From udayendu.kar at gmail.com Mon Apr 1 06:46:10 2013 From: udayendu.kar at gmail.com (Udayendu Sekhar kar) Date: Mon, 1 Apr 2013 12:16:10 +0530 Subject: [Engine-devel] Latest **ovirt-node** is available with a wrong release date at ovirt.org !! Message-ID: Index of /releases/3.2/iso [image: [ICO]]NameLast modified Size Description ------------------------------ [image: [DIR]]Parent Directory - [image: [ ]]ovirt-node-iso-2.6.0-20130212.fc18.iso14-Feb-2013 19:09 207M [image: [ ]]ovirt-node-iso-2.6.1-20120228.fc18.iso28-Feb-2013 11:47 208M <====== ------------------------------ Hey All, Can we please modify the latest **ovirt-node** iso release date in ovirt.org download stream. Thanks, Uday -------------- next part -------------- An HTML attachment was scrubbed... URL: From emesika at redhat.com Mon Apr 1 21:35:03 2013 From: emesika at redhat.com (Eli Mesika) Date: Mon, 1 Apr 2013 17:35:03 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <1442496988.16060758.1364484694306.JavaMail.root@redhat.com> References: <1442496988.16060758.1364484694306.JavaMail.root@redhat.com> Message-ID: <416667521.234829.1364852103221.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Laszlo Hornyak" > To: "Libor Spevak" > Cc: "Juan Hernandez" , engine-devel at ovirt.org > Sent: Thursday, March 28, 2013 5:31:34 PM > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > > > ----- Original Message ----- > > From: "Libor Spevak" > > To: "Itamar Heim" > > Cc: "Juan Hernandez" , engine-devel at ovirt.org > > Sent: Thursday, March 28, 2013 4:04:20 PM > > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > > > Hi, > > > > apart from SQL vs. stored procedures discussion, I am trying to > > understand what we can get if we support more databases... Sorry for joining this discussion so late (I was in a vacation) anyway two points missing from SQL VS. SP are 1) security - With plain SQL we will have to handle SQL Injection 2) It is more economic to pass a call to SP than the full SQL on the wire... > > > > Some points: > > 1. Is there a real need by end-users/customers to run it on e.g. > > Oracle > > only? (performance, stability, easier administration). > > Usually companies have one database and they are trying to stick to that one. > Having two doubles the resource needs, you need one more DBA team, care for > mirrors, backups. So it almost doubles the costs. Generally, I agree with Alon B L , if you have to support X DBs you are not doubling the effort by X Actually, we had already experience with that when we supported both MS SQL & Postgres I believe that as we have some customers with large installations, performance counts and the best way (and sometimes teh only way) id the DB layer > This is why I frequently hear people asking if we plan to support XyDB in the > future. PostgreSQL is cool, but those who already use MySQL/MariaDB, they > just do not want one more. > > > What is the future of PostgreSQL? > > > > 2. Is it decided by architectural board, what kind of databases we > > would > > like to support? (cannot support any db) > > With a JPA we could support most mainstream relational databases, but in my > opinion 99 percent of people run oracle, mysql/mariadb or postgresql. So > maybe we do not have to think in big number of database engines. > This is theoretical since JPA is still on wishlist :( > > > > > 3. Are we talking about the Engine only, or there will be a need to > > rewrite ETL mappings and upgrade DWH database, or maybe modify > > JasperReports templates (simply, some DB types behave differently)? > > Maybe we can look at JasperSoft solution, they support more > > databases. IMHO , ETL & DWH are perfect candidates for NO SQL which is already supported by Jasper > > > > 4. Current full/incremental upgrade process of PostgreSQL is IMHO > > very > > good tuned (it is similar to dbmaintain.org tool - Java > > implementation - > > I used successfully on one project - after some changes of course). I > > do > > not believe we can use or easily develop general upgrade/migration > > tool, > > and XML based (I am sorry Alissa, not sure about Liquibase, I haven't > > studied it deeply, but there is a need to incrementally change db > > objects, but sometimes also to migrate data to new structures, the > > most > > flexible and quickest is to do it using native SQL, but yes, it > > depends > > on the project needs...). I had evaluated Liquibase and I think that managing your DB upgrades via XML is very unfriendly and very limited as you reach complex upgrades as we had in the past. Just think of the tables in which we change the key from long to UUID , there is no way to do that in such tools > > > > 5. As a developer, with every new column I need to write upgrade > > scripts, prepare test environments and test all scenarios several > > times > > on different databases, so time-consuming. Did it also , again , since our SQL is 90% simple , the effort of writing a SP for more than one DB is not so high (and you have free converters you can use for that) Finally, embedded SQL in the Java code is not a good idea, it will be hard to maintain it and it is not advancing us in supporting more than one database. We have already SQL generated in the Java code on the search engine and IMHO this is one of the parts in the applications that needs a rewrite ... > > > > > > On 27.3.2013 13:53, Itamar Heim wrote: > > > On 03/26/2013 08:39 PM, Alon Bar-Lev wrote: > > >> > > >> > > >> ----- Original Message ----- > > >>> From: "Juan Hernandez" > > >>> To: engine-devel at ovirt.org > > >>> Sent: Tuesday, March 26, 2013 7:34:04 PM > > >>> Subject: [Engine-devel] Move SQL out of stored procedures > > >>> > > >>> Hello, > > >>> > > >>> I would like to start a discussion about the subject. I think > > >>> this is > > >>> something we need to do if one day we want to be able to use any > > >>> database other than PostgreSQL. > > >> > > >> Hello, > > >> > > >> I think that database layer is a software interface like any other > > >> software interface, if done properly, a dba can convert the stored > > >> procedure to any other database without any code change. > > >> > > >> This way the database specific implementation lives within the > > >> database and maintained by the designated dba. > > >> > > >> Fixups and optimizations can be done in database without touching > > >> the > > >> code. > > >> > > >> Backward compatibility layer is much simpler to implement based on > > >> stored procedures than complex set of views and tables. > > >> > > >> Also, accessing the database via different technologies is simpler > > >> if > > >> there is maintained database interface (stored procedures). > > >> > > >> I've seen hibernate based java applications that promised to be > > >> database independent but at the edges when performance counts, the > > >> DAO became HQL, then a special dialect and finally database > > >> specific > > >> SQLS. > > > > > > there may be db specific optimization/logic, but I don't see why we > > > need STPs for 80% (if not more) of the CRUD and basic queries. > > > > > > I also agree with Tal later in the thread that its a good question > > > if > > > we can't find a better solution than re-writing the sql's in the > > > code > > > > > > _______________________________________________ > > > 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 shuming at linux.vnet.ibm.com Tue Apr 2 02:15:44 2013 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Tue, 02 Apr 2013 10:15:44 +0800 Subject: [Engine-devel] [RFC] new power management protocol "libvirtp" Message-ID: <515A3F50.6030001@linux.vnet.ibm.com> Hi, In oVirt environment, power manager should be enabled for the host to support VM high availability in the cluster. Various kinds of physical power management protocol are supported, ie., ALOM, ILO&etc. However, when the oVirt is running on a nested KVM environment, there is no feasible way to do the power management of the VDSM host(also a KVM virtual machine). A new protocol will be based on libvirt to achieve the power management of a virtual host. The new protocol can be named as "libvirtp". In oVirt engine, a new type will be added to power management---> type libvirtp power management--->address it will be the IP of the physical host where the virtual VDSM host is on when "libvirtp" is selected power management--->user name it will be the user name to the libvirtd service power management--->password it will be the password to the libvirtd service power management--->port it will be the port to the libvirtd service -- --- ?? Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming at cn.ibm.com or shuming at linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC From lzelkha at redhat.com Tue Apr 2 05:24:08 2013 From: lzelkha at redhat.com (Liran Zelkha) Date: Tue, 2 Apr 2013 01:24:08 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <416667521.234829.1364852103221.JavaMail.root@redhat.com> References: <1442496988.16060758.1364484694306.JavaMail.root@redhat.com> <416667521.234829.1364852103221.JavaMail.root@redhat.com> Message-ID: <2076126807.440539.1364880248853.JavaMail.root@redhat.com> I also apologize for jumping in late... I think concerning SQL injection we'll be covered by using PreparedStatements. Since we're using SpringJDBC, most of our code uses PreparedStatements anyway. Concerning ORM - I feel it won't really be beneficial to us. I know of very few projects who can actually be cross-database, and just maintaining schema creation scripts for different databases can be too difficult to maintain. Also, from a performance perspective, ORM performs worse than regular SQL (or stored procedures), so it wouldn't be the direction I choose. I think we should keep using SpringJDBC with either SQL or stored procedures (doesn't really matter, whatever is easier to maintain and performs faster) and maybe add a better, more generic, RowMapper class. ----- Original Message ----- From: "Eli Mesika" To: engine-devel at ovirt.org Sent: Tuesday, April 2, 2013 12:35:03 AM Subject: Re: [Engine-devel] Move SQL out of stored procedures ----- Original Message ----- > From: "Laszlo Hornyak" > To: "Libor Spevak" > Cc: "Juan Hernandez" , engine-devel at ovirt.org > Sent: Thursday, March 28, 2013 5:31:34 PM > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > > > ----- Original Message ----- > > From: "Libor Spevak" > > To: "Itamar Heim" > > Cc: "Juan Hernandez" , engine-devel at ovirt.org > > Sent: Thursday, March 28, 2013 4:04:20 PM > > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > > > Hi, > > > > apart from SQL vs. stored procedures discussion, I am trying to > > understand what we can get if we support more databases... Sorry for joining this discussion so late (I was in a vacation) anyway two points missing from SQL VS. SP are 1) security - With plain SQL we will have to handle SQL Injection 2) It is more economic to pass a call to SP than the full SQL on the wire... > > > > Some points: > > 1. Is there a real need by end-users/customers to run it on e.g. > > Oracle > > only? (performance, stability, easier administration). > > Usually companies have one database and they are trying to stick to that one. > Having two doubles the resource needs, you need one more DBA team, care for > mirrors, backups. So it almost doubles the costs. Generally, I agree with Alon B L , if you have to support X DBs you are not doubling the effort by X Actually, we had already experience with that when we supported both MS SQL & Postgres I believe that as we have some customers with large installations, performance counts and the best way (and sometimes teh only way) id the DB layer > This is why I frequently hear people asking if we plan to support XyDB in the > future. PostgreSQL is cool, but those who already use MySQL/MariaDB, they > just do not want one more. > > > What is the future of PostgreSQL? > > > > 2. Is it decided by architectural board, what kind of databases we > > would > > like to support? (cannot support any db) > > With a JPA we could support most mainstream relational databases, but in my > opinion 99 percent of people run oracle, mysql/mariadb or postgresql. So > maybe we do not have to think in big number of database engines. > This is theoretical since JPA is still on wishlist :( > > > > > 3. Are we talking about the Engine only, or there will be a need to > > rewrite ETL mappings and upgrade DWH database, or maybe modify > > JasperReports templates (simply, some DB types behave differently)? > > Maybe we can look at JasperSoft solution, they support more > > databases. IMHO , ETL & DWH are perfect candidates for NO SQL which is already supported by Jasper > > > > 4. Current full/incremental upgrade process of PostgreSQL is IMHO > > very > > good tuned (it is similar to dbmaintain.org tool - Java > > implementation - > > I used successfully on one project - after some changes of course). I > > do > > not believe we can use or easily develop general upgrade/migration > > tool, > > and XML based (I am sorry Alissa, not sure about Liquibase, I haven't > > studied it deeply, but there is a need to incrementally change db > > objects, but sometimes also to migrate data to new structures, the > > most > > flexible and quickest is to do it using native SQL, but yes, it > > depends > > on the project needs...). I had evaluated Liquibase and I think that managing your DB upgrades via XML is very unfriendly and very limited as you reach complex upgrades as we had in the past. Just think of the tables in which we change the key from long to UUID , there is no way to do that in such tools > > > > 5. As a developer, with every new column I need to write upgrade > > scripts, prepare test environments and test all scenarios several > > times > > on different databases, so time-consuming. Did it also , again , since our SQL is 90% simple , the effort of writing a SP for more than one DB is not so high (and you have free converters you can use for that) Finally, embedded SQL in the Java code is not a good idea, it will be hard to maintain it and it is not advancing us in supporting more than one database. We have already SQL generated in the Java code on the search engine and IMHO this is one of the parts in the applications that needs a rewrite ... > > > > > > On 27.3.2013 13:53, Itamar Heim wrote: > > > On 03/26/2013 08:39 PM, Alon Bar-Lev wrote: > > >> > > >> > > >> ----- Original Message ----- > > >>> From: "Juan Hernandez" > > >>> To: engine-devel at ovirt.org > > >>> Sent: Tuesday, March 26, 2013 7:34:04 PM > > >>> Subject: [Engine-devel] Move SQL out of stored procedures > > >>> > > >>> Hello, > > >>> > > >>> I would like to start a discussion about the subject. I think > > >>> this is > > >>> something we need to do if one day we want to be able to use any > > >>> database other than PostgreSQL. > > >> > > >> Hello, > > >> > > >> I think that database layer is a software interface like any other > > >> software interface, if done properly, a dba can convert the stored > > >> procedure to any other database without any code change. > > >> > > >> This way the database specific implementation lives within the > > >> database and maintained by the designated dba. > > >> > > >> Fixups and optimizations can be done in database without touching > > >> the > > >> code. > > >> > > >> Backward compatibility layer is much simpler to implement based on > > >> stored procedures than complex set of views and tables. > > >> > > >> Also, accessing the database via different technologies is simpler > > >> if > > >> there is maintained database interface (stored procedures). > > >> > > >> I've seen hibernate based java applications that promised to be > > >> database independent but at the edges when performance counts, the > > >> DAO became HQL, then a special dialect and finally database > > >> specific > > >> SQLS. > > > > > > there may be db specific optimization/logic, but I don't see why we > > > need STPs for 80% (if not more) of the CRUD and basic queries. > > > > > > I also agree with Tal later in the thread that its a good question > > > if > > > we can't find a better solution than re-writing the sql's in the > > > code > > > > > > _______________________________________________ > > > 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 lhornyak at redhat.com Tue Apr 2 06:34:53 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Tue, 2 Apr 2013 02:34:53 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <2076126807.440539.1364880248853.JavaMail.root@redhat.com> References: <1442496988.16060758.1364484694306.JavaMail.root@redhat.com> <416667521.234829.1364852103221.JavaMail.root@redhat.com> <2076126807.440539.1364880248853.JavaMail.root@redhat.com> Message-ID: <2012118280.451038.1364884493689.JavaMail.root@redhat.com> Hi Liran, I agree that ORM tools in general have to add some mapping overhead, but that overhead is very small compared to the time needed by the database interaction. ORM tools sometimes generate SQL statements that we could imagine being better, I do not think they are as hard for the DB as for example the ones generated by searchbackend. Also, we can do rdbms specific optimizations when needed. Plus we could finally have some caching in ovirt engine and the code would not have to read e.g. the DC record again and again. There are some more like that. Therefore having a JPA could improve the performance in engine. Laszlo ----- Original Message ----- > From: "Liran Zelkha" > To: "Eli Mesika" > Cc: engine-devel at ovirt.org > Sent: Tuesday, April 2, 2013 7:24:08 AM > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > I also apologize for jumping in late... > I think concerning SQL injection we'll be covered by using > PreparedStatements. Since we're using SpringJDBC, most of our code uses > PreparedStatements anyway. > Concerning ORM - I feel it won't really be beneficial to us. I know of very > few projects who can actually be cross-database, and just maintaining schema > creation scripts for different databases can be too difficult to maintain. > Also, from a performance perspective, ORM performs worse than regular SQL > (or stored procedures), so it wouldn't be the direction I choose. > I think we should keep using SpringJDBC with either SQL or stored procedures > (doesn't really matter, whatever is easier to maintain and performs faster) > and maybe add a better, more generic, RowMapper class. > > ----- Original Message ----- > From: "Eli Mesika" > To: engine-devel at ovirt.org > Sent: Tuesday, April 2, 2013 12:35:03 AM > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > > > ----- Original Message ----- > > From: "Laszlo Hornyak" > > To: "Libor Spevak" > > Cc: "Juan Hernandez" , engine-devel at ovirt.org > > Sent: Thursday, March 28, 2013 5:31:34 PM > > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > > > > > > > ----- Original Message ----- > > > From: "Libor Spevak" > > > To: "Itamar Heim" > > > Cc: "Juan Hernandez" , engine-devel at ovirt.org > > > Sent: Thursday, March 28, 2013 4:04:20 PM > > > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > > > > > Hi, > > > > > > apart from SQL vs. stored procedures discussion, I am trying to > > > understand what we can get if we support more databases... > > Sorry for joining this discussion so late (I was in a vacation) > anyway > two points missing from SQL VS. SP are > 1) security - With plain SQL we will have to handle SQL Injection > 2) It is more economic to pass a call to SP than the full SQL on the wire... > > > > > > > > Some points: > > > 1. Is there a real need by end-users/customers to run it on e.g. > > > Oracle > > > only? (performance, stability, easier administration). > > > > Usually companies have one database and they are trying to stick to that > > one. > > Having two doubles the resource needs, you need one more DBA team, care for > > mirrors, backups. So it almost doubles the costs. > > Generally, I agree with Alon B L , if you have to support X DBs you are not > doubling the effort by X > Actually, we had already experience with that when we supported both MS SQL & > Postgres > I believe that as we have some customers with large installations, > performance counts and the best way (and sometimes teh only way) id the DB > layer > > > This is why I frequently hear people asking if we plan to support XyDB in > > the > > future. PostgreSQL is cool, but those who already use MySQL/MariaDB, they > > just do not want one more. > > > > > What is the future of PostgreSQL? > > > > > > 2. Is it decided by architectural board, what kind of databases we > > > would > > > like to support? (cannot support any db) > > > > With a JPA we could support most mainstream relational databases, but in my > > opinion 99 percent of people run oracle, mysql/mariadb or postgresql. So > > maybe we do not have to think in big number of database engines. > > This is theoretical since JPA is still on wishlist :( > > > > > > > > 3. Are we talking about the Engine only, or there will be a need to > > > rewrite ETL mappings and upgrade DWH database, or maybe modify > > > JasperReports templates (simply, some DB types behave differently)? > > > Maybe we can look at JasperSoft solution, they support more > > > databases. > > IMHO , ETL & DWH are perfect candidates for NO SQL which is already supported > by Jasper > > > > > > > 4. Current full/incremental upgrade process of PostgreSQL is IMHO > > > very > > > good tuned (it is similar to dbmaintain.org tool - Java > > > implementation - > > > I used successfully on one project - after some changes of course). I > > > do > > > not believe we can use or easily develop general upgrade/migration > > > tool, > > > and XML based (I am sorry Alissa, not sure about Liquibase, I haven't > > > studied it deeply, but there is a need to incrementally change db > > > objects, but sometimes also to migrate data to new structures, the > > > most > > > flexible and quickest is to do it using native SQL, but yes, it > > > depends > > > on the project needs...). > > I had evaluated Liquibase and I think that managing your DB upgrades via XML > is very unfriendly and very limited as you reach complex upgrades as we had > in the past. > Just think of the tables in which we change the key from long to UUID , there > is no way to do that in such tools > > > > > > > 5. As a developer, with every new column I need to write upgrade > > > scripts, prepare test environments and test all scenarios several > > > times > > > on different databases, so time-consuming. > > Did it also , again , since our SQL is 90% simple , the effort of writing a > SP for more than one DB is not so high (and you have free converters you can > use for that) > > Finally, embedded SQL in the Java code is not a good idea, it will be hard to > maintain it and it is not advancing us in supporting more than one database. > We have already SQL generated in the Java code on the search engine and IMHO > this is one of the parts in the applications that needs a rewrite ... > > > > > > > > > > On 27.3.2013 13:53, Itamar Heim wrote: > > > > On 03/26/2013 08:39 PM, Alon Bar-Lev wrote: > > > >> > > > >> > > > >> ----- Original Message ----- > > > >>> From: "Juan Hernandez" > > > >>> To: engine-devel at ovirt.org > > > >>> Sent: Tuesday, March 26, 2013 7:34:04 PM > > > >>> Subject: [Engine-devel] Move SQL out of stored procedures > > > >>> > > > >>> Hello, > > > >>> > > > >>> I would like to start a discussion about the subject. I think > > > >>> this is > > > >>> something we need to do if one day we want to be able to use any > > > >>> database other than PostgreSQL. > > > >> > > > >> Hello, > > > >> > > > >> I think that database layer is a software interface like any other > > > >> software interface, if done properly, a dba can convert the stored > > > >> procedure to any other database without any code change. > > > >> > > > >> This way the database specific implementation lives within the > > > >> database and maintained by the designated dba. > > > >> > > > >> Fixups and optimizations can be done in database without touching > > > >> the > > > >> code. > > > >> > > > >> Backward compatibility layer is much simpler to implement based on > > > >> stored procedures than complex set of views and tables. > > > >> > > > >> Also, accessing the database via different technologies is simpler > > > >> if > > > >> there is maintained database interface (stored procedures). > > > >> > > > >> I've seen hibernate based java applications that promised to be > > > >> database independent but at the edges when performance counts, the > > > >> DAO became HQL, then a special dialect and finally database > > > >> specific > > > >> SQLS. > > > > > > > > there may be db specific optimization/logic, but I don't see why we > > > > need STPs for 80% (if not more) of the CRUD and basic queries. > > > > > > > > I also agree with Tal later in the thread that its a good question > > > > if > > > > we can't find a better solution than re-writing the sql's in the > > > > code > > > > > > > > _______________________________________________ > > > > 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 > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From liran.zelkha at gmail.com Tue Apr 2 06:37:28 2013 From: liran.zelkha at gmail.com (Liran Zelkha) Date: Tue, 2 Apr 2013 09:37:28 +0300 Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <2012118280.451038.1364884493689.JavaMail.root@redhat.com> References: <1442496988.16060758.1364484694306.JavaMail.root@redhat.com> <416667521.234829.1364852103221.JavaMail.root@redhat.com> <2076126807.440539.1364880248853.JavaMail.root@redhat.com> <2012118280.451038.1364884493689.JavaMail.root@redhat.com> Message-ID: <4409558F-4634-48AD-870E-EEC39A68A5E7@gmail.com> Hi Laszlo, I'm currently in the process of adding a caching layer on top of JdbcTemplate, which would greatly reduce the number of database activities we have, so that would solve the last item you raised. I didn't mean the ORM performance is caused by the mapping. I think the problem lies in the fact that we will modify our code to have batch updates for most insert activities - a thing that is impossible in JPA/Hibernate. So, if we'll have some code in SQL and some in ORM - I prefer we stick all code to SQL? On Apr 2, 2013, at 9:34 AM, Laszlo Hornyak wrote: > Hi Liran, > > I agree that ORM tools in general have to add some mapping overhead, but that overhead is very small compared to the time needed by the database interaction. > ORM tools sometimes generate SQL statements that we could imagine being better, I do not think they are as hard for the DB as for example the ones generated by searchbackend. Also, we can do rdbms specific optimizations when needed. > Plus we could finally have some caching in ovirt engine and the code would not have to read e.g. the DC record again and again. There are some more like that. > > Therefore having a JPA could improve the performance in engine. > > Laszlo > > ----- Original Message ----- >> From: "Liran Zelkha" >> To: "Eli Mesika" >> Cc: engine-devel at ovirt.org >> Sent: Tuesday, April 2, 2013 7:24:08 AM >> Subject: Re: [Engine-devel] Move SQL out of stored procedures >> >> I also apologize for jumping in late... >> I think concerning SQL injection we'll be covered by using >> PreparedStatements. Since we're using SpringJDBC, most of our code uses >> PreparedStatements anyway. >> Concerning ORM - I feel it won't really be beneficial to us. I know of very >> few projects who can actually be cross-database, and just maintaining schema >> creation scripts for different databases can be too difficult to maintain. >> Also, from a performance perspective, ORM performs worse than regular SQL >> (or stored procedures), so it wouldn't be the direction I choose. >> I think we should keep using SpringJDBC with either SQL or stored procedures >> (doesn't really matter, whatever is easier to maintain and performs faster) >> and maybe add a better, more generic, RowMapper class. >> >> ----- Original Message ----- >> From: "Eli Mesika" >> To: engine-devel at ovirt.org >> Sent: Tuesday, April 2, 2013 12:35:03 AM >> Subject: Re: [Engine-devel] Move SQL out of stored procedures >> >> >> >> ----- Original Message ----- >>> From: "Laszlo Hornyak" >>> To: "Libor Spevak" >>> Cc: "Juan Hernandez" , engine-devel at ovirt.org >>> Sent: Thursday, March 28, 2013 5:31:34 PM >>> Subject: Re: [Engine-devel] Move SQL out of stored procedures >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Libor Spevak" >>>> To: "Itamar Heim" >>>> Cc: "Juan Hernandez" , engine-devel at ovirt.org >>>> Sent: Thursday, March 28, 2013 4:04:20 PM >>>> Subject: Re: [Engine-devel] Move SQL out of stored procedures >>>> >>>> Hi, >>>> >>>> apart from SQL vs. stored procedures discussion, I am trying to >>>> understand what we can get if we support more databases... >> >> Sorry for joining this discussion so late (I was in a vacation) >> anyway >> two points missing from SQL VS. SP are >> 1) security - With plain SQL we will have to handle SQL Injection >> 2) It is more economic to pass a call to SP than the full SQL on the wire... >> >> >>>> >>>> Some points: >>>> 1. Is there a real need by end-users/customers to run it on e.g. >>>> Oracle >>>> only? (performance, stability, easier administration). >>> >>> Usually companies have one database and they are trying to stick to that >>> one. >>> Having two doubles the resource needs, you need one more DBA team, care for >>> mirrors, backups. So it almost doubles the costs. >> >> Generally, I agree with Alon B L , if you have to support X DBs you are not >> doubling the effort by X >> Actually, we had already experience with that when we supported both MS SQL & >> Postgres >> I believe that as we have some customers with large installations, >> performance counts and the best way (and sometimes teh only way) id the DB >> layer >> >>> This is why I frequently hear people asking if we plan to support XyDB in >>> the >>> future. PostgreSQL is cool, but those who already use MySQL/MariaDB, they >>> just do not want one more. >>> >>>> What is the future of PostgreSQL? >>>> >>>> 2. Is it decided by architectural board, what kind of databases we >>>> would >>>> like to support? (cannot support any db) >>> >>> With a JPA we could support most mainstream relational databases, but in my >>> opinion 99 percent of people run oracle, mysql/mariadb or postgresql. So >>> maybe we do not have to think in big number of database engines. >>> This is theoretical since JPA is still on wishlist :( >>> >>>> >>>> 3. Are we talking about the Engine only, or there will be a need to >>>> rewrite ETL mappings and upgrade DWH database, or maybe modify >>>> JasperReports templates (simply, some DB types behave differently)? >>>> Maybe we can look at JasperSoft solution, they support more >>>> databases. >> >> IMHO , ETL & DWH are perfect candidates for NO SQL which is already supported >> by Jasper >> >>>> >>>> 4. Current full/incremental upgrade process of PostgreSQL is IMHO >>>> very >>>> good tuned (it is similar to dbmaintain.org tool - Java >>>> implementation - >>>> I used successfully on one project - after some changes of course). I >>>> do >>>> not believe we can use or easily develop general upgrade/migration >>>> tool, >>>> and XML based (I am sorry Alissa, not sure about Liquibase, I haven't >>>> studied it deeply, but there is a need to incrementally change db >>>> objects, but sometimes also to migrate data to new structures, the >>>> most >>>> flexible and quickest is to do it using native SQL, but yes, it >>>> depends >>>> on the project needs...). >> >> I had evaluated Liquibase and I think that managing your DB upgrades via XML >> is very unfriendly and very limited as you reach complex upgrades as we had >> in the past. >> Just think of the tables in which we change the key from long to UUID , there >> is no way to do that in such tools >> >>>> >>>> 5. As a developer, with every new column I need to write upgrade >>>> scripts, prepare test environments and test all scenarios several >>>> times >>>> on different databases, so time-consuming. >> >> Did it also , again , since our SQL is 90% simple , the effort of writing a >> SP for more than one DB is not so high (and you have free converters you can >> use for that) >> >> Finally, embedded SQL in the Java code is not a good idea, it will be hard to >> maintain it and it is not advancing us in supporting more than one database. >> We have already SQL generated in the Java code on the search engine and IMHO >> this is one of the parts in the applications that needs a rewrite ... >> >>>> >>>> >>>> On 27.3.2013 13:53, Itamar Heim wrote: >>>>> On 03/26/2013 08:39 PM, Alon Bar-Lev wrote: >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Juan Hernandez" >>>>>>> To: engine-devel at ovirt.org >>>>>>> Sent: Tuesday, March 26, 2013 7:34:04 PM >>>>>>> Subject: [Engine-devel] Move SQL out of stored procedures >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I would like to start a discussion about the subject. I think >>>>>>> this is >>>>>>> something we need to do if one day we want to be able to use any >>>>>>> database other than PostgreSQL. >>>>>> >>>>>> Hello, >>>>>> >>>>>> I think that database layer is a software interface like any other >>>>>> software interface, if done properly, a dba can convert the stored >>>>>> procedure to any other database without any code change. >>>>>> >>>>>> This way the database specific implementation lives within the >>>>>> database and maintained by the designated dba. >>>>>> >>>>>> Fixups and optimizations can be done in database without touching >>>>>> the >>>>>> code. >>>>>> >>>>>> Backward compatibility layer is much simpler to implement based on >>>>>> stored procedures than complex set of views and tables. >>>>>> >>>>>> Also, accessing the database via different technologies is simpler >>>>>> if >>>>>> there is maintained database interface (stored procedures). >>>>>> >>>>>> I've seen hibernate based java applications that promised to be >>>>>> database independent but at the edges when performance counts, the >>>>>> DAO became HQL, then a special dialect and finally database >>>>>> specific >>>>>> SQLS. >>>>> >>>>> there may be db specific optimization/logic, but I don't see why we >>>>> need STPs for 80% (if not more) of the CRUD and basic queries. >>>>> >>>>> I also agree with Tal later in the thread that its a good question >>>>> if >>>>> we can't find a better solution than re-writing the sql's in the >>>>> code >>>>> >>>>> _______________________________________________ >>>>> 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 >> _______________________________________________ >> 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 danken at redhat.com Tue Apr 2 06:50:44 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Tue, 2 Apr 2013 09:50:44 +0300 Subject: [Engine-devel] [RFC] new power management protocol "libvirtp" In-Reply-To: <515A3F50.6030001@linux.vnet.ibm.com> References: <515A3F50.6030001@linux.vnet.ibm.com> Message-ID: <20130402065043.GE24503@redhat.com> On Tue, Apr 02, 2013 at 10:15:44AM +0800, Shu Ming wrote: > Hi, > > In oVirt environment, power manager should be enabled for the host to > support VM high availability in the cluster. Various kinds of > physical power management protocol are supported, ie., ALOM, ILO&etc. > However, when the oVirt is running on a nested KVM > environment, there is no feasible way to do the power management of the > VDSM host(also a KVM virtual machine). A new protocol > will be based on libvirt to achieve the power management of a virtual > host. The new protocol can be named as "libvirtp". > > In oVirt engine, a new type will be added to > > power management---> type libvirtp > power management--->address it will be the IP of the physical host where > the virtual VDSM host is on when "libvirtp" is selected > power management--->user name it will be the user name to the libvirtd > service > power management--->password it will be the password to the libvirtd service > power management--->port it will be the port to the libvirtd service Have you looked into fence_virsh or fence_virt ? Don't they provide what you want? From lhornyak at redhat.com Tue Apr 2 06:54:13 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Tue, 2 Apr 2013 02:54:13 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <416667521.234829.1364852103221.JavaMail.root@redhat.com> References: <1442496988.16060758.1364484694306.JavaMail.root@redhat.com> <416667521.234829.1364852103221.JavaMail.root@redhat.com> Message-ID: <74282452.453368.1364885653238.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Eli Mesika" > To: engine-devel at ovirt.org > Sent: Monday, April 1, 2013 11:35:03 PM > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > > > ----- Original Message ----- > > From: "Laszlo Hornyak" > > To: "Libor Spevak" > > Cc: "Juan Hernandez" , engine-devel at ovirt.org > > Sent: Thursday, March 28, 2013 5:31:34 PM > > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > > > > > > > ----- Original Message ----- > > > From: "Libor Spevak" > > > To: "Itamar Heim" > > > Cc: "Juan Hernandez" , engine-devel at ovirt.org > > > Sent: Thursday, March 28, 2013 4:04:20 PM > > > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > > > > > Hi, > > > > > > apart from SQL vs. stored procedures discussion, I am trying to > > > understand what we can get if we support more databases... > > Sorry for joining this discussion so late (I was in a vacation) > anyway > two points missing from SQL VS. SP are > 1) security - With plain SQL we will have to handle SQL Injection I do not understand this. What's wrong with PreparedStatement? > 2) It is more economic to pass a call to SP than the full SQL on the wire... Ah that is not actually happening with postgresql :) I don't know about all the specific DB's but I am quite sure most other DB does not do that either. If you have a DataSource, like commons-dbcp, it is caching the PreparedStatements in the background. A PreparedStatement executes a 'PREPARE' command in postgresql http://www.postgresql.org/docs/9.2/static/sql-prepare.html After that it will only send over the name of the query plan and the parameters. I believe it usually does not save a lot on bandwidth, for example engine's SQL statements fit in a single tcp/ip frame, but the query parser and planner needs to run only once, when you create the query plan and that is a big win. I wrote a testfor this once, quite long ago but I remember something around 10% win if the query execution was simple enough. But of course it does not matter much if you have a pile of seqscan in your query plan. Anyway, this is kind of cool in PostgreSQL :) > > > > > > > > Some points: > > > 1. Is there a real need by end-users/customers to run it on e.g. > > > Oracle > > > only? (performance, stability, easier administration). > > > > Usually companies have one database and they are trying to stick to that > > one. > > Having two doubles the resource needs, you need one more DBA team, care for > > mirrors, backups. So it almost doubles the costs. > > Generally, I agree with Alon B L , if you have to support X DBs you are not > doubling the effort by X > Actually, we had already experience with that when we supported both MS SQL & > Postgres > I believe that as we have some customers with large installations, > performance counts and the best way (and sometimes teh only way) id the DB > layer Ok, then let's tell MySQL/MariaDB users to use PostgerSQL and see what happens. > > > This is why I frequently hear people asking if we plan to support XyDB in > > the > > future. PostgreSQL is cool, but those who already use MySQL/MariaDB, they > > just do not want one more. > > > > > What is the future of PostgreSQL? > > > > > > 2. Is it decided by architectural board, what kind of databases we > > > would > > > like to support? (cannot support any db) > > > > With a JPA we could support most mainstream relational databases, but in my > > opinion 99 percent of people run oracle, mysql/mariadb or postgresql. So > > maybe we do not have to think in big number of database engines. > > This is theoretical since JPA is still on wishlist :( > > > > > > > > 3. Are we talking about the Engine only, or there will be a need to > > > rewrite ETL mappings and upgrade DWH database, or maybe modify > > > JasperReports templates (simply, some DB types behave differently)? > > > Maybe we can look at JasperSoft solution, they support more > > > databases. > > IMHO , ETL & DWH are perfect candidates for NO SQL which is already supported > by Jasper > > > > > > > 4. Current full/incremental upgrade process of PostgreSQL is IMHO > > > very > > > good tuned (it is similar to dbmaintain.org tool - Java > > > implementation - > > > I used successfully on one project - after some changes of course). I > > > do > > > not believe we can use or easily develop general upgrade/migration > > > tool, > > > and XML based (I am sorry Alissa, not sure about Liquibase, I haven't > > > studied it deeply, but there is a need to incrementally change db > > > objects, but sometimes also to migrate data to new structures, the > > > most > > > flexible and quickest is to do it using native SQL, but yes, it > > > depends > > > on the project needs...). > > I had evaluated Liquibase and I think that managing your DB upgrades via XML > is very unfriendly and very limited as you reach complex upgrades as we had > in the past. > Just think of the tables in which we change the key from long to UUID , there > is no way to do that in such tools > > > > > > > 5. As a developer, with every new column I need to write upgrade > > > scripts, prepare test environments and test all scenarios several > > > times > > > on different databases, so time-consuming. > > Did it also , again , since our SQL is 90% simple , the effort of writing a > SP for more than one DB is not so high (and you have free converters you can > use for that) > > Finally, embedded SQL in the Java code is not a good idea, it will be hard to > maintain it and it is not advancing us in supporting more than one database. > We have already SQL generated in the Java code on the search engine and IMHO > this is one of the parts in the applications that needs a rewrite ... > > > > > > > > > > On 27.3.2013 13:53, Itamar Heim wrote: > > > > On 03/26/2013 08:39 PM, Alon Bar-Lev wrote: > > > >> > > > >> > > > >> ----- Original Message ----- > > > >>> From: "Juan Hernandez" > > > >>> To: engine-devel at ovirt.org > > > >>> Sent: Tuesday, March 26, 2013 7:34:04 PM > > > >>> Subject: [Engine-devel] Move SQL out of stored procedures > > > >>> > > > >>> Hello, > > > >>> > > > >>> I would like to start a discussion about the subject. I think > > > >>> this is > > > >>> something we need to do if one day we want to be able to use any > > > >>> database other than PostgreSQL. > > > >> > > > >> Hello, > > > >> > > > >> I think that database layer is a software interface like any other > > > >> software interface, if done properly, a dba can convert the stored > > > >> procedure to any other database without any code change. > > > >> > > > >> This way the database specific implementation lives within the > > > >> database and maintained by the designated dba. > > > >> > > > >> Fixups and optimizations can be done in database without touching > > > >> the > > > >> code. > > > >> > > > >> Backward compatibility layer is much simpler to implement based on > > > >> stored procedures than complex set of views and tables. > > > >> > > > >> Also, accessing the database via different technologies is simpler > > > >> if > > > >> there is maintained database interface (stored procedures). > > > >> > > > >> I've seen hibernate based java applications that promised to be > > > >> database independent but at the edges when performance counts, the > > > >> DAO became HQL, then a special dialect and finally database > > > >> specific > > > >> SQLS. > > > > > > > > there may be db specific optimization/logic, but I don't see why we > > > > need STPs for 80% (if not more) of the CRUD and basic queries. > > > > > > > > I also agree with Tal later in the thread that its a good question > > > > if > > > > we can't find a better solution than re-writing the sql's in the > > > > code > > > > > > > > _______________________________________________ > > > > 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 dfediuck at redhat.com Tue Apr 2 07:08:07 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Tue, 2 Apr 2013 03:08:07 -0400 (EDT) Subject: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your review In-Reply-To: References: <60519417.9696375.1364465102897.JavaMail.root@redhat.com> <1014066770.26313104.1364481799434.JavaMail.root@redhat.com> Message-ID: <814713580.693563.1364886487701.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Wei D Chen" > To: "Doron Fediuck" , "Ofri Masad" > Cc: engine-devel at ovirt.org > Sent: Friday, March 29, 2013 5:00:55 AM > Subject: Re: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your > review > > Thanks Doron & Ofri, > > As to the question of cache flash, we already have our consideration and > wrote them on our design page. I have no doubt that your suggestion is more > reasonable, we just keep in mind that expiration is much longer that the > time needed to poll all of hosts, so this is really a potential issue we > ignored. Let's make estimation at first, we will have a try if our schedule > is okay. > > Doron, we have reserved some effort to research about cluster-level policy. > As ovirt is complete new to our engineers, would we finished our current > features (such as ovf and rest api.) in pipeline at first? After these basic > features are ready and we still have some buffer, we will make some > improvement. Is this acceptable? > > Thanks again to Doron and Ofri. > > > Best Regards, > Dave Chen > > Hi Dave, Thanks for your response. Looking for additional reference I also read [1], which gave me some insights on your design. There is a difference between both architectures which has a big impact on the implementation, so I think it would be wise to explain it; OpenStack currently has no clear definition of cluster as a migration-domain the same way oVirt has. So this means you cannot use this benefit of oVirt which provides you a domain where all VMs should be able to freely migrate from any host to any other host. In OpenStack you may have more than one scheduling service, which means you may scale very large numbers of scheduling requests. In oVirt's current implementation, it will be handled by the same process, so every scheduling delay should be carefully considered to avoid a performance hit. In my suggestion of a cluster level policy, you will get the trust level you need without changing the oVirt scheduler at all(!!!), so you are using the current concepts while avoiding any performance issue you may introduce by adding trust to the scheduling logic. As you can see this should give you a much cleaner, simpler and safer implementation. Working in cluster level will require a different implementation in the engine side to make sure the cluster complies with the trust level you want. The Attestation broker and caching are still needed, but the whole scheduling part should be removed. Obviously this will give you a completely different API as well as UI and potentially OVF, which will make current implementation redundant. This is not an improvement, rather than a different design. I strongly suggest you re-think the process to better evaluate both options. Doron [1] https://wiki.openstack.org/wiki/TrustedComputingPools > -----Original Message----- > From: Doron Fediuck [mailto:dfediuck at redhat.com] > Sent: Thursday, March 28, 2013 10:43 PM > To: Ofri Masad > Cc: engine-devel at ovirt.org; Chen, Wei D > Subject: Re: [Engine-devel] Open Attestation integration with oVirt engine > proposal has submitted patchset5 for your review > > ----- Original Message ----- > > From: "Ofri Masad" > > To: "Wei D Chen" > > Cc: engine-devel at ovirt.org > > Sent: Thursday, March 28, 2013 12:05:02 PM > > Subject: Re: [Engine-devel] Open Attestation integration with oVirt > > engine proposal has submitted patchset5 for your review > > > > Hi Dave, > > > > I would like to raise again the question of the full cache flash for > > each stale cache entry found. > > This method can cause two unwanted situations: > > 1. Choosing untrusted host: lets say, for example that you have 1000 > > host in your pool. you look at the first host in the cache and find > > that its attestation hat expired. you refresh the entire pool (there > > are 1000 host, that must take some time). by the the time the last > > host was refreshed in the pool, the first host may already be expired > > again. but since you already checked it - you keep on with your flow > > and select that host, even so it has expired and may as well be > > untrusted. > > > > 2. infinite loop: lets say we'll try to fix what I've described in > > 1. then, we need to check again if the host has expired before we > > select it. if it is, the entire refresh process starts again. this > > could potentially go on forever (unless I'm missing something, and > > the expiration is much longer then the full re-cache process). > > > > Instead of re-caching the full cache we can do as follows: > > - hold the cache entries sorted by expiration (if the expiration > > time is the same for all hosts, so a queue is enough). > > - each time we need a new trusted host - select from the unexpired > > hosts, refresh all expired hosts (in one query). > > - if all hosts are expired - we can wait for the first host to be > > defined trusted by the attestation server and select that host. > > > > Ofri > > > > > > Dave, adding another suggestion on top of Ofri's; > > Generally speaking, a cluster of hosts defines many joint features (such as > CPU level), which means that in the same cluster we would expect to be able > to freely migrate a VM from one host to another. > > Current trust-pools design is breaking this concept, as you introduce a state > where a VM cannot migrate from a 'safe' host into an 'unsafe' > host. > > This leads me to the suggestion of having attestation as a cluster policy > rather than a VM-level property. It means that all hosts in this cluster are > constantly being monitored to be safe. If a host is declared as unsafe in > the Attestation server, it will become non-operational in the engine. This > will simplify the implementation since you have everything ready for you > once you have a 'safe' cluster and no need to do any VM-level changes. > > So in this way you keep current concepts while simplifying the implementation > with very little worries of performance issues. > > Can you please share your thoughts on this suggestion? > > > ----- Original Message ----- > > > From: "Wei D Chen" > > > To: engine-devel at ovirt.org > > > Sent: Friday, March 22, 2013 11:34:55 AM > > > Subject: [Engine-devel] Open Attestation integration with oVirt > > > engine proposal has submitted patchset5 for your review > > > > > > Hi all, > > > > > > Before submitting this patch set, we has updated our design page, > > > and new feature about VM template has added to this patchset. In > > > patchset a lot of frontend changes has been imported. > > > Welcome to review our patchset and thanks advance for your > > > suggestion. > > > > > > > > > Detailed description: http://wiki.ovirt.org/Trusted_compute_pools > > > > > > In this patch set, follow changes has been introduced: > > > > > > 1. GUI changes to support for creating a trusted VM on a trusted > > > physical host. > > > 2. View/Edit VM changes to enable end user switch between three run > > > on options. > > > 3. Template relevant changes to support end user create a trusted VM > > > template and create trusted VM based on this template afterwards. > > > 4. Bug fixing and code cleanup. > > > 5. wiki design page update. > > > > > > > > > > > > Best Regards, > > > Dave Chen > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From yzaslavs at redhat.com Tue Apr 2 07:15:06 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Tue, 2 Apr 2013 03:15:06 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <4409558F-4634-48AD-870E-EEC39A68A5E7@gmail.com> References: <1442496988.16060758.1364484694306.JavaMail.root@redhat.com> <416667521.234829.1364852103221.JavaMail.root@redhat.com> <2076126807.440539.1364880248853.JavaMail.root@redhat.com> <2012118280.451038.1364884493689.JavaMail.root@redhat.com> <4409558F-4634-48AD-870E-EEC39A68A5E7@gmail.com> Message-ID: <1145373845.369568.1364886906787.JavaMail.root@redhat.com> Hi all, Sorry for my late response on the issue, I will try to cover as many issues as possible in this email and other emails ----- Original Message ----- > From: "Liran Zelkha" > To: "Laszlo Hornyak" > Cc: engine-devel at ovirt.org > Sent: Tuesday, April 2, 2013 9:37:28 AM > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > Hi Laszlo, > > I'm currently in the process of adding a caching layer on top of > JdbcTemplate, which would greatly reduce the number of database activities > we have, so that would solve the last item you raised. +1 On that approach - some of us already talked about the need to have caching AT LEAST for the static parts. > I didn't mean the ORM performance is caused by the mapping. I think the > problem lies in the fact that we will modify our code to have batch updates > for most insert activities - a thing that is impossible in JPA/Hibernate. > So, if we'll have some code in SQL and some in ORM - I prefer we stick all > code to SQL? > > On Apr 2, 2013, at 9:34 AM, Laszlo Hornyak wrote: > > > Hi Liran, > > > > I agree that ORM tools in general have to add some mapping overhead, but > > that overhead is very small compared to the time needed by the database > > interaction. > > ORM tools sometimes generate SQL statements that we could imagine being > > better, I do not think they are as hard for the DB as for example the ones > > generated by searchbackend. Also, we can do rdbms specific optimizations > > when needed. > > Plus we could finally have some caching in ovirt engine and the code would > > not have to read e.g. the DC record again and again. There are some more > > like that. > > > > Therefore having a JPA could improve the performance in engine. > > > > Laszlo > > > > ----- Original Message ----- > >> From: "Liran Zelkha" > >> To: "Eli Mesika" > >> Cc: engine-devel at ovirt.org > >> Sent: Tuesday, April 2, 2013 7:24:08 AM > >> Subject: Re: [Engine-devel] Move SQL out of stored procedures > >> > >> I also apologize for jumping in late... > >> I think concerning SQL injection we'll be covered by using > >> PreparedStatements. Since we're using SpringJDBC, most of our code uses > >> PreparedStatements anyway. > >> Concerning ORM - I feel it won't really be beneficial to us. I know of > >> very > >> few projects who can actually be cross-database, and just maintaining > >> schema > >> creation scripts for different databases can be too difficult to maintain. > >> Also, from a performance perspective, ORM performs worse than regular SQL > >> (or stored procedures), so it wouldn't be the direction I choose. > >> I think we should keep using SpringJDBC with either SQL or stored > >> procedures > >> (doesn't really matter, whatever is easier to maintain and performs > >> faster) > >> and maybe add a better, more generic, RowMapper class. +1 on that approach - I remind you all that our data model is a bit complex - for example - we have entities that are composed of views - VM which is based on static, dynamic and statistics information. Modeling this with hibernate is problematic. In addition, we will have to introduce a custom mapper for pgsql uuid to either out Guid/NGuid or (as others already suggested) java.util.UUID , hence the desire to have 100% portability already breaks. Barein mind not all databases support UUID as native types - this is something we need to think of (maybe outside the context of this discussion) - I can tell you that from what I saw so far, mssql , postgresql and h2 databases DO support it. In addition we have MLA related stored procedures which have to contain logic and trying to model them as JPA queries will definitely hurt performance. If we do want to go to hibernate approach (again) as lessons from last time I would: a. Not try to solve the complex cases - keep hibernate/JPA for relatively CRUD operations - for more complex ones - keep stored procedures (I remind you it is possible to invoke native SQL/Stored procedures from JPA). b. Consider having a layer of objects (DTOs) that their sole purpose is to work with the JPA layer (let's say that they are in package of org.ovirt.engine.core.dal.entities) and they will map to our existing business entities. The advantage in this approach is that our business entities (which are currently shared with frontend) will not need to be adjusted/annotated with hibernate/JPA annotations. The disadvantages in this approach is that we will have a double group of entities - one for DAL and one for BLL/frontend (and this brings up the question on what are the plans of using the REST-API with frontend?) > >> > >> ----- Original Message ----- > >> From: "Eli Mesika" > >> To: engine-devel at ovirt.org > >> Sent: Tuesday, April 2, 2013 12:35:03 AM > >> Subject: Re: [Engine-devel] Move SQL out of stored procedures > >> > >> > >> > >> ----- Original Message ----- > >>> From: "Laszlo Hornyak" > >>> To: "Libor Spevak" > >>> Cc: "Juan Hernandez" , engine-devel at ovirt.org > >>> Sent: Thursday, March 28, 2013 5:31:34 PM > >>> Subject: Re: [Engine-devel] Move SQL out of stored procedures > >>> > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Libor Spevak" > >>>> To: "Itamar Heim" > >>>> Cc: "Juan Hernandez" , engine-devel at ovirt.org > >>>> Sent: Thursday, March 28, 2013 4:04:20 PM > >>>> Subject: Re: [Engine-devel] Move SQL out of stored procedures > >>>> > >>>> Hi, > >>>> > >>>> apart from SQL vs. stored procedures discussion, I am trying to > >>>> understand what we can get if we support more databases... > >> > >> Sorry for joining this discussion so late (I was in a vacation) > >> anyway > >> two points missing from SQL VS. SP are > >> 1) security - With plain SQL we will have to handle SQL Injection > >> 2) It is more economic to pass a call to SP than the full SQL on the > >> wire... > >> > >> > >>>> > >>>> Some points: > >>>> 1. Is there a real need by end-users/customers to run it on e.g. > >>>> Oracle > >>>> only? (performance, stability, easier administration). > >>> > >>> Usually companies have one database and they are trying to stick to that > >>> one. > >>> Having two doubles the resource needs, you need one more DBA team, care > >>> for > >>> mirrors, backups. So it almost doubles the costs. > >> > >> Generally, I agree with Alon B L , if you have to support X DBs you are > >> not > >> doubling the effort by X > >> Actually, we had already experience with that when we supported both MS > >> SQL & > >> Postgres > >> I believe that as we have some customers with large installations, > >> performance counts and the best way (and sometimes teh only way) id the DB > >> layer > >> > >>> This is why I frequently hear people asking if we plan to support XyDB in > >>> the > >>> future. PostgreSQL is cool, but those who already use MySQL/MariaDB, they > >>> just do not want one more. > >>> > >>>> What is the future of PostgreSQL? > >>>> > >>>> 2. Is it decided by architectural board, what kind of databases we > >>>> would > >>>> like to support? (cannot support any db) > >>> > >>> With a JPA we could support most mainstream relational databases, but in > >>> my > >>> opinion 99 percent of people run oracle, mysql/mariadb or postgresql. So > >>> maybe we do not have to think in big number of database engines. > >>> This is theoretical since JPA is still on wishlist :( > >>> > >>>> > >>>> 3. Are we talking about the Engine only, or there will be a need to > >>>> rewrite ETL mappings and upgrade DWH database, or maybe modify > >>>> JasperReports templates (simply, some DB types behave differently)? > >>>> Maybe we can look at JasperSoft solution, they support more > >>>> databases. > >> > >> IMHO , ETL & DWH are perfect candidates for NO SQL which is already > >> supported > >> by Jasper +1 Here about NoSQL for ETL & DWH. > >> > >>>> > >>>> 4. Current full/incremental upgrade process of PostgreSQL is IMHO > >>>> very > >>>> good tuned (it is similar to dbmaintain.org tool - Java > >>>> implementation - > >>>> I used successfully on one project - after some changes of course). I > >>>> do > >>>> not believe we can use or easily develop general upgrade/migration > >>>> tool, > >>>> and XML based (I am sorry Alissa, not sure about Liquibase, I haven't > >>>> studied it deeply, but there is a need to incrementally change db > >>>> objects, but sometimes also to migrate data to new structures, the > >>>> most > >>>> flexible and quickest is to do it using native SQL, but yes, it > >>>> depends > >>>> on the project needs...). > >> > >> I had evaluated Liquibase and I think that managing your DB upgrades via > >> XML > >> is very unfriendly and very limited as you reach complex upgrades as we > >> had > >> in the past. > >> Just think of the tables in which we change the key from long to UUID , > >> there > >> is no way to do that in such tools > >> > >>>> > >>>> 5. As a developer, with every new column I need to write upgrade > >>>> scripts, prepare test environments and test all scenarios several > >>>> times > >>>> on different databases, so time-consuming. > >> > >> Did it also , again , since our SQL is 90% simple , the effort of writing > >> a > >> SP for more than one DB is not so high (and you have free converters you > >> can > >> use for that) > >> > >> Finally, embedded SQL in the Java code is not a good idea, it will be hard > >> to > >> maintain it and it is not advancing us in supporting more than one > >> database. > >> We have already SQL generated in the Java code on the search engine and > >> IMHO > >> this is one of the parts in the applications that needs a rewrite ... > >> > >>>> > >>>> > >>>> On 27.3.2013 13:53, Itamar Heim wrote: > >>>>> On 03/26/2013 08:39 PM, Alon Bar-Lev wrote: > >>>>>> > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Juan Hernandez" > >>>>>>> To: engine-devel at ovirt.org > >>>>>>> Sent: Tuesday, March 26, 2013 7:34:04 PM > >>>>>>> Subject: [Engine-devel] Move SQL out of stored procedures > >>>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> I would like to start a discussion about the subject. I think > >>>>>>> this is > >>>>>>> something we need to do if one day we want to be able to use any > >>>>>>> database other than PostgreSQL. > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> I think that database layer is a software interface like any other > >>>>>> software interface, if done properly, a dba can convert the stored > >>>>>> procedure to any other database without any code change. > >>>>>> > >>>>>> This way the database specific implementation lives within the > >>>>>> database and maintained by the designated dba. > >>>>>> > >>>>>> Fixups and optimizations can be done in database without touching > >>>>>> the > >>>>>> code. > >>>>>> > >>>>>> Backward compatibility layer is much simpler to implement based on > >>>>>> stored procedures than complex set of views and tables. > >>>>>> > >>>>>> Also, accessing the database via different technologies is simpler > >>>>>> if > >>>>>> there is maintained database interface (stored procedures). > >>>>>> > >>>>>> I've seen hibernate based java applications that promised to be > >>>>>> database independent but at the edges when performance counts, the > >>>>>> DAO became HQL, then a special dialect and finally database > >>>>>> specific > >>>>>> SQLS. > >>>>> > >>>>> there may be db specific optimization/logic, but I don't see why we > >>>>> need STPs for 80% (if not more) of the CRUD and basic queries. > >>>>> > >>>>> I also agree with Tal later in the thread that its a good question > >>>>> if > >>>>> we can't find a better solution than re-writing the sql's in the > >>>>> code > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >> _______________________________________________ > >> 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 lhornyak at redhat.com Tue Apr 2 07:17:25 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Tue, 2 Apr 2013 03:17:25 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <4409558F-4634-48AD-870E-EEC39A68A5E7@gmail.com> References: <1442496988.16060758.1364484694306.JavaMail.root@redhat.com> <416667521.234829.1364852103221.JavaMail.root@redhat.com> <2076126807.440539.1364880248853.JavaMail.root@redhat.com> <2012118280.451038.1364884493689.JavaMail.root@redhat.com> <4409558F-4634-48AD-870E-EEC39A68A5E7@gmail.com> Message-ID: <565832744.458372.1364887045437.JavaMail.root@redhat.com> Hi Liran, ----- Original Message ----- > From: "Liran Zelkha" > To: "Laszlo Hornyak" > Cc: "Liran Zelkha" , engine-devel at ovirt.org > Sent: Tuesday, April 2, 2013 8:37:28 AM > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > Hi Laszlo, > > I'm currently in the process of adding a caching layer on top of > JdbcTemplate, which would greatly reduce the number of database activities > we have, so that would solve the last item you raised. That's a great news! Thank you! > I didn't mean the ORM performance is caused by the mapping. I think the > problem lies in the fact that we will modify our code to have batch updates > for most insert activities - a thing that is impossible in JPA/Hibernate. > So, if we'll have some code in SQL and some in ORM - I prefer we stick all > code to SQL? I think you can do this with a JPAQL in JPA, but anyway, yes, some code would very likely have to be in rdbms-specific SQL statements. > > On Apr 2, 2013, at 9:34 AM, Laszlo Hornyak wrote: > > > Hi Liran, > > > > I agree that ORM tools in general have to add some mapping overhead, but > > that overhead is very small compared to the time needed by the database > > interaction. > > ORM tools sometimes generate SQL statements that we could imagine being > > better, I do not think they are as hard for the DB as for example the ones > > generated by searchbackend. Also, we can do rdbms specific optimizations > > when needed. > > Plus we could finally have some caching in ovirt engine and the code would > > not have to read e.g. the DC record again and again. There are some more > > like that. > > > > Therefore having a JPA could improve the performance in engine. > > > > Laszlo > > > > ----- Original Message ----- > >> From: "Liran Zelkha" > >> To: "Eli Mesika" > >> Cc: engine-devel at ovirt.org > >> Sent: Tuesday, April 2, 2013 7:24:08 AM > >> Subject: Re: [Engine-devel] Move SQL out of stored procedures > >> > >> I also apologize for jumping in late... > >> I think concerning SQL injection we'll be covered by using > >> PreparedStatements. Since we're using SpringJDBC, most of our code uses > >> PreparedStatements anyway. > >> Concerning ORM - I feel it won't really be beneficial to us. I know of > >> very > >> few projects who can actually be cross-database, and just maintaining > >> schema > >> creation scripts for different databases can be too difficult to maintain. > >> Also, from a performance perspective, ORM performs worse than regular SQL > >> (or stored procedures), so it wouldn't be the direction I choose. > >> I think we should keep using SpringJDBC with either SQL or stored > >> procedures > >> (doesn't really matter, whatever is easier to maintain and performs > >> faster) > >> and maybe add a better, more generic, RowMapper class. > >> > >> ----- Original Message ----- > >> From: "Eli Mesika" > >> To: engine-devel at ovirt.org > >> Sent: Tuesday, April 2, 2013 12:35:03 AM > >> Subject: Re: [Engine-devel] Move SQL out of stored procedures > >> > >> > >> > >> ----- Original Message ----- > >>> From: "Laszlo Hornyak" > >>> To: "Libor Spevak" > >>> Cc: "Juan Hernandez" , engine-devel at ovirt.org > >>> Sent: Thursday, March 28, 2013 5:31:34 PM > >>> Subject: Re: [Engine-devel] Move SQL out of stored procedures > >>> > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Libor Spevak" > >>>> To: "Itamar Heim" > >>>> Cc: "Juan Hernandez" , engine-devel at ovirt.org > >>>> Sent: Thursday, March 28, 2013 4:04:20 PM > >>>> Subject: Re: [Engine-devel] Move SQL out of stored procedures > >>>> > >>>> Hi, > >>>> > >>>> apart from SQL vs. stored procedures discussion, I am trying to > >>>> understand what we can get if we support more databases... > >> > >> Sorry for joining this discussion so late (I was in a vacation) > >> anyway > >> two points missing from SQL VS. SP are > >> 1) security - With plain SQL we will have to handle SQL Injection > >> 2) It is more economic to pass a call to SP than the full SQL on the > >> wire... > >> > >> > >>>> > >>>> Some points: > >>>> 1. Is there a real need by end-users/customers to run it on e.g. > >>>> Oracle > >>>> only? (performance, stability, easier administration). > >>> > >>> Usually companies have one database and they are trying to stick to that > >>> one. > >>> Having two doubles the resource needs, you need one more DBA team, care > >>> for > >>> mirrors, backups. So it almost doubles the costs. > >> > >> Generally, I agree with Alon B L , if you have to support X DBs you are > >> not > >> doubling the effort by X > >> Actually, we had already experience with that when we supported both MS > >> SQL & > >> Postgres > >> I believe that as we have some customers with large installations, > >> performance counts and the best way (and sometimes teh only way) id the DB > >> layer > >> > >>> This is why I frequently hear people asking if we plan to support XyDB in > >>> the > >>> future. PostgreSQL is cool, but those who already use MySQL/MariaDB, they > >>> just do not want one more. > >>> > >>>> What is the future of PostgreSQL? > >>>> > >>>> 2. Is it decided by architectural board, what kind of databases we > >>>> would > >>>> like to support? (cannot support any db) > >>> > >>> With a JPA we could support most mainstream relational databases, but in > >>> my > >>> opinion 99 percent of people run oracle, mysql/mariadb or postgresql. So > >>> maybe we do not have to think in big number of database engines. > >>> This is theoretical since JPA is still on wishlist :( > >>> > >>>> > >>>> 3. Are we talking about the Engine only, or there will be a need to > >>>> rewrite ETL mappings and upgrade DWH database, or maybe modify > >>>> JasperReports templates (simply, some DB types behave differently)? > >>>> Maybe we can look at JasperSoft solution, they support more > >>>> databases. > >> > >> IMHO , ETL & DWH are perfect candidates for NO SQL which is already > >> supported > >> by Jasper > >> > >>>> > >>>> 4. Current full/incremental upgrade process of PostgreSQL is IMHO > >>>> very > >>>> good tuned (it is similar to dbmaintain.org tool - Java > >>>> implementation - > >>>> I used successfully on one project - after some changes of course). I > >>>> do > >>>> not believe we can use or easily develop general upgrade/migration > >>>> tool, > >>>> and XML based (I am sorry Alissa, not sure about Liquibase, I haven't > >>>> studied it deeply, but there is a need to incrementally change db > >>>> objects, but sometimes also to migrate data to new structures, the > >>>> most > >>>> flexible and quickest is to do it using native SQL, but yes, it > >>>> depends > >>>> on the project needs...). > >> > >> I had evaluated Liquibase and I think that managing your DB upgrades via > >> XML > >> is very unfriendly and very limited as you reach complex upgrades as we > >> had > >> in the past. > >> Just think of the tables in which we change the key from long to UUID , > >> there > >> is no way to do that in such tools > >> > >>>> > >>>> 5. As a developer, with every new column I need to write upgrade > >>>> scripts, prepare test environments and test all scenarios several > >>>> times > >>>> on different databases, so time-consuming. > >> > >> Did it also , again , since our SQL is 90% simple , the effort of writing > >> a > >> SP for more than one DB is not so high (and you have free converters you > >> can > >> use for that) > >> > >> Finally, embedded SQL in the Java code is not a good idea, it will be hard > >> to > >> maintain it and it is not advancing us in supporting more than one > >> database. > >> We have already SQL generated in the Java code on the search engine and > >> IMHO > >> this is one of the parts in the applications that needs a rewrite ... > >> > >>>> > >>>> > >>>> On 27.3.2013 13:53, Itamar Heim wrote: > >>>>> On 03/26/2013 08:39 PM, Alon Bar-Lev wrote: > >>>>>> > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Juan Hernandez" > >>>>>>> To: engine-devel at ovirt.org > >>>>>>> Sent: Tuesday, March 26, 2013 7:34:04 PM > >>>>>>> Subject: [Engine-devel] Move SQL out of stored procedures > >>>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> I would like to start a discussion about the subject. I think > >>>>>>> this is > >>>>>>> something we need to do if one day we want to be able to use any > >>>>>>> database other than PostgreSQL. > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> I think that database layer is a software interface like any other > >>>>>> software interface, if done properly, a dba can convert the stored > >>>>>> procedure to any other database without any code change. > >>>>>> > >>>>>> This way the database specific implementation lives within the > >>>>>> database and maintained by the designated dba. > >>>>>> > >>>>>> Fixups and optimizations can be done in database without touching > >>>>>> the > >>>>>> code. > >>>>>> > >>>>>> Backward compatibility layer is much simpler to implement based on > >>>>>> stored procedures than complex set of views and tables. > >>>>>> > >>>>>> Also, accessing the database via different technologies is simpler > >>>>>> if > >>>>>> there is maintained database interface (stored procedures). > >>>>>> > >>>>>> I've seen hibernate based java applications that promised to be > >>>>>> database independent but at the edges when performance counts, the > >>>>>> DAO became HQL, then a special dialect and finally database > >>>>>> specific > >>>>>> SQLS. > >>>>> > >>>>> there may be db specific optimization/logic, but I don't see why we > >>>>> need STPs for 80% (if not more) of the CRUD and basic queries. > >>>>> > >>>>> I also agree with Tal later in the thread that its a good question > >>>>> if > >>>>> we can't find a better solution than re-writing the sql's in the > >>>>> code > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >> _______________________________________________ > >> 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 Tue Apr 2 07:19:31 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Tue, 2 Apr 2013 03:19:31 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <5152A932.6050707@redhat.com> References: <5151DC0C.2040909@redhat.com> <5152A932.6050707@redhat.com> Message-ID: <158492723.370424.1364887171225.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Libor Spevak" > To: "Juan Hernandez" > Cc: engine-devel at ovirt.org > Sent: Wednesday, March 27, 2013 10:09:22 AM > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > Hi, > I would recommend always to avoid hard coding SQL into Java code. It is > very hard to maintain and read. > If there is something, which prevents using JPA/Hibernate, e.g. the > database relational model doesn't reflect the object-oriented domain > very well or we have to live with many stored procedures concurrently, I > would choose a framework, which enables to externalize the SQL code > (into XML). > > I worked on a larger project(s) with a lot of PL/SQL code, we moved to > myBatis (previously iBatis) very soon for Java backend: > > https://code.google.com/p/mybatis/ > > Libor I used a similar approach at past project - not with iBatis though, but a "in house" implementation of such framework. I think this idea is worth considering. > > > On 26.3.2013 18:34, Juan Hernandez wrote: > > Hello, > > > > I would like to start a discussion about the subject. I think this is > > something we need to do if one day we want to be able to use any > > database other than PostgreSQL. > > > > I did an small example of what it takes and how it looks like to have > > the SQL code into the DAOs: > > > > http://gerrit.ovirt.org/13347 > > > > It isn't rocket science, it isn't an exciting task, it isn't fun, but > > something I think we should eventually do. > > > > I appreciate any comment about how and when to do this, including > > those saying that instead of this primitive approach we should use > > this or that ORM framework. > > > > Regards, > > Juan Hernandez > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From liran.zelkha at gmail.com Tue Apr 2 07:21:42 2013 From: liran.zelkha at gmail.com (Liran Zelkha) Date: Tue, 2 Apr 2013 10:21:42 +0300 Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <158492723.370424.1364887171225.JavaMail.root@redhat.com> References: <5151DC0C.2040909@redhat.com> <5152A932.6050707@redhat.com> <158492723.370424.1364887171225.JavaMail.root@redhat.com> Message-ID: <4B3D7BE9-B0AD-41FE-9A08-CC828FB26132@gmail.com> Hi I think externalizing SQL can lead to a VERY difficult maintenance. But, as long as we stick to SQL (or stored procedures, just not ORM), I don't mind? On Apr 2, 2013, at 10:19 AM, Yair Zaslavsky wrote: > > > ----- Original Message ----- >> From: "Libor Spevak" >> To: "Juan Hernandez" >> Cc: engine-devel at ovirt.org >> Sent: Wednesday, March 27, 2013 10:09:22 AM >> Subject: Re: [Engine-devel] Move SQL out of stored procedures >> >> Hi, >> I would recommend always to avoid hard coding SQL into Java code. It is >> very hard to maintain and read. >> If there is something, which prevents using JPA/Hibernate, e.g. the >> database relational model doesn't reflect the object-oriented domain >> very well or we have to live with many stored procedures concurrently, I >> would choose a framework, which enables to externalize the SQL code >> (into XML). >> >> I worked on a larger project(s) with a lot of PL/SQL code, we moved to >> myBatis (previously iBatis) very soon for Java backend: >> >> https://code.google.com/p/mybatis/ >> >> Libor > > I used a similar approach at past project - not with iBatis though, but a "in house" implementation of such framework. > I think this idea is worth considering. > >> >> >> On 26.3.2013 18:34, Juan Hernandez wrote: >>> Hello, >>> >>> I would like to start a discussion about the subject. I think this is >>> something we need to do if one day we want to be able to use any >>> database other than PostgreSQL. >>> >>> I did an small example of what it takes and how it looks like to have >>> the SQL code into the DAOs: >>> >>> http://gerrit.ovirt.org/13347 >>> >>> It isn't rocket science, it isn't an exciting task, it isn't fun, but >>> something I think we should eventually do. >>> >>> I appreciate any comment about how and when to do this, including >>> those saying that instead of this primitive approach we should use >>> this or that ORM framework. >>> >>> Regards, >>> Juan Hernandez >> >> _______________________________________________ >> 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 jhernand at redhat.com Tue Apr 2 07:41:40 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Tue, 02 Apr 2013 09:41:40 +0200 Subject: [Engine-devel] Sandro Bonazzola as a tools maintainer In-Reply-To: <1127688207.3914753.1363789429350.JavaMail.root@redhat.com> References: <1127688207.3914753.1363789429350.JavaMail.root@redhat.com> Message-ID: <515A8BB4.3070905@redhat.com> On 03/20/2013 03:23 PM, Ofer Schreiber wrote: > +1 > +1 > ----- Original Message ----- >> I would like to propose that we add Sandro Bonazzola as a maintainer >> for >> the Ovirt ISO Uploader, Image Uploader and Log Collector. He too has >> been enormously helpful with the maintenance of the tools. >> >> Thanks, >> Keith Robertson -- 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 mkolesni at redhat.com Tue Apr 2 09:17:31 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Tue, 2 Apr 2013 05:17:31 -0400 (EDT) Subject: [Engine-devel] FeatureSupported and compatibility versions In-Reply-To: <51543BF5.3050505@redhat.com> References: <36623975.7044697.1364386718971.JavaMail.root@redhat.com> <51543BF5.3050505@redhat.com> Message-ID: <1842623267.574910.1364894251176.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/27/2013 05:48 PM, Mike Kolesnik wrote: > > ----- Original Message ----- > > > > On 03/20/2013 08:20 PM, Yair Zaslavsky wrote: > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Shireesh Anjal" To: "Mike Kolesnik" > > > > > Cc: engine-devel at ovirt.org Sent: Wednesday, > > > > > March > > > > > 20, > > > > > 2013 4:47:08 PM > > > > > > > > > > > > > > > Subject: Re: [Engine-devel] FeatureSupported and compatibility > > > > > > > > > > > > > > > versions > > > > > > > > > > > > > > > On 03/18/2013 01:11 PM, Shireesh Anjal wrote: > > > > > > > > > > > > > > > > On 03/18/2013 12:59 PM, Mike Kolesnik wrote: > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The current mechanism in oVirt to check whether a feature is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > supported > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > in a particular compatibility version is to use the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > FeatureSupported > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > class. e.g. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion()) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Checks whether the "network linking" feature is supported for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > VM's cluster compatibility version. This internally checks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > whether > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > value of the corresponding config (NetworkLinkingSupported) for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > given compatibility version is true/false. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not sure if this is a good idea, since a feature is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > typically > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > supported "from" a particular version. E.g. Gluster support was > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > introduced in 3.1, and it continues to be available in all > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > subsequent > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > versions. So I see no point in adding configuration for every > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > version > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > indicating whether the feature is supported in that version or > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > not. I > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > suggest to use either of the following options: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You can "merge" the configs into a single config when older > > > > > > > > > > > > > > > > > > > > > > > > > > > > versions > > > > > > > > > > > > > > > > > > > > > > > > > > > > go out of the supported versions for the system. > > > > > > > > > > > > > > > > > > > > > > > > > > > > i.e. in 4.0 you can have upgrade script that merges all > > > > > > > > > > > > > > > > > > > > > > > > > > > > GlusterFeatureSupported to one entry instead of several. > > > > > > > > > > > > > > > > > > > > > > > > > > Why are we even storing this information in config? Is this > > > > > > > > > > > > > > > something > > > > > > > > > > > > > > > that can be "configured" at customer site? > > > > > > > > > > > > > > As previously explained (but off list :) ) , Config gives you the > > > > > > > > > > ability to have a cachable "map" of entry (i.e - "feature name") > > > > > > > > > > per version and value. > > > > > > > > > > I guess it was convinient for the developers to use that. > > > > > > > > > > I also mentioned that customers/oVirt users should config the > > > > > > > > > > entries of vdc_options using engine-config tool only. > > > > > > > > > > Not all entries are exposed via engine-config.properties (and no, > > > > > > > > > > not just "is feature supported" entries are hidden). > > > > > > > > > > > > > > 1) Instead of using a boolean config for each version, use a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > single > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > string config that indicates the "supported from" version e.g. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > GlusterSupportedFrom = 3.1. There could be rare cases where a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > feature, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > for some reason, is removed in some release. In such cases, we > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > could > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > use > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > one additional config for the "supported to" version. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) Continue with the boolean approach, but do not have entries > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > every > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > version; rather make use of the "default value" for majority of > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > cases, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > and add the explicit version mapping for the minority e.g. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > GlusterSupported = true by default, and false in case of 3.0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (only > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > one > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > config required for 3.0) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not sure why we would want to complicate this simple > > > > > > > > > > > > > > > > > > > > > > > > > > > > mechanism? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is there much to gain? > > > > > > > > > > > > > > > > > > > > > > > > > > > I think option 1 suggested above is simpler - to implement as > > > > > > > > > > > > > > > > > > > > > well > > > > > > > > > > > > > > > > > > > > > as > > > > > > > > > > > > > > > > > > > > > to understand. > > > > > > > > > > > > > > > > > > > > > Let me give you an example of why I don't like current mechanism. > > > > > > > > > > > > > > > > > > > > > I > > > > > > > > > > > > > > > > > > > > > introduce a version check for a feature that was introduced in > > > > > > > > > > > > > > > > > > > > > 3.1. > > > > > > > > > > > > > > > > > > > > > I'm being asked now to add three entries in config > > > > > > > > > > > > > > > > > > > > > 3.0 - false > > > > > > > > > > > > > > > > > > > > > 3.1 - true > > > > > > > > > > > > > > > > > > > > > 3.2 - true > > > > > > > > > > > > > > > > > > > > > It will also mean that when 3.3 goes out, someone has to make > > > > > > > > > > > > > > > > > > > > > sure > > > > > > > > > > > > > > > > > > > > > that another entry is added for 3.3-true. I think it is not > > > > > > > > > > > > > > > > > > > > > logical > > > > > > > > > > > > > > > > > > > > > as > > > > > > > > > > > > > > > > > > > > > well as scalable if you have more versions. And it sounds far > > > > > > > > > > > > > > > > > > > > > more > > > > > > > > > > > > > > > > > > > > > complex (to maintain) than just having > > > > > > > > > > > > > > > > > > > > > SupportedFrom = 3.1 > > > > > > > > > > > > > > > > > > > > > So I would like to know if there are any objections to my > > > > > > > > > > > > > > > > > > > > > proposal. > > > > > > > > > > > > > > > > > > > > > I > > > > > > > > > > > > > > > > > > > > > intend to use this for at least the gluster related features. > > > > > > > > > > > > > > > > > > I've sent a patch ( http://gerrit.ovirt.org/12970 ) with following > > > > > > changes: > > > > > > 1) Introduced CompatibilityUtils that provides utility methods for > > > > > > checking if a given feature is supported in the config. One method to > > > > > > check based on boolean values (as is being done today for virt > > > > > > features), and nother to check based on a range (from, to) which I > > > > > > would > > > > > > like to use for gluster features. > > > > > > 2) Renamed FeatureSupported to VirtFeatureSupported, and made it use > > > > > > the > > > > > > first utility method from CompatibilityUtils > > > > > > 3) Introduced GlusterFeatureSupported for gluster features, which > > > > > > uses > > > > > > the second utility method from CompatibilityUtils > > > > > > Key advantage here is that > > > > > > - we don't have to touch any virt specifc source for adding > > > > > > compatibility checks for gluster features > > > > > > - virt features continue to use the existing boolean config check > > > > > > Any comments / suggestions / reviews will be highly appreciated :) > > > > > I think splitting to two classes is OK, but the underlying mechanism IMO > > should be as Omer suggested: > > > Use the default value from the java config file, and if in the DB there is > > a > > version specific value then use it for that version only. > > Review comments here are on the contrary: > http://gerrit.ovirt.org/#/c/12970/5/backend/manager/dbscripts/upgrade/pre_upgrade/0000_config.sql The comment in the review simply states that the mechanism is probably broken, not that that's the way it has to be done. > > I don't think "From, To, etc" is a good design, it's not a standard way and > > is very restrictive. > > Can you please explain in what way is it restrictive? > Also, what is the "etc" you are referring to? What if for certain version it is not supported, you add "except"? Or do you specify 2 ranges? Starting to add from/to creates a limited design of one range, which would be difficult to tune if necessary. I think the design generally for config values is very simple and suits us well - use the default value, unless a specific version is configured differently. This way you can specify the feature is supported, and disable it for specific versions. I think this direction gives us the flexibility that we would like to have. Currently it doesn't work that way, but I think it's not impossible to change, and more worthwhile than introducing a new mechanism. > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shireesh > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emesika at redhat.com Tue Apr 2 09:29:31 2013 From: emesika at redhat.com (Eli Mesika) Date: Tue, 2 Apr 2013 05:29:31 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <1145373845.369568.1364886906787.JavaMail.root@redhat.com> References: <1442496988.16060758.1364484694306.JavaMail.root@redhat.com> <416667521.234829.1364852103221.JavaMail.root@redhat.com> <2076126807.440539.1364880248853.JavaMail.root@redhat.com> <2012118280.451038.1364884493689.JavaMail.root@redhat.com> <4409558F-4634-48AD-870E-EEC39A68A5E7@gmail.com> <1145373845.369568.1364886906787.JavaMail.root@redhat.com> Message-ID: <225436286.555924.1364894971340.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Yair Zaslavsky" > To: "Liran Zelkha" > Cc: engine-devel at ovirt.org > Sent: Tuesday, April 2, 2013 10:15:06 AM > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > > Hi all, > Sorry for my late response on the issue, I will try to cover as many issues > as possible in this email and other emails > > ----- Original Message ----- > > From: "Liran Zelkha" > > To: "Laszlo Hornyak" > > Cc: engine-devel at ovirt.org > > Sent: Tuesday, April 2, 2013 9:37:28 AM > > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > > > Hi Laszlo, > > > > I'm currently in the process of adding a caching layer on top of > > JdbcTemplate, which would greatly reduce the number of database activities > > we have, so that would solve the last item you raised. > > +1 On that approach - some of us already talked about the need to have > caching AT LEAST for the static parts. > > > > I didn't mean the ORM performance is caused by the mapping. I think the > > problem lies in the fact that we will modify our code to have batch updates > > for most insert activities - a thing that is impossible in JPA/Hibernate. > > So, if we'll have some code in SQL and some in ORM - I prefer we stick all > > code to SQL? > > > > > > On Apr 2, 2013, at 9:34 AM, Laszlo Hornyak wrote: > > > > > Hi Liran, > > > > > > I agree that ORM tools in general have to add some mapping overhead, but > > > that overhead is very small compared to the time needed by the database > > > interaction. > > > ORM tools sometimes generate SQL statements that we could imagine being > > > better, I do not think they are as hard for the DB as for example the > > > ones > > > generated by searchbackend. Also, we can do rdbms specific optimizations > > > when needed. > > > Plus we could finally have some caching in ovirt engine and the code > > > would > > > not have to read e.g. the DC record again and again. There are some more > > > like that. > > > > > > Therefore having a JPA could improve the performance in engine. > > > > > > Laszlo > > > > > > ----- Original Message ----- > > >> From: "Liran Zelkha" > > >> To: "Eli Mesika" > > >> Cc: engine-devel at ovirt.org > > >> Sent: Tuesday, April 2, 2013 7:24:08 AM > > >> Subject: Re: [Engine-devel] Move SQL out of stored procedures > > >> > > >> I also apologize for jumping in late... > > >> I think concerning SQL injection we'll be covered by using > > >> PreparedStatements. Since we're using SpringJDBC, most of our code uses > > >> PreparedStatements anyway. > > >> Concerning ORM - I feel it won't really be beneficial to us. I know of > > >> very > > >> few projects who can actually be cross-database, and just maintaining > > >> schema > > >> creation scripts for different databases can be too difficult to > > >> maintain. > > >> Also, from a performance perspective, ORM performs worse than regular > > >> SQL > > >> (or stored procedures), so it wouldn't be the direction I choose. > > >> I think we should keep using SpringJDBC with either SQL or stored > > >> procedures > > >> (doesn't really matter, whatever is easier to maintain and performs > > >> faster) > > >> and maybe add a better, more generic, RowMapper class. > > +1 on that approach - I remind you all that our data model is a bit complex - > for example - we have entities that are composed of views - VM which is > based on static, dynamic and statistics information. > Modeling this with hibernate is problematic. > In addition, we will have to introduce a custom mapper for pgsql uuid to > either out Guid/NGuid or (as others already suggested) java.util.UUID , > hence the desire to have 100% portability already breaks. > Barein mind not all databases support UUID as native types - this is > something we need to think of (maybe outside the context of this discussion) > - I can tell you that from what I saw so far, mssql , postgresql and h2 > databases DO support it. > In addition we have MLA related stored procedures which have to contain logic > and trying to model them as JPA queries will definitely hurt performance. > > If we do want to go to hibernate approach (again) as lessons from last time I > would: > a. Not try to solve the complex cases - keep hibernate/JPA for relatively > CRUD operations - for more complex ones - keep stored procedures (I remind > you it is possible to invoke native SQL/Stored procedures from JPA). > b. Consider having a layer of objects (DTOs) that their sole purpose is to > work with the JPA layer (let's say that they are in package of > org.ovirt.engine.core.dal.entities) and they will map to our existing > business entities. > The advantage in this approach is that our business entities (which are > currently shared with frontend) will not need to be adjusted/annotated with > hibernate/JPA annotations. > The disadvantages in this approach is that we will have a double group of > entities - one for DAL and one for BLL/frontend (and this brings up the > question on what are the plans of using the REST-API with frontend?) Hybrid solutions tend to waste much more time than they save ... > > > > > > > > >> > > >> ----- Original Message ----- > > >> From: "Eli Mesika" > > >> To: engine-devel at ovirt.org > > >> Sent: Tuesday, April 2, 2013 12:35:03 AM > > >> Subject: Re: [Engine-devel] Move SQL out of stored procedures > > >> > > >> > > >> > > >> ----- Original Message ----- > > >>> From: "Laszlo Hornyak" > > >>> To: "Libor Spevak" > > >>> Cc: "Juan Hernandez" , engine-devel at ovirt.org > > >>> Sent: Thursday, March 28, 2013 5:31:34 PM > > >>> Subject: Re: [Engine-devel] Move SQL out of stored procedures > > >>> > > >>> > > >>> > > >>> ----- Original Message ----- > > >>>> From: "Libor Spevak" > > >>>> To: "Itamar Heim" > > >>>> Cc: "Juan Hernandez" , engine-devel at ovirt.org > > >>>> Sent: Thursday, March 28, 2013 4:04:20 PM > > >>>> Subject: Re: [Engine-devel] Move SQL out of stored procedures > > >>>> > > >>>> Hi, > > >>>> > > >>>> apart from SQL vs. stored procedures discussion, I am trying to > > >>>> understand what we can get if we support more databases... > > >> > > >> Sorry for joining this discussion so late (I was in a vacation) > > >> anyway > > >> two points missing from SQL VS. SP are > > >> 1) security - With plain SQL we will have to handle SQL Injection > > >> 2) It is more economic to pass a call to SP than the full SQL on the > > >> wire... > > >> > > >> > > >>>> > > >>>> Some points: > > >>>> 1. Is there a real need by end-users/customers to run it on e.g. > > >>>> Oracle > > >>>> only? (performance, stability, easier administration). > > >>> > > >>> Usually companies have one database and they are trying to stick to > > >>> that > > >>> one. > > >>> Having two doubles the resource needs, you need one more DBA team, care > > >>> for > > >>> mirrors, backups. So it almost doubles the costs. > > >> > > >> Generally, I agree with Alon B L , if you have to support X DBs you are > > >> not > > >> doubling the effort by X > > >> Actually, we had already experience with that when we supported both MS > > >> SQL & > > >> Postgres > > >> I believe that as we have some customers with large installations, > > >> performance counts and the best way (and sometimes teh only way) id the > > >> DB > > >> layer > > >> > > >>> This is why I frequently hear people asking if we plan to support XyDB > > >>> in > > >>> the > > >>> future. PostgreSQL is cool, but those who already use MySQL/MariaDB, > > >>> they > > >>> just do not want one more. > > >>> > > >>>> What is the future of PostgreSQL? > > >>>> > > >>>> 2. Is it decided by architectural board, what kind of databases we > > >>>> would > > >>>> like to support? (cannot support any db) > > >>> > > >>> With a JPA we could support most mainstream relational databases, but > > >>> in > > >>> my > > >>> opinion 99 percent of people run oracle, mysql/mariadb or postgresql. > > >>> So > > >>> maybe we do not have to think in big number of database engines. > > >>> This is theoretical since JPA is still on wishlist :( > > >>> > > >>>> > > >>>> 3. Are we talking about the Engine only, or there will be a need to > > >>>> rewrite ETL mappings and upgrade DWH database, or maybe modify > > >>>> JasperReports templates (simply, some DB types behave differently)? > > >>>> Maybe we can look at JasperSoft solution, they support more > > >>>> databases. > > >> > > >> IMHO , ETL & DWH are perfect candidates for NO SQL which is already > > >> supported > > >> by Jasper > > +1 Here about NoSQL for ETL & DWH. > > >> > > >>>> > > >>>> 4. Current full/incremental upgrade process of PostgreSQL is IMHO > > >>>> very > > >>>> good tuned (it is similar to dbmaintain.org tool - Java > > >>>> implementation - > > >>>> I used successfully on one project - after some changes of course). I > > >>>> do > > >>>> not believe we can use or easily develop general upgrade/migration > > >>>> tool, > > >>>> and XML based (I am sorry Alissa, not sure about Liquibase, I haven't > > >>>> studied it deeply, but there is a need to incrementally change db > > >>>> objects, but sometimes also to migrate data to new structures, the > > >>>> most > > >>>> flexible and quickest is to do it using native SQL, but yes, it > > >>>> depends > > >>>> on the project needs...). > > >> > > >> I had evaluated Liquibase and I think that managing your DB upgrades via > > >> XML > > >> is very unfriendly and very limited as you reach complex upgrades as we > > >> had > > >> in the past. > > >> Just think of the tables in which we change the key from long to UUID , > > >> there > > >> is no way to do that in such tools > > >> > > >>>> > > >>>> 5. As a developer, with every new column I need to write upgrade > > >>>> scripts, prepare test environments and test all scenarios several > > >>>> times > > >>>> on different databases, so time-consuming. > > >> > > >> Did it also , again , since our SQL is 90% simple , the effort of > > >> writing > > >> a > > >> SP for more than one DB is not so high (and you have free converters you > > >> can > > >> use for that) > > >> > > >> Finally, embedded SQL in the Java code is not a good idea, it will be > > >> hard > > >> to > > >> maintain it and it is not advancing us in supporting more than one > > >> database. > > >> We have already SQL generated in the Java code on the search engine and > > >> IMHO > > >> this is one of the parts in the applications that needs a rewrite ... > > >> > > >>>> > > >>>> > > >>>> On 27.3.2013 13:53, Itamar Heim wrote: > > >>>>> On 03/26/2013 08:39 PM, Alon Bar-Lev wrote: > > >>>>>> > > >>>>>> > > >>>>>> ----- Original Message ----- > > >>>>>>> From: "Juan Hernandez" > > >>>>>>> To: engine-devel at ovirt.org > > >>>>>>> Sent: Tuesday, March 26, 2013 7:34:04 PM > > >>>>>>> Subject: [Engine-devel] Move SQL out of stored procedures > > >>>>>>> > > >>>>>>> Hello, > > >>>>>>> > > >>>>>>> I would like to start a discussion about the subject. I think > > >>>>>>> this is > > >>>>>>> something we need to do if one day we want to be able to use any > > >>>>>>> database other than PostgreSQL. > > >>>>>> > > >>>>>> Hello, > > >>>>>> > > >>>>>> I think that database layer is a software interface like any other > > >>>>>> software interface, if done properly, a dba can convert the stored > > >>>>>> procedure to any other database without any code change. > > >>>>>> > > >>>>>> This way the database specific implementation lives within the > > >>>>>> database and maintained by the designated dba. > > >>>>>> > > >>>>>> Fixups and optimizations can be done in database without touching > > >>>>>> the > > >>>>>> code. > > >>>>>> > > >>>>>> Backward compatibility layer is much simpler to implement based on > > >>>>>> stored procedures than complex set of views and tables. > > >>>>>> > > >>>>>> Also, accessing the database via different technologies is simpler > > >>>>>> if > > >>>>>> there is maintained database interface (stored procedures). > > >>>>>> > > >>>>>> I've seen hibernate based java applications that promised to be > > >>>>>> database independent but at the edges when performance counts, the > > >>>>>> DAO became HQL, then a special dialect and finally database > > >>>>>> specific > > >>>>>> SQLS. > > >>>>> > > >>>>> there may be db specific optimization/logic, but I don't see why we > > >>>>> need STPs for 80% (if not more) of the CRUD and basic queries. > > >>>>> > > >>>>> I also agree with Tal later in the thread that its a good question > > >>>>> if > > >>>>> we can't find a better solution than re-writing the sql's in the > > >>>>> code > > >>>>> > > >>>>> _______________________________________________ > > >>>>> 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 > > >> _______________________________________________ > > >> 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 sanjal at redhat.com Tue Apr 2 11:00:51 2013 From: sanjal at redhat.com (Shireesh Anjal) Date: Tue, 02 Apr 2013 16:30:51 +0530 Subject: [Engine-devel] FeatureSupported and compatibility versions In-Reply-To: <1842623267.574910.1364894251176.JavaMail.root@redhat.com> References: <36623975.7044697.1364386718971.JavaMail.root@redhat.com> <51543BF5.3050505@redhat.com> <1842623267.574910.1364894251176.JavaMail.root@redhat.com> Message-ID: <515ABA63.4070106@redhat.com> On 04/02/2013 02:47 PM, Mike Kolesnik wrote: > ------------------------------------------------------------------------ > > On 03/27/2013 05:48 PM, Mike Kolesnik wrote: > > ----- Original Message ----- > > On 03/20/2013 08:20 PM, Yair Zaslavsky wrote: > > ----- Original Message ----- > > From: "Shireesh Anjal" > To: "Mike Kolesnik" > Cc:engine-devel at ovirt.org > Sent: Wednesday, March 20, 2013 4:47:08 PM > Subject: Re: [Engine-devel] FeatureSupported and compatibility > versions > > On 03/18/2013 01:11 PM, Shireesh Anjal wrote: > > On 03/18/2013 12:59 PM, Mike Kolesnik wrote: > > ----- Original Message ----- > > Hi all, > > The current mechanism in oVirt to check whether a feature is > supported > in a particular compatibility version is to use the > FeatureSupported > class. e.g. > > FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion()) > > > Checks whether the "network linking" feature is supported for > the > the > VM's cluster compatibility version. This internally checks > whether > the > value of the corresponding config (NetworkLinkingSupported) for > the > given compatibility version is true/false. > > I'm not sure if this is a good idea, since a feature is > typically > supported "from" a particular version. E.g. Gluster support was > introduced in 3.1, and it continues to be available in all > subsequent > versions. So I see no point in adding configuration for every > version > indicating whether the feature is supported in that version or > not. I > suggest to use either of the following options: > > You can "merge" the configs into a single config when older > versions > go out of the supported versions for the system. > > i.e. in 4.0 you can have upgrade script that merges all > GlusterFeatureSupported to one entry instead of several. > > Why are we even storing this information in config? Is this > something > that can be "configured" at customer site? > > As previously explained (but off list :) ) , Config gives you the > ability to have a cachable "map" of entry (i.e - "feature name") > per version and value. > I guess it was convinient for the developers to use that. > I also mentioned that customers/oVirt users should config the > entries of vdc_options using engine-config tool only. > Not all entries are exposed via engine-config.properties (and no, > not just "is feature supported" entries are hidden). > > > > > 1) Instead of using a boolean config for each version, use a > single > string config that indicates the "supported from" version e.g. > GlusterSupportedFrom = 3.1. There could be rare cases where a > feature, > for some reason, is removed in some release. In such cases, we > could > use > one additional config for the "supported to" version. > > 2) Continue with the boolean approach, but do not have entries > for > every > version; rather make use of the "default value" for majority of > cases, > and add the explicit version mapping for the minority e.g. > GlusterSupported = true by default, and false in case of 3.0 > (only > one > config required for 3.0) > > I'm not sure why we would want to complicate this simple > mechanism? > > Is there much to gain? > > I think option 1 suggested above is simpler - to implement as > well > as > to understand. > > Let me give you an example of why I don't like current mechanism. > I > introduce a version check for a feature that was introduced in > 3.1. > I'm being asked now to add three entries in config > > 3.0 - false > 3.1 - true > 3.2 - true > > It will also mean that when 3.3 goes out, someone has to make > sure > that another entry is added for 3.3-true. I think it is not > logical > as > well as scalable if you have more versions. And it sounds far > more > complex (to maintain) than just having > > SupportedFrom = 3.1 > > So I would like to know if there are any objections to my > proposal. > I > intend to use this for at least the gluster related features. > > I've sent a patch (http://gerrit.ovirt.org/12970) with following > changes: > > 1) Introduced CompatibilityUtils that provides utility methods for > checking if a given feature is supported in the config. One method to > check based on boolean values (as is being done today for virt > features), and nother to check based on a range (from, to) which I > would > like to use for gluster features. > 2) Renamed FeatureSupported to VirtFeatureSupported, and made it use > the > first utility method from CompatibilityUtils > 3) Introduced GlusterFeatureSupported for gluster features, which > uses > the second utility method from CompatibilityUtils > > Key advantage here is that > - we don't have to touch any virt specifc source for adding > compatibility checks for gluster features > - virt features continue to use the existing boolean config check > > Any comments / suggestions / reviews will be highly appreciated :) > > I think splitting to two classes is OK, but the underlying mechanism IMO should be as Omer suggested: > Use the default value from the java config file, and if in the DB there is a version specific value then use it for that version only. > > > Review comments here are on the contrary: > http://gerrit.ovirt.org/#/c/12970/5/backend/manager/dbscripts/upgrade/pre_upgrade/0000_config.sql > > The comment in the review simply states that the mechanism is probably > broken, not that that's the way it has to be done. The comment explicitly asks me to add entries for every version. What you have looked at is my response to this comment, which suggests that the current mechanism is not great. In fact, what I had done in patch-set 5 is exactly what you are suggesting : true as default value and explicit entries in config for the "false" values. But it was not accepted. > > I don't think "From, To, etc" is a good design, it's not a standard way and is very restrictive. > > > Can you please explain in what way is it restrictive? > > Also, what is the "etc" you are referring to? > > What if for certain version it is not supported, you add "except"? Or > do you specify 2 ranges? > > Starting to add from/to creates a limited design of one range, which > would be difficult to tune if necessary. Really? Does someone really think that there will be a feature that will be supported in multiple different ranges of versions? I see zero possibility for this. I would love to see some +1s on this concept before I can accept this argument. > I think the design generally for config values is very simple and > suits us well - use the default value, unless a specific version is > configured differently. I think the current design is wrong. A feature gets supported "from" a particular version, and that's all that is required in most of the cases. Expecting developers to add version-by-version mapping for features is bad. The "to" part in my patch is just to handle rare cases, if at all they come up. I'm willing to even remove that if such a case doesn't exist today. Also, even though I have followed it for the sake of consistency, I don't think these values need to be stored in the config (db) at all. Only explanation I've got for it is that it was probably 'convenient' for developers to use the config mechanism. I'm for having this check purely in code in a central place, and not the config (db). > This way you can specify the feature is supported, and disable it for > specific versions. So one has to look at both code (FeatureSupported) as well as db (config) to get an idea of what versions the feature is supported in. Not great. > I think this direction gives us the flexibility that we would like to > have. > > Currently it doesn't work that way, but I think it's not impossible to > change, and more worthwhile than introducing a new mechanism. I disagree, and would like to use the "supported from" mechanism at least for gluster features. > > Thoughts? > > Regards, > Shireesh > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhornyak at redhat.com Tue Apr 2 11:17:47 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Tue, 2 Apr 2013 07:17:47 -0400 (EDT) Subject: [Engine-devel] Cloud-Init integration In-Reply-To: <725327293.92916816.1364563093706.JavaMail.root@redhat.com> References: <725327293.92916816.1364563093706.JavaMail.root@redhat.com> Message-ID: <1125183885.514306.1364901467502.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Oved Ourfalli" > To: "Laszlo Hornyak" > Cc: "Greg Padgett" , "engine-devel" > Sent: Friday, March 29, 2013 2:18:13 PM > Subject: Re: [Engine-devel] Cloud-Init integration > > > ----- Laszlo Hornyak wrote: > > Hi Greg, > > > > Cool feature :) Some questions: > > - Maybe the IP (and probably the hostname) should be enforced to be unique > > on the same network? Or at least warning if duplicates found? > If we will persist it then we can warn for duplicated, but looks like cloud > init is mainly used for one time initialization, so in that case we won't > persist it, thus we won't have this information in the engine. Ah ok. But still it could check if any VM has that IP address already at least from the ones that have guest agent isntalled and running. > > > - Let's say if the IP is set by cloud-init, then you may also have it in > > the guest agent info if the guest agent is installed. This may make life a > > bit more difficult for the developers who build on rest-api. Is there a > > nice solution for this? > Can you elaborate on that? What would be hard on developers? I thought it will be persisted, ignore pls. > > > - for authorized keys, it would be a pain to copy-paste the public key each > > time you install a guest. Could a default be stored let's say in the > > user's data? > > We might store those in the engine, allowing users to select one they have > permissions on. Not sure we would do it in the first phase, though. That's ok. Just trying to approach the problem from the user's perspective. > > > - the hostname set for the guest could default to the VM name? > > > That can indeed be nice. > > > Thank you, > > Laszlo > > > > ----- Original Message ----- > > > From: "Greg Padgett" > > > To: "engine-devel" > > > Sent: Friday, March 29, 2013 12:35:23 AM > > > Subject: [Engine-devel] Cloud-Init integration > > > > > > Hi Everyone, > > > > > > I'd like to propose a feature we've been doing some investigation > > > into, > > > which is to integrate cloud-init support into oVirt. > > > > > > Cloud-init is used to help provision new Linux systems by setting the > > > hostname, ip, ssh keys, timezone, injecting files, and more. It's > > > used by > > > OpenStack (amongst others) now, and has a lot of features that may be > > > helpful to our users. > > > > > > Details are still evolving, but for more info please see the wiki > > > page: > > > > > > http://www.ovirt.org/Features/Cloud-Init_Integration > > > > > > All feedback is welcome! > > > > > > Thanks, > > > Greg > > > _______________________________________________ > > > 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 mkublin at redhat.com Tue Apr 2 11:49:02 2013 From: mkublin at redhat.com (Michael Kublin) Date: Tue, 2 Apr 2013 07:49:02 -0400 (EDT) Subject: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your review In-Reply-To: References: <60519417.9696375.1364465102897.JavaMail.root@redhat.com> <1014066770.26313104.1364481799434.JavaMail.root@redhat.com> Message-ID: <1720827382.634160.1364903342393.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Wei D Chen" > To: "Doron Fediuck" , "Ofri Masad" > Cc: engine-devel at ovirt.org > Sent: Friday, March 29, 2013 5:00:55 AM > Subject: Re: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your > review > > Thanks Doron & Ofri, > > As to the question of cache flash, we already have our consideration and > wrote them on our design page. I have no doubt that your suggestion is more > reasonable, we just keep in mind that expiration is much longer that the > time needed to poll all of hosts, so this is really a potential issue we > ignored. Let's make estimation at first, we will have a try if our schedule > is okay. > > Doron, we have reserved some effort to research about cluster-level policy. > As ovirt is complete new to our engineers, would we finished our current > features (such as ovf and rest api.) in pipeline at first? After these basic > features are ready and we still have some buffer, we will make some > improvement. Is this acceptable? > > Thanks again to Doron and Ofri. > > > Best Regards, > Dave Chen > > > -----Original Message----- > From: Doron Fediuck [mailto:dfediuck at redhat.com] > Sent: Thursday, March 28, 2013 10:43 PM > To: Ofri Masad > Cc: engine-devel at ovirt.org; Chen, Wei D > Subject: Re: [Engine-devel] Open Attestation integration with oVirt engine > proposal has submitted patchset5 for your review > > ----- Original Message ----- > > From: "Ofri Masad" > > To: "Wei D Chen" > > Cc: engine-devel at ovirt.org > > Sent: Thursday, March 28, 2013 12:05:02 PM > > Subject: Re: [Engine-devel] Open Attestation integration with oVirt > > engine proposal has submitted patchset5 for your review > > > > Hi Dave, > > > > I would like to raise again the question of the full cache flash for > > each stale cache entry found. > > This method can cause two unwanted situations: > > 1. Choosing untrusted host: lets say, for example that you have 1000 > > host in your pool. you look at the first host in the cache and find > > that its attestation hat expired. you refresh the entire pool (there > > are 1000 host, that must take some time). by the the time the last > > host was refreshed in the pool, the first host may already be expired > > again. but since you already checked it - you keep on with your flow > > and select that host, even so it has expired and may as well be > > untrusted. > > > > 2. infinite loop: lets say we'll try to fix what I've described in > > 1. then, we need to check again if the host has expired before we > > select it. if it is, the entire refresh process starts again. this > > could potentially go on forever (unless I'm missing something, and > > the expiration is much longer then the full re-cache process). > > > > Instead of re-caching the full cache we can do as follows: > > - hold the cache entries sorted by expiration (if the expiration > > time is the same for all hosts, so a queue is enough). > > - each time we need a new trusted host - select from the unexpired > > hosts, refresh all expired hosts (in one query). > > - if all hosts are expired - we can wait for the first host to be > > defined trusted by the attestation server and select that host. > > > > Ofri > > > > > > Dave, adding another suggestion on top of Ofri's; > > Generally speaking, a cluster of hosts defines many joint features (such as > CPU level), which means that in the same cluster we would expect to be able > to freely migrate a VM from one host to another. > > Current trust-pools design is breaking this concept, as you introduce a state > where a VM cannot migrate from a 'safe' host into an 'unsafe' > host. > > This leads me to the suggestion of having attestation as a cluster policy > rather than a VM-level property. It means that all hosts in this cluster are > constantly being monitored to be safe. If a host is declared as unsafe in > the Attestation server, it will become non-operational in the engine. This > will simplify the implementation since you have everything ready for you > once you have a 'safe' cluster and no need to do any VM-level changes. > > So in this way you keep current concepts while simplifying the implementation > with very little worries of performance issues. > > Can you please share your thoughts on this suggestion? > > > ----- Original Message ----- > > > From: "Wei D Chen" > > > To: engine-devel at ovirt.org > > > Sent: Friday, March 22, 2013 11:34:55 AM > > > Subject: [Engine-devel] Open Attestation integration with oVirt > > > engine proposal has submitted patchset5 for your review > > > > > > Hi all, > > > > > > Before submitting this patch set, we has updated our design page, > > > and new feature about VM template has added to this patchset. In > > > patchset a lot of frontend changes has been imported. > > > Welcome to review our patchset and thanks advance for your > > > suggestion. > > > > > > > > > Detailed description: http://wiki.ovirt.org/Trusted_compute_pools > > > > > > In this patch set, follow changes has been introduced: > > > > > > 1. GUI changes to support for creating a trusted VM on a trusted > > > physical host. > > > 2. View/Edit VM changes to enable end user switch between three run > > > on options. > > > 3. Template relevant changes to support end user create a trusted VM > > > template and create trusted VM based on this template afterwards. > > > 4. Bug fixing and code cleanup. > > > 5. wiki design page update. > > > > > > > > > > > > Best Regards, > > > Dave Chen > > > > > > Hi, I read your design and I have some proposal about implementation of cache. Currently in project we have couple of places with custom-made cache implementation, my advice is to start using something that already written and well tested: I think that cache of Guava project (http://code.google.com/p/guava-libraries/) is good choice. The following cache has all required functionality and some features that can help for your implementation, like Removal Listeners (sync/async) and cache Loaders, also the following implementation is easy to configure and test. The code for cache can be put inside utils. Also, not sure that is a relevant but the following stuff can influence your feature: remove of host, add of new host, moving a host to maintenance and after that to other cluster/pool, host restarts From dfediuck at redhat.com Tue Apr 2 11:54:53 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Tue, 2 Apr 2013 07:54:53 -0400 (EDT) Subject: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your review In-Reply-To: <1720827382.634160.1364903342393.JavaMail.root@redhat.com> References: <60519417.9696375.1364465102897.JavaMail.root@redhat.com> <1014066770.26313104.1364481799434.JavaMail.root@redhat.com> <1720827382.634160.1364903342393.JavaMail.root@redhat.com> Message-ID: <839060345.851607.1364903693035.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michael Kublin" > To: "Wei D Chen" > Cc: engine-devel at ovirt.org > Sent: Tuesday, April 2, 2013 2:49:02 PM > Subject: Re: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your > review > > > > > > ----- Original Message ----- > > From: "Wei D Chen" > > To: "Doron Fediuck" , "Ofri Masad" > > Cc: engine-devel at ovirt.org > > Sent: Friday, March 29, 2013 5:00:55 AM > > Subject: Re: [Engine-devel] Open Attestation integration with oVirt engine > > proposal has submitted patchset5 for your > > review > > > > Thanks Doron & Ofri, > > > > As to the question of cache flash, we already have our consideration and > > wrote them on our design page. I have no doubt that your suggestion is more > > reasonable, we just keep in mind that expiration is much longer that the > > time needed to poll all of hosts, so this is really a potential issue we > > ignored. Let's make estimation at first, we will have a try if our schedule > > is okay. > > > > Doron, we have reserved some effort to research about cluster-level policy. > > As ovirt is complete new to our engineers, would we finished our current > > features (such as ovf and rest api.) in pipeline at first? After these > > basic > > features are ready and we still have some buffer, we will make some > > improvement. Is this acceptable? > > > > Thanks again to Doron and Ofri. > > > > > > Best Regards, > > Dave Chen > > > > > > -----Original Message----- > > From: Doron Fediuck [mailto:dfediuck at redhat.com] > > Sent: Thursday, March 28, 2013 10:43 PM > > To: Ofri Masad > > Cc: engine-devel at ovirt.org; Chen, Wei D > > Subject: Re: [Engine-devel] Open Attestation integration with oVirt engine > > proposal has submitted patchset5 for your review > > > > ----- Original Message ----- > > > From: "Ofri Masad" > > > To: "Wei D Chen" > > > Cc: engine-devel at ovirt.org > > > Sent: Thursday, March 28, 2013 12:05:02 PM > > > Subject: Re: [Engine-devel] Open Attestation integration with oVirt > > > engine proposal has submitted patchset5 for your review > > > > > > Hi Dave, > > > > > > I would like to raise again the question of the full cache flash for > > > each stale cache entry found. > > > This method can cause two unwanted situations: > > > 1. Choosing untrusted host: lets say, for example that you have 1000 > > > host in your pool. you look at the first host in the cache and find > > > that its attestation hat expired. you refresh the entire pool (there > > > are 1000 host, that must take some time). by the the time the last > > > host was refreshed in the pool, the first host may already be expired > > > again. but since you already checked it - you keep on with your flow > > > and select that host, even so it has expired and may as well be > > > untrusted. > > > > > > 2. infinite loop: lets say we'll try to fix what I've described in > > > 1. then, we need to check again if the host has expired before we > > > select it. if it is, the entire refresh process starts again. this > > > could potentially go on forever (unless I'm missing something, and > > > the expiration is much longer then the full re-cache process). > > > > > > Instead of re-caching the full cache we can do as follows: > > > - hold the cache entries sorted by expiration (if the expiration > > > time is the same for all hosts, so a queue is enough). > > > - each time we need a new trusted host - select from the unexpired > > > hosts, refresh all expired hosts (in one query). > > > - if all hosts are expired - we can wait for the first host to be > > > defined trusted by the attestation server and select that host. > > > > > > Ofri > > > > > > > > > > Dave, adding another suggestion on top of Ofri's; > > > > Generally speaking, a cluster of hosts defines many joint features (such as > > CPU level), which means that in the same cluster we would expect to be able > > to freely migrate a VM from one host to another. > > > > Current trust-pools design is breaking this concept, as you introduce a > > state > > where a VM cannot migrate from a 'safe' host into an 'unsafe' > > host. > > > > This leads me to the suggestion of having attestation as a cluster policy > > rather than a VM-level property. It means that all hosts in this cluster > > are > > constantly being monitored to be safe. If a host is declared as unsafe in > > the Attestation server, it will become non-operational in the engine. This > > will simplify the implementation since you have everything ready for you > > once you have a 'safe' cluster and no need to do any VM-level changes. > > > > So in this way you keep current concepts while simplifying the > > implementation > > with very little worries of performance issues. > > > > Can you please share your thoughts on this suggestion? > > > > > ----- Original Message ----- > > > > From: "Wei D Chen" > > > > To: engine-devel at ovirt.org > > > > Sent: Friday, March 22, 2013 11:34:55 AM > > > > Subject: [Engine-devel] Open Attestation integration with oVirt > > > > engine proposal has submitted patchset5 for your review > > > > > > > > Hi all, > > > > > > > > Before submitting this patch set, we has updated our design page, > > > > and new feature about VM template has added to this patchset. In > > > > patchset a lot of frontend changes has been imported. > > > > Welcome to review our patchset and thanks advance for your > > > > suggestion. > > > > > > > > > > > > Detailed description: http://wiki.ovirt.org/Trusted_compute_pools > > > > > > > > In this patch set, follow changes has been introduced: > > > > > > > > 1. GUI changes to support for creating a trusted VM on a trusted > > > > physical host. > > > > 2. View/Edit VM changes to enable end user switch between three run > > > > on options. > > > > 3. Template relevant changes to support end user create a trusted VM > > > > template and create trusted VM based on this template afterwards. > > > > 4. Bug fixing and code cleanup. > > > > 5. wiki design page update. > > > > > > > > > > > > > > > > Best Regards, > > > > Dave Chen > > > > > > > > > > Hi, I read your design and I have some proposal about implementation of > cache. > Currently in project we have couple of places with custom-made cache > implementation, > my advice is to start using something that already written and well tested: > I think that cache of Guava project > (http://code.google.com/p/guava-libraries/) is good choice. > The following cache has all required functionality and some features that can > help for your implementation, > like Removal Listeners (sync/async) and cache Loaders, also the following > implementation is easy to configure and test. > The code for cache can be put inside utils. > > Also, not sure that is a relevant but the following stuff can influence your > feature: remove of host, add of new host, > moving a host to maintenance and after that to other cluster/pool, host > restarts > Thanks Michael! I suggest you read my mail on moving it to be a cluster level-policy, which will make caching redundant. In this way a host with a trust level which does not meet the policy will become non-operational. The process of validating hosts trust will be in the background similar to the load balancing we're doing today. From mkublin at redhat.com Tue Apr 2 12:16:09 2013 From: mkublin at redhat.com (Michael Kublin) Date: Tue, 2 Apr 2013 08:16:09 -0400 (EDT) Subject: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your review In-Reply-To: <839060345.851607.1364903693035.JavaMail.root@redhat.com> References: <60519417.9696375.1364465102897.JavaMail.root@redhat.com> <1014066770.26313104.1364481799434.JavaMail.root@redhat.com> <1720827382.634160.1364903342393.JavaMail.root@redhat.com> <839060345.851607.1364903693035.JavaMail.root@redhat.com> Message-ID: <560107078.642876.1364904969220.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Doron Fediuck" > To: "Michael Kublin" > Cc: "Wei D Chen" , engine-devel at ovirt.org > Sent: Tuesday, April 2, 2013 2:54:53 PM > Subject: Re: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your > review > > > > ----- Original Message ----- > > From: "Michael Kublin" > > To: "Wei D Chen" > > Cc: engine-devel at ovirt.org > > Sent: Tuesday, April 2, 2013 2:49:02 PM > > Subject: Re: [Engine-devel] Open Attestation integration with oVirt engine > > proposal has submitted patchset5 for your > > review > > > > > > > > > > > > ----- Original Message ----- > > > From: "Wei D Chen" > > > To: "Doron Fediuck" , "Ofri Masad" > > > > > > Cc: engine-devel at ovirt.org > > > Sent: Friday, March 29, 2013 5:00:55 AM > > > Subject: Re: [Engine-devel] Open Attestation integration with oVirt > > > engine > > > proposal has submitted patchset5 for your > > > review > > > > > > Thanks Doron & Ofri, > > > > > > As to the question of cache flash, we already have our consideration and > > > wrote them on our design page. I have no doubt that your suggestion is > > > more > > > reasonable, we just keep in mind that expiration is much longer that the > > > time needed to poll all of hosts, so this is really a potential issue we > > > ignored. Let's make estimation at first, we will have a try if our > > > schedule > > > is okay. > > > > > > Doron, we have reserved some effort to research about cluster-level > > > policy. > > > As ovirt is complete new to our engineers, would we finished our current > > > features (such as ovf and rest api.) in pipeline at first? After these > > > basic > > > features are ready and we still have some buffer, we will make some > > > improvement. Is this acceptable? > > > > > > Thanks again to Doron and Ofri. > > > > > > > > > Best Regards, > > > Dave Chen > > > > > > > > > -----Original Message----- > > > From: Doron Fediuck [mailto:dfediuck at redhat.com] > > > Sent: Thursday, March 28, 2013 10:43 PM > > > To: Ofri Masad > > > Cc: engine-devel at ovirt.org; Chen, Wei D > > > Subject: Re: [Engine-devel] Open Attestation integration with oVirt > > > engine > > > proposal has submitted patchset5 for your review > > > > > > ----- Original Message ----- > > > > From: "Ofri Masad" > > > > To: "Wei D Chen" > > > > Cc: engine-devel at ovirt.org > > > > Sent: Thursday, March 28, 2013 12:05:02 PM > > > > Subject: Re: [Engine-devel] Open Attestation integration with oVirt > > > > engine proposal has submitted patchset5 for your review > > > > > > > > Hi Dave, > > > > > > > > I would like to raise again the question of the full cache flash for > > > > each stale cache entry found. > > > > This method can cause two unwanted situations: > > > > 1. Choosing untrusted host: lets say, for example that you have 1000 > > > > host in your pool. you look at the first host in the cache and find > > > > that its attestation hat expired. you refresh the entire pool (there > > > > are 1000 host, that must take some time). by the the time the last > > > > host was refreshed in the pool, the first host may already be expired > > > > again. but since you already checked it - you keep on with your flow > > > > and select that host, even so it has expired and may as well be > > > > untrusted. > > > > > > > > 2. infinite loop: lets say we'll try to fix what I've described in > > > > 1. then, we need to check again if the host has expired before we > > > > select it. if it is, the entire refresh process starts again. this > > > > could potentially go on forever (unless I'm missing something, and > > > > the expiration is much longer then the full re-cache process). > > > > > > > > Instead of re-caching the full cache we can do as follows: > > > > - hold the cache entries sorted by expiration (if the expiration > > > > time is the same for all hosts, so a queue is enough). > > > > - each time we need a new trusted host - select from the unexpired > > > > hosts, refresh all expired hosts (in one query). > > > > - if all hosts are expired - we can wait for the first host to be > > > > defined trusted by the attestation server and select that host. > > > > > > > > Ofri > > > > > > > > > > > > > > Dave, adding another suggestion on top of Ofri's; > > > > > > Generally speaking, a cluster of hosts defines many joint features (such > > > as > > > CPU level), which means that in the same cluster we would expect to be > > > able > > > to freely migrate a VM from one host to another. > > > > > > Current trust-pools design is breaking this concept, as you introduce a > > > state > > > where a VM cannot migrate from a 'safe' host into an 'unsafe' > > > host. > > > > > > This leads me to the suggestion of having attestation as a cluster policy > > > rather than a VM-level property. It means that all hosts in this cluster > > > are > > > constantly being monitored to be safe. If a host is declared as unsafe in > > > the Attestation server, it will become non-operational in the engine. > > > This > > > will simplify the implementation since you have everything ready for you > > > once you have a 'safe' cluster and no need to do any VM-level changes. > > > > > > So in this way you keep current concepts while simplifying the > > > implementation > > > with very little worries of performance issues. > > > > > > Can you please share your thoughts on this suggestion? > > > > > > > ----- Original Message ----- > > > > > From: "Wei D Chen" > > > > > To: engine-devel at ovirt.org > > > > > Sent: Friday, March 22, 2013 11:34:55 AM > > > > > Subject: [Engine-devel] Open Attestation integration with oVirt > > > > > engine proposal has submitted patchset5 for your review > > > > > > > > > > Hi all, > > > > > > > > > > Before submitting this patch set, we has updated our design page, > > > > > and new feature about VM template has added to this patchset. In > > > > > patchset a lot of frontend changes has been imported. > > > > > Welcome to review our patchset and thanks advance for your > > > > > suggestion. > > > > > > > > > > > > > > > Detailed description: http://wiki.ovirt.org/Trusted_compute_pools > > > > > > > > > > In this patch set, follow changes has been introduced: > > > > > > > > > > 1. GUI changes to support for creating a trusted VM on a trusted > > > > > physical host. > > > > > 2. View/Edit VM changes to enable end user switch between three run > > > > > on options. > > > > > 3. Template relevant changes to support end user create a trusted VM > > > > > template and create trusted VM based on this template afterwards. > > > > > 4. Bug fixing and code cleanup. > > > > > 5. wiki design page update. > > > > > > > > > > > > > > > > > > > > Best Regards, > > > > > Dave Chen > > > > > > > > > > > > > > Hi, I read your design and I have some proposal about implementation of > > cache. > > Currently in project we have couple of places with custom-made cache > > implementation, > > my advice is to start using something that already written and well tested: > > I think that cache of Guava project > > (http://code.google.com/p/guava-libraries/) is good choice. > > The following cache has all required functionality and some features that > > can > > help for your implementation, > > like Removal Listeners (sync/async) and cache Loaders, also the following > > implementation is easy to configure and test. > > The code for cache can be put inside utils. > > > > Also, not sure that is a relevant but the following stuff can influence > > your > > feature: remove of host, add of new host, > > moving a host to maintenance and after that to other cluster/pool, host > > restarts > > > Thanks Michael! > I suggest you read my mail on moving it to be a cluster level-policy, > which will make caching redundant. In this way a host with a trust level > which does not meet the policy will become non-operational. The process > of validating hosts trust will be in the background similar to the load > balancing we're doing today. > Sorry, that missed this, this solution is much better From mpastern at redhat.com Tue Apr 2 12:41:08 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Tue, 02 Apr 2013 15:41:08 +0300 Subject: [Engine-devel] ovirt-sdk-python 3.3.0.1 released Message-ID: <515AD1E4.7050506@redhat.com> - added new collection ClusterGlusterVolumeBrickStatistics - added NetUp 'cloned disk' importing capabilities - to ClusterGlusterVolumeBricks.list() added new argument "all_content" - to ClusterGlusterVolumeBricks.get() added new argument "all_content" - to host install method added new parameter "image" - to host add method added new parameter "display.address" - to vm add method added new parameter "vm.cpu.mode" - to vm add method added new overload for creating vm from snapshot - to cluster added tunnel_migration - to display added keyboard_layout - to display added smartcard_enabled - to DataCenter added Clusters sub-collection - to StorageDomain added Disks sub-collection - to Disks.list() added 'unregistered' argument - to Host added display.address - to Snapshot added commit/preview/undo actions - to vms.add() added overload for creating vm from snapshot - to hosts.add() added [@param host.display.address: string] - to vm.ticket() added [@param action.ticket.value: string] - return error if amount of fetched objects in X.get() is > 1 #890327 - session based authentication for /localhost is broken #916285 - explicitly ask for reply in xml - Add constructor parameter validate_cert_chain=True #915225 - defend against malformed server reply For more details see [1]. [1] http://wiki.ovirt.org/Python-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Tue Apr 2 12:42:12 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Tue, 02 Apr 2013 15:42:12 +0300 Subject: [Engine-devel] ovirt-cli 3.3.0.1 released Message-ID: <515AD224.5020709@redhat.com> - at vm.start() --vm-os-boot doesn't send the order of devices #921464 - rephrase status command help - add option to retrieve system summary #854369 - accept IP address as FQ argument rather than string #886067 - fix broken pipe - Bad error message when trying to create a new Role #908284 - add flag --dont-validate-cert-chain #915231 - collection-based-options could be passed in 2 ways #859684 - make NO_SUCH_ACTION error a bit more clear - ovirt-cli DistributionNotFound exception on f18 #881011 - ovirt-shell misleading help for command "connect" #907943 - show event -id accept strings instead of numeric values #886786 - Use vncviewer passwordFile instead of passwdInput More details can be found at [1]. [1] http://wiki.ovirt.org/Cli-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D From amureini at redhat.com Tue Apr 2 13:33:20 2013 From: amureini at redhat.com (Allon Mureinik) Date: Tue, 2 Apr 2013 09:33:20 -0400 (EDT) Subject: [Engine-devel] Java 7, revisited again In-Reply-To: <1241556280.209143.1364908827725.JavaMail.root@redhat.com> Message-ID: <1300679206.218645.1364909600566.JavaMail.root@redhat.com> Hola, A couple of weeks (months?) ago we discussed upgrading to Java 7.[1] Generally, there was a positive vibe about moving forward with technology, although we noted that this should not be done for common, compat and the GWT modules, under the limitation of the current GWT version we're using. Here's an initial suggestion for this upgrade: http://gerrit.ovirt.org/#/c/13519/ Areas handled and checked: 1. compilation (including GWT compilation)[2] 2. animal-sniffer validations for to makes sure that modules that aren't supposed to use JDK7 features really don't[2] 3. Running and making sure the UI still works :-) (checkstyle issues which Laslo pointed out in the original discussion were already solved in a different patch merged long ago) Sincerely, Allon and Alissa [1] http://lists.ovirt.org/pipermail/engine-devel/2012-December/003139.html [2] This includes, of course, purposely introducing Java 7 syntax and JDK 7 features to modules that aren't supposed to have them, and making sure that the build fails early, as expected, without having to add the -Pgwt-admin or -Pgwt-user profiles. From qw.iampaco at gmail.com Tue Apr 2 15:38:41 2013 From: qw.iampaco at gmail.com (Paco qw) Date: Tue, 2 Apr 2013 19:38:41 +0400 Subject: [Engine-devel] ovirt 3.2 build from srpm Message-ID: Hi! Trying to build an RPM of ovirt in Centos 6.4. Srpms take away http://resources.ovirt.org/releases/3.2/rpm/EL/6/SRPMS/ ?ommand to execute rpmbuild --rebuild otopi -- OK rpmbuild --rebuild ovirt-host-deploy -- OK install otopi and ovirt-host-deploy rpmbuild --rebuild ovirt-engine-3.2.1-1.el6.src.rpm as a result of getting an error message [INFO] Compiling 6 permutations [INFO] Compiling permutation 0... [INFO] Process output [INFO] [ERROR] [AppClassLoader at 75da931b] info AspectJ Weaver Version 1.6.11 built on Tuesday Mar 15, 2011 at 15:31:04 GMT [INFO] [ERROR] [AppClassLoader at 75da931b] info register classloader sun.misc.Launcher$AppClassLoader at 75da931b [INFO] [ERROR] [AppClassLoader at 75da931b] info using configuration file:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0.jar!/META-INF/aop.xml [INFO] [ERROR] [AppClassLoader at 75da931b] info using configuration file:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0-sources.jar!/META-INF/aop.xml [INFO] [ERROR] [AppClassLoader at 75da931b] info register aspect org.ovirt.engine.ui.gwtextension.DontPrune [INFO] [ERROR] [AppClassLoader at 75da931b] info register aspect org.ovirt.engine.ui.gwtextension.DontPrune [INFO] Compiling [INFO] Compiling permutation 1... [INFO] [WARN] Lost communication with remote process [INFO] java.io.EOFException [INFO] at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2577) [INFO] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1315) [INFO] at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369) [INFO] at com.google.gwt.dev.ExternalPermutationWorkerFactory$ExternalPermutationWorker.compile(ExternalPermutationWorkerFactory.java:150) [INFO] at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73) [INFO] at java.lang.Thread.run(Thread.java:722) [INFO] Compiling permutation 2... [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] ovirt-root ........................................ SUCCESS [1.311s] [INFO] oVirt Build Tools root ............................ SUCCESS [0.026s] [INFO] oVirt checkstyle .................................. SUCCESS [2.206s] [INFO] oVirt JBoss Modules Maven Plugin .................. SUCCESS [7.823s] [INFO] oVirt Checkstyle Checks ........................... SUCCESS [1.712s] [INFO] oVirt Modules - backend ........................... SUCCESS [0.020s] [INFO] oVirt Manager ..................................... SUCCESS [0.039s] [INFO] oVirt DB Scripts .................................. SUCCESS [0.299s] [INFO] oVirt Engine dependencies ......................... SUCCESS [2.053s] [INFO] oVirt Modules - manager ........................... SUCCESS [1.845s] [INFO] CSharp Compatibility .............................. SUCCESS [6.803s] [INFO] Common Code ....................................... SUCCESS [19.745s] [INFO] Common utilities .................................. SUCCESS [10.625s] [INFO] Data Access Layer ................................. SUCCESS [16.322s] [INFO] engine beans ...................................... SUCCESS [0.098s] [INFO] engine scheduler bean ............................. SUCCESS [3.615s] [INFO] Vds broker ........................................ SUCCESS [11.356s] [INFO] Search Backend .................................... SUCCESS [5.869s] [INFO] Backend Logic @Service bean ....................... SUCCESS [29.194s] [INFO] oVirt RESTful API Backend Integration ............. SUCCESS [0.369s] [INFO] oVirt RESTful API interface ....................... SUCCESS [0.147s] [INFO] oVirt Engine API Definition ....................... SUCCESS [12.313s] [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS [0.130s] [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS [5.514s] [INFO] oVirt RESTful API Backend Integration Type Mappers SUCCESS [8.108s] [INFO] oVirt RESTful API Backend Integration JAX-RS Resources SUCCESS [19.997s] [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS [1.065s] [INFO] oVirt Engine Web Root ............................. SUCCESS [2.290s] [INFO] oVirt Engine Tools ................................ SUCCESS [5.784s] [INFO] oVirt Modules :: Frontend ......................... SUCCESS [0.020s] [INFO] oVirt APIs ........................................ SUCCESS [0.123s] [INFO] oVirt generic API ................................. SUCCESS [4.327s] [INFO] oVirt Modules :: Webadmin ......................... SUCCESS [0.033s] [INFO] oVirt Modules - ui ................................ SUCCESS [0.031s] [INFO] Extensions for GWT ................................ SUCCESS [2.283s] [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS [3.808s] [INFO] Frontend for GWT UI Projects ...................... SUCCESS [6.468s] [INFO] UICommonWeb ....................................... SUCCESS [24.879s] [INFO] oVirt GWT UI common infrastructure ................ SUCCESS [29.410s] [INFO] WebAdmin .......................................... FAILURE [28:10.304s] [INFO] UserPortal ........................................ SKIPPED [INFO] oVirt WARs ........................................ SKIPPED [INFO] oVirt Web Application Module ...................... SKIPPED [INFO] oVirt Server EAR .................................. SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 32:21.698s [INFO] Finished at: Tue Apr 02 23:18:37 MSK 2013 [INFO] Final Memory: 288M/707M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.codehaus.mojo:gwt-maven-plugin:2.3.0-1:compile (gwtcompile) on project webadmin: Command [[ [ERROR] /bin/sh -c /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/bin/java -javaagent:/root/.m2/repository/org/aspectj/aspectjweaver/1.6.11/aspectjweaver-1.6.11.jar -Xms1024M -Xmx2048M -XX:PermSize=256M -XX:MaxPermSize=256M '-Dgwt.dontPrune=org\.ovirt\.engine\.core\.(common|compat)\..*' -classpath /root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/webadmin/src/main/java:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/webadmin/target/generated-sources/annotations:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/webadmin/target/generated-sources/gwt:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/webadmin/src/main/resources:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/webadmin/target/webadmin-3.2.0/WEB-INF/classes:/root/.m2/repository/com/google/gwt/gwt-user/2.3.0/gwt-user-2.3.0.jar:/root/.m2/repository/com/google/gwt/gwt-dev/2.3.0/gwt-dev-2.3.0.jar:/root/.m2/repository/com/gwtplatform/gwtp-mvp-client/0.6/gwtp-mvp-client-0.6.jar:/root/.m2/repository/com/gwtplatform/gwtp-clients-common/0.6/gwtp-clients-common-0.6.jar:/root/.m2/repository/com/gwtplatform/gwtp-processors/0.6/gwtp-processors-0.6.jar:/root/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar:/root/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar:/root/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/root/.m2/repository/com/google/inject/extensions/guice-assistedinject/3.0/guice-assistedinject-3.0.jar:/root/.m2/repository/com/google/gwt/inject/gin/1.5.0/gin-1.5.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/uicommonweb/target/uicommonweb-3.2.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/backend/manager/modules/searchbackend/target/searchbackend-3.2.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/backend/manager/modules/compat/target/compat-3.2.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/uicompat/target/uicompat-3.2.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/backend/manager/modules/common/target/common-3.2.0-sources.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/backend/manager/modules/compat/target/compat-3.2.0-sources.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/backend/manager/modules/searchbackend/target/searchbackend-3.2.0-sources.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/gwt-common/target/gwt-common-3.2.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/api/genericapi/target/genericapi-3.2.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/backend/manager/modules/common/target/common-3.2.0.jar:/root/.m2/repository/org/hibernate/hibernate-validator/ 4.0.2.GA/hibernate-validator-4.0.2.GA.jar:/root/.m2/repository/javax/validation/validation-api/1.0.0.GA/validation-api-1.0.0.GA.jar:/root/.m2/repository/org/slf4j/slf4j-api/1.5.6/slf4j-api-1.5.6.jar:/root/.m2/repository/com/sun/xml/bind/jaxb-impl/2.1.3/jaxb-impl-2.1.3.jar:/root/.m2/repository/org/hibernate/hibernate-annotations/3.4.0.GA/hibernate-annotations-3.4.0.GA.jar:/root/.m2/repository/org/hibernate/ejb3-persistence/1.0.2.GA/ejb3-persistence-1.0.2.GA.jar:/root/.m2/repository/org/hibernate/hibernate-commons-annotations/3.1.0.GA/hibernate-commons-annotations-3.1.0.GA.jar:/root/.m2/repository/org/hibernate/hibernate-core/3.3.0.SP1/hibernate-core-3.3.0.SP1.jar:/root/.m2/repository/antlr/antlr/2.7.6/antlr-2.7.6.jar:/root/.m2/repository/commons-collections/commons-collections/3.1/commons-collections-3.1.jar:/root/.m2/repository/javax/transaction/jta/1.1/jta-1.1.jar:/root/.m2/repository/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar:/root/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar:/root/.m2/repository/org/codehaus/jackson/jackson-mapper-asl/1.9.4/jackson-mapper-asl-1.9.4.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/backend/manager/modules/utils/target/utils-3.2.0.jar:/root/.m2/repository/commons-beanutils/commons-beanutils/1.8.2/commons-beanutils-1.8.2.jar:/root/.m2/repository/org/apache/mina/mina-core/2.0.1/mina-core-2.0.1.jar:/root/.m2/repository/org/apache/sshd/sshd-core/0.7.0/sshd-core-0.7.0.jar:/root/.m2/repository/org/ovirt/otopi/otopi/1.0.0/otopi-1.0.0.jar:/root/.m2/repository/org/ovirt/ovirt-host-deploy/ovirt-host-deploy/1.0.0/ovirt-host-deploy-1.0.0.jar:/root/.m2/repository/org/apache/commons/commons-compress/1.3/commons-compress-1.3.jar:/root/.m2/repository/commons-lang/commons-lang/2.6/commons-lang-2.6.jar:/root/.m2/repository/commons-codec/commons-codec/1.4/commons-codec-1.4.jar:/root/.m2/repository/org/apache/xmlrpc/xmlrpc-client/3.1.3/xmlrpc-client-3.1.3.jar:/root/.m2/repository/org/apache/xmlrpc/xmlrpc-common/3.1.3/xmlrpc-common-3.1.3.jar:/root/.m2/repository/org/apache/ws/commons/util/ws-commons-util/1.0.2/ws-commons-util-1.0.2.jar:/root/.m2/repository/commons-httpclient/commons-httpclient/3.1/commons-httpclient-3.1.jar:/root/.m2/repository/org/codehaus/jackson/jackson-core-asl/1.9.4/jackson-core-asl-1.9.4.jar:/root/.m2/repository/org/springframework/spring-core/3.1.1.RELEASE/spring-core-3.1.1.RELEASE.jar:/root/.m2/repository/org/springframework/spring-asm/3.1.1.RELEASE/spring-asm-3.1.1.RELEASE.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/frontend/target/frontend-3.2.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0.jar:/root/.m2/repository/javax/xml/bind/jaxb-api/2.1/jaxb-api-2.1.jar:/root/.m2/repository/javax/xml/stream/stax-api/1.0-2/stax-api-1.0-2.jar:/root/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar:/root/.m2/repository/org/jboss/spec/javax/ejb/jboss-ejb-api_3.1_spec/1.0.1.Final/jboss-ejb-api_3.1_spec-1.0.1.Final.jar:/root/.m2/repository/org/aspectj/aspectjweaver/1.6.11/aspectjweaver-1.6.11.jar:/root/.m2/repository/commons-logging/commons-logging/1.1/commons-logging-1.1.jar:/root/.m2/repository/log4j/log4j/1.2.16/log4j-1.2.16.jar:/root/.m2/repository/logkit/logkit/1.0.1/logkit-1.0.1.jar:/root/.m2/repository/avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.jar:/root/.m2/repository/javax/servlet/servlet-api/2.3/servlet-api-2.3.jar:/root/.m2/repository/com/google/gwt/gwt-user/2.3.0/gwt-user-2.3.0.jar:/root/.m2/repository/javax/validation/validation-api/1.0.0.GA/validation-api-1.0.0.GA.jar:/root/.m2/repository/javax/validation/validation-api/1.0.0.GA/validation-api-1.0.0.GA-sources.jar:/root/.m2/repository/com/google/gwt/gwt-dev/2.3.0/gwt-dev-2.3.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0-sources.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/uicommonweb/target/uicommonweb-3.2.0-sources.jarcom.google.gwt.dev.Compiler -gen /root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/webadmin/gen -logLevel INFO -style OBF -war /root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/webadmin/target/webadmin-3.2.0 -localWorkers 2 org.ovirt.engine.ui.webadmin.WebAdmin [ERROR] ]] failed with status 137 [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :webadmin make: *** [tmp.built] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.p0jiQq (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.p0jiQq (%build) what am I doing wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christopher.Morrissey at netapp.com Tue Apr 2 23:17:31 2013 From: Christopher.Morrissey at netapp.com (Morrissey, Christopher) Date: Tue, 2 Apr 2013 23:17:31 +0000 Subject: [Engine-devel] UI Plugin API improvements In-Reply-To: <678163471.20791553.1364484299073.JavaMail.root@redhat.com> References: <1401998609.20784520.1364483303436.JavaMail.root@redhat.com> <678163471.20791553.1364484299073.JavaMail.root@redhat.com> Message-ID: Great job on the dialog support, Vojtech! It's working very well for me. I am having an issue with the REST session ID that I haven't been able to nail down. It seems to be timing out rather quickly. Somewhere between 15 and 30 seconds if I don't use it explicitly. I've seen the code that is scheduled to run every minute to keep it alive, but it looks like the timeout is happening so quickly that the heartbeat can't keep it alive. Any idea on why this would be happening? -Chris > -----Original Message----- > From: engine-devel-bounces at ovirt.org [mailto:engine-devel- > bounces at ovirt.org] On Behalf Of Vojtech Szocs > Sent: Thursday, March 28, 2013 11:25 AM > To: engine-devel > Cc: Spenser Shumaker; Ren? Koch; Morrissey, Christopher > Subject: [Engine-devel] UI Plugin API improvements > > Hi guys, > > I've just merged some UI Plugin patches that improve existing API functions, > as well as add some new API functions. Please read on to learn what's new. > > > Modal dialog API > ================ > > Function improved: showDialog > > New signature: > showDialog(title, dialogToken, contentUrl, width, height [, options]) > > Example usage: > showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', > '600px', { > // Default value = empty array (no buttons) > buttons: [ > { > label: 'Do stuff', > onClick: function() { > alert('Bump!'); > } > } > ], > > // Default value = false > resizeEnabled: true, > > // Default value = true > closeIconVisible: true, > > // Default value = true > closeOnEscKey: true > }); > > Notable changes: > * modal dialogs now look & feel the same as standard WebAdmin dialogs > * width & height are strings containing CSS units > * the reason why buttons default to empty array is to give plugin authors the > choice to provide custom buttons (or similar input elements) via dialog > content (iframe), and use HTML5 window.postMessage to call the plugin > (coming soon!) > > -- > > New function: setDialogContentUrl > > New signature: > setDialogContentUrl(dialogToken, contentUrl) > > Example usage: > setDialogContentUrl('my-dialog', 'http://www.example.com/') > > -- > > New function: closeDialog > > New signature: > closeDialog(dialogToken) > > Example usage: > closeDialog('my-dialog') > > > Tab API > ======= > > Functions improved: addMainTab & addSubTab > > New signatures: > addMainTab(label, historyToken, contentUrl [, options]) > addSubTab(entityTypeName, label, historyToken, contentUrl [, options]) > > Example usage: > > // Tab is left-aligned by default > addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/'); > > // Tab is right-aligned via options object > addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { > alignRight: true > }); > > -- > > Regards, > Vojtech > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From shuming at linux.vnet.ibm.com Wed Apr 3 02:56:15 2013 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Wed, 03 Apr 2013 10:56:15 +0800 Subject: [Engine-devel] [RFC] new power management protocol "libvirtp" In-Reply-To: <20130402065043.GE24503@redhat.com> References: <515A3F50.6030001@linux.vnet.ibm.com> <20130402065043.GE24503@redhat.com> Message-ID: <515B9A4F.8060600@linux.vnet.ibm.com> Dan Kenigsberg: > On Tue, Apr 02, 2013 at 10:15:44AM +0800, Shu Ming wrote: >> Hi, >> >> In oVirt environment, power manager should be enabled for the host to >> support VM high availability in the cluster. Various kinds of >> physical power management protocol are supported, ie., ALOM, ILO&etc. >> However, when the oVirt is running on a nested KVM >> environment, there is no feasible way to do the power management of the >> VDSM host(also a KVM virtual machine). A new protocol >> will be based on libvirt to achieve the power management of a virtual >> host. The new protocol can be named as "libvirtp". >> >> In oVirt engine, a new type will be added to >> >> power management---> type libvirtp >> power management--->address it will be the IP of the physical host where >> the virtual VDSM host is on when "libvirtp" is selected >> power management--->user name it will be the user name to the libvirtd >> service >> power management--->password it will be the password to the libvirtd service >> power management--->port it will be the port to the libvirtd service > Have you looked into fence_virsh or fence_virt ? Don't they provide > what you want? > Thanks for your reminder. I think fence_virsh or fence_virt can be leveraged to achieve the goal.. For fence_virsh, it requires virsh to be installed on the vdsm virtual host. For fence_virt, it requires fence_virtd to be installed on the vdsm virtual host and it is not libvirt centric. With these two power management protocol, the oVirt engine still need change to integrate these two protocols for the host power management. -- --- ?? Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming at cn.ibm.com or shuming at linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC From kmayilsa at redhat.com Wed Apr 3 04:23:16 2013 From: kmayilsa at redhat.com (Kanagaraj) Date: Wed, 03 Apr 2013 09:53:16 +0530 Subject: [Engine-devel] Java 7, revisited again In-Reply-To: <1300679206.218645.1364909600566.JavaMail.root@redhat.com> References: <1300679206.218645.1364909600566.JavaMail.root@redhat.com> Message-ID: <515BAEB4.4060301@redhat.com> On 04/02/2013 07:03 PM, Allon Mureinik wrote: > Hola, > > A couple of weeks (months?) ago we discussed upgrading to Java 7.[1] > Generally, there was a positive vibe about moving forward with technology, > although we noted that this should not be done for common, compat and the GWT modules, searchbackend is also used by GWT, this needs to be excluded as well. Thanks, Kanagaraj > under the limitation of the current GWT version we're using. > > Here's an initial suggestion for this upgrade: > http://gerrit.ovirt.org/#/c/13519/ > > Areas handled and checked: > 1. compilation (including GWT compilation)[2] > 2. animal-sniffer validations for to makes sure that modules that aren't supposed to use JDK7 features really don't[2] > 3. Running and making sure the UI still works :-) > (checkstyle issues which Laslo pointed out in the original discussion were already solved in a different patch merged long ago) > > > Sincerely, > Allon and Alissa > > [1] http://lists.ovirt.org/pipermail/engine-devel/2012-December/003139.html > [2] This includes, of course, purposely introducing Java 7 syntax and JDK 7 features to modules that aren't supposed to have them, > and making sure that the build fails early, as expected, without having to add the -Pgwt-admin or -Pgwt-user profiles. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From amureini at redhat.com Wed Apr 3 07:06:34 2013 From: amureini at redhat.com (Allon Mureinik) Date: Wed, 3 Apr 2013 03:06:34 -0400 (EDT) Subject: [Engine-devel] Java 7, revisited again In-Reply-To: <515BAEB4.4060301@redhat.com> References: <1300679206.218645.1364909600566.JavaMail.root@redhat.com> <515BAEB4.4060301@redhat.com> Message-ID: <532853312.532229.1364972794164.JavaMail.root@redhat.com> Good point, thanks! Fixed up the patch and uploaded a new version. ----- Original Message ----- > From: "Kanagaraj" > To: "Allon Mureinik" > Cc: "engine-devel" > Sent: Wednesday, April 3, 2013 7:23:16 AM > Subject: Re: [Engine-devel] Java 7, revisited again > > On 04/02/2013 07:03 PM, Allon Mureinik wrote: > > Hola, > > > > A couple of weeks (months?) ago we discussed upgrading to Java 7.[1] > > Generally, there was a positive vibe about moving forward with technology, > > although we noted that this should not be done for common, compat and the > > GWT modules, > > searchbackend is also used by GWT, this needs to be excluded as well. > > Thanks, > Kanagaraj > > > under the limitation of the current GWT version we're using. > > > > Here's an initial suggestion for this upgrade: > > http://gerrit.ovirt.org/#/c/13519/ > > > > Areas handled and checked: > > 1. compilation (including GWT compilation)[2] > > 2. animal-sniffer validations for to makes sure that modules that aren't > > supposed to use JDK7 features really don't[2] > > 3. Running and making sure the UI still works :-) > > (checkstyle issues which Laslo pointed out in the original discussion were > > already solved in a different patch merged long ago) > > > > > > Sincerely, > > Allon and Alissa > > > > [1] http://lists.ovirt.org/pipermail/engine-devel/2012-December/003139.html > > [2] This includes, of course, purposely introducing Java 7 syntax and JDK 7 > > features to modules that aren't supposed to have them, > > and making sure that the build fails early, as expected, without > > having to add the -Pgwt-admin or -Pgwt-user profiles. > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From jhernand at redhat.com Wed Apr 3 07:32:54 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Wed, 03 Apr 2013 09:32:54 +0200 Subject: [Engine-devel] ovirt 3.2 build from srpm In-Reply-To: References: Message-ID: <515BDB26.6070404@redhat.com> On 04/02/2013 05:38 PM, Paco qw wrote: > Hi! > > Trying to build an RPM of ovirt in Centos 6.4. > Srpms take away http://resources.ovirt.org/releases/3.2/rpm/EL/6/SRPMS/ > ?ommand to execute > rpmbuild --rebuild otopi -- OK > rpmbuild --rebuild ovirt-host-deploy -- OK > install otopi and ovirt-host-deploy > rpmbuild --rebuild ovirt-engine-3.2.1-1.el6.src.rpm > > as a result of getting an error message > > [INFO] Compiling 6 permutations > [INFO] Compiling permutation 0... > [INFO] Process output > [INFO] [ERROR] [AppClassLoader at 75da931b] info AspectJ Weaver > Version 1.6.11 built on Tuesday Mar 15, 2011 at 15:31:04 GMT > [INFO] [ERROR] [AppClassLoader at 75da931b] info register classloader > sun.misc.Launcher$AppClassLoader at 75da931b > [INFO] [ERROR] [AppClassLoader at 75da931b] info using configuration > file:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0.jar!/META-INF/aop.xml > [INFO] [ERROR] [AppClassLoader at 75da931b] info using configuration > file:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0-sources.jar!/META-INF/aop.xml > [INFO] [ERROR] [AppClassLoader at 75da931b] info register aspect > org.ovirt.engine.ui.gwtextension.DontPrune > [INFO] [ERROR] [AppClassLoader at 75da931b] info register aspect > org.ovirt.engine.ui.gwtextension.DontPrune > [INFO] Compiling > [INFO] Compiling permutation 1... > [INFO] [WARN] Lost communication with remote process > [INFO] java.io.EOFException > [INFO] at > java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2577) > [INFO] at > java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1315) > [INFO] at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369) > [INFO] at > com.google.gwt.dev.ExternalPermutationWorkerFactory$ExternalPermutationWorker.compile(ExternalPermutationWorkerFactory.java:150) > [INFO] at > com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73) > [INFO] at java.lang.Thread.run(Thread.java:722) > > [INFO] Compiling permutation 2... > [INFO] > ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] ovirt-root ........................................ SUCCESS [1.311s] > [INFO] oVirt Build Tools root ............................ SUCCESS [0.026s] > [INFO] oVirt checkstyle .................................. SUCCESS [2.206s] > [INFO] oVirt JBoss Modules Maven Plugin .................. SUCCESS [7.823s] > [INFO] oVirt Checkstyle Checks ........................... SUCCESS [1.712s] > [INFO] oVirt Modules - backend ........................... SUCCESS [0.020s] > [INFO] oVirt Manager ..................................... SUCCESS [0.039s] > [INFO] oVirt DB Scripts .................................. SUCCESS [0.299s] > [INFO] oVirt Engine dependencies ......................... SUCCESS [2.053s] > [INFO] oVirt Modules - manager ........................... SUCCESS [1.845s] > [INFO] CSharp Compatibility .............................. SUCCESS [6.803s] > [INFO] Common Code ....................................... SUCCESS [19.745s] > [INFO] Common utilities .................................. SUCCESS [10.625s] > [INFO] Data Access Layer ................................. SUCCESS [16.322s] > [INFO] engine beans ...................................... SUCCESS [0.098s] > [INFO] engine scheduler bean ............................. SUCCESS [3.615s] > [INFO] Vds broker ........................................ SUCCESS [11.356s] > [INFO] Search Backend .................................... SUCCESS [5.869s] > [INFO] Backend Logic @Service bean ....................... SUCCESS [29.194s] > [INFO] oVirt RESTful API Backend Integration ............. SUCCESS [0.369s] > [INFO] oVirt RESTful API interface ....................... SUCCESS [0.147s] > [INFO] oVirt Engine API Definition ....................... SUCCESS [12.313s] > [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS [0.130s] > [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS [5.514s] > [INFO] oVirt RESTful API Backend Integration Type Mappers SUCCESS [8.108s] > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources SUCCESS > [19.997s] > [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS [1.065s] > [INFO] oVirt Engine Web Root ............................. SUCCESS [2.290s] > [INFO] oVirt Engine Tools ................................ SUCCESS [5.784s] > [INFO] oVirt Modules :: Frontend ......................... SUCCESS [0.020s] > [INFO] oVirt APIs ........................................ SUCCESS [0.123s] > [INFO] oVirt generic API ................................. SUCCESS [4.327s] > [INFO] oVirt Modules :: Webadmin ......................... SUCCESS [0.033s] > [INFO] oVirt Modules - ui ................................ SUCCESS [0.031s] > [INFO] Extensions for GWT ................................ SUCCESS [2.283s] > [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS [3.808s] > [INFO] Frontend for GWT UI Projects ...................... SUCCESS [6.468s] > [INFO] UICommonWeb ....................................... SUCCESS [24.879s] > [INFO] oVirt GWT UI common infrastructure ................ SUCCESS [29.410s] > [INFO] WebAdmin .......................................... FAILURE > [28:10.304s] > [INFO] UserPortal ........................................ SKIPPED > [INFO] oVirt WARs ........................................ SKIPPED > [INFO] oVirt Web Application Module ...................... SKIPPED > [INFO] oVirt Server EAR .................................. SKIPPED > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 32:21.698s > [INFO] Finished at: Tue Apr 02 23:18:37 MSK 2013 > [INFO] Final Memory: 288M/707M > [INFO] > ------------------------------------------------------------------------ > [ERROR] Failed to execute goal > org.codehaus.mojo:gwt-maven-plugin:2.3.0-1:compile (gwtcompile) on project > webadmin: Command [[ > [ERROR] /bin/sh -c > /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/bin/java > -javaagent:/root/.m2/repository/org/aspectj/aspectjweaver/1.6.11/aspectjweaver-1.6.11.jar > -Xms1024M -Xmx2048M -XX:PermSize=256M -XX:MaxPermSize=256M > '-Dgwt.dontPrune=org\.ovirt\.engine\.core\.(common|compat)\..*' -classpath > /root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/webadmin/src/main/java:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/webadmin/target/generated-sources/annotations:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/webadmin/target/generated-sources/gwt:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/webadmin/src/main/resources:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/webadmin/target/webadmin-3.2.0/WEB-INF/classes:/root/.m2/repository/com/google/gwt/gwt-user/2.3.0/gwt-user-2.3.0.jar:/root/.m2/repository/com/google/gwt/gwt-dev/2.3.0/gwt-dev-2.3.0.jar:/root/.m2/repository/com/gwtplatform/gwtp-mvp-client/0.6/gwtp-mvp-client-0.6.jar:/root/.m2/repository/com/gwtplatform/gwtp-clients-common/0.6/gwtp-clients-common-0.6.jar:/root/.m2/repository/com/gwtplatform/gwtp-processors/0.6/gwtp-processors-0.6.jar:/root/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar:/root/.m2/repository/ja! vax/inject /javax.inject/1/javax.inject-1.jar:/root/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/root/.m2/repository/com/google/inject/extensions/guice-assistedinject/3.0/guice-assistedinject-3.0.jar:/root/.m2/repository/com/google/gwt/inject/gin/1.5.0/gin-1.5.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/uicommonweb/target/uicommonweb-3.2.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/backend/manager/modules/searchbackend/target/searchbackend-3.2.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/backend/manager/modules/compat/target/compat-3.2.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/uicompat/target/uicompat-3.2.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/backend/manager/modules/common/target/common-3.2.0-sources.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/backend/manager/modules/compat/target/compat-3.2.0-sources.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/backend/manager/modules/searchbackend/target/searchbacke! nd-3.2.0-s ources.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/gwt-common/target/gwt-common-3.2.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/api/genericapi/target/genericapi-3.2.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/backend/manager/modules/common/target/common-3.2.0.jar:/root/.m2/repository/org/hibernate/hibernate-validator/ > 4.0.2.GA/hibernate-validator-4.0.2.GA.jar:/root/.m2/repository/javax/validation/validation-api/1.0.0.GA/validation-api-1.0.0.GA.jar:/root/.m2/repository/org/slf4j/slf4j-api/1.5.6/slf4j-api-1.5.6.jar:/root/.m2/repository/com/sun/xml/bind/jaxb-impl/2.1.3/jaxb-impl-2.1.3.jar:/root/.m2/repository/org/hibernate/hibernate-annotations/3.4.0.GA/hibernate-annotations-3.4.0.GA.jar:/root/.m2/repository/org/hibernate/ejb3-persistence/1.0.2.GA/ejb3-persistence-1.0.2.GA.jar:/root/.m2/repository/org/hibernate/hibernate-commons-annotations/3.1.0.GA/hibernate-commons-annotations-3.1.0.GA.jar:/root/.m2/repository/org/hibernate/hibernate-core/3.3.0.SP1/hibernate-core-3.3.0.SP1.jar:/root/.m2/repository/antlr/antlr/2.7.6/antlr-2.7.6.jar:/root/.m2/repository/commons-collections/commons-collections/3.1/commons-collections-3.1.jar:/root/.m2/repository/javax/transaction/jta/1.1/jta-1.1.jar:/root/.m2/repository/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar:/root/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis! -1.0.b2.ja r:/root/.m2/repository/org/codehaus/jackson/jackson-mapper-asl/1.9.4/jackson-mapper-asl-1.9.4.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/backend/manager/modules/utils/target/utils-3.2.0.jar:/root/.m2/repository/commons-beanutils/commons-beanutils/1.8.2/commons-beanutils-1.8.2.jar:/root/.m2/repository/org/apache/mina/mina-core/2.0.1/mina-core-2.0.1.jar:/root/.m2/repository/org/apache/sshd/sshd-core/0.7.0/sshd-core-0.7.0.jar:/root/.m2/repository/org/ovirt/otopi/otopi/1.0.0/otopi-1.0.0.jar:/root/.m2/repository/org/ovirt/ovirt-host-deploy/ovirt-host-deploy/1.0.0/ovirt-host-deploy-1.0.0.jar:/root/.m2/repository/org/apache/commons/commons-compress/1.3/commons-compress-1.3.jar:/root/.m2/repository/commons-lang/commons-lang/2.6/commons-lang-2.6.jar:/root/.m2/repository/commons-codec/commons-codec/1.4/commons-codec-1.4.jar:/root/.m2/repository/org/apache/xmlrpc/xmlrpc-client/3.1.3/xmlrpc-client-3.1.3.jar:/root/.m2/repository/org/apache/xmlrpc/xmlrpc-common/3.1.3/xmlrpc-common-3.1.3.! jar:/root/ .m2/repository/org/apache/ws/commons/util/ws-commons-util/1.0.2/ws-commons-util-1.0.2.jar:/root/.m2/repository/commons-httpclient/commons-httpclient/3.1/commons-httpclient-3.1.jar:/root/.m2/repository/org/codehaus/jackson/jackson-core-asl/1.9.4/jackson-core-asl-1.9.4.jar:/root/.m2/repository/org/springframework/spring-core/3.1.1.RELEASE/spring-core-3.1.1.RELEASE.jar:/root/.m2/repository/org/springframework/spring-asm/3.1.1.RELEASE/spring-asm-3.1.1.RELEASE.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/frontend/target/frontend-3.2.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0.jar:/root/.m2/repository/javax/xml/bind/jaxb-api/2.1/jaxb-api-2.1.jar:/root/.m2/repository/javax/xml/stream/stax-api/1.0-2/stax-api-1.0-2.jar:/root/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar:/root/.m2/repository/org/jboss/spec/javax/ejb/jboss-ejb-api_3.1_spec/1.0.1.Final/jboss-ejb-api_3.1_spec! -1.0.1.Fin al.jar:/root/.m2/repository/org/aspectj/aspectjweaver/1.6.11/aspectjweaver-1.6.11.jar:/root/.m2/repository/commons-logging/commons-logging/1.1/commons-logging-1.1.jar:/root/.m2/repository/log4j/log4j/1.2.16/log4j-1.2.16.jar:/root/.m2/repository/logkit/logkit/1.0.1/logkit-1.0.1.jar:/root/.m2/repository/avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.jar:/root/.m2/repository/javax/servlet/servlet-api/2.3/servlet-api-2.3.jar:/root/.m2/repository/com/google/gwt/gwt-user/2.3.0/gwt-user-2.3.0.jar:/root/.m2/repository/javax/validation/validation-api/1.0.0.GA/validation-api-1.0.0.GA.jar:/root/.m2/repository/javax/validation/validation-api/1.0.0.GA/validation-api-1.0.0.GA-sources.jar:/root/.m2/repository/com/google/gwt/gwt-dev/2.3.0/gwt-dev-2.3.0.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/gwt-extension/target/gwt-extension-3.2.0-sources.jar:/root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/uicommonweb/target/uicommonweb-3.2.0-! sources.ja rcom.google.gwt.dev.Compiler > -gen > /root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/webadmin/gen > -logLevel INFO -style OBF -war > /root/rpmbuild/BUILD/ovirt-engine-3.2.1/frontend/webadmin/modules/webadmin/target/webadmin-3.2.0 > -localWorkers 2 org.ovirt.engine.ui.webadmin.WebAdmin > [ERROR] ]] failed with status 137 > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, > please read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the > command > [ERROR] mvn -rf :webadmin > make: *** [tmp.built] Error 1 > error: Bad exit status from /var/tmp/rpm-tmp.p0jiQq (%build) > > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.p0jiQq (%build) > > > what am I doing wrong? > The exit code 137 that you get probably means that the Java virtual machine was killed with signal 9 (137 = 128 + 9). If you didn't kill it manually then it was probably killed by the "out of memory killer" of the kernel. This means that you don't have enough memory in that machine to run the full build. Either increase available memory or reduce the number of permutations (currently you are building 6 permutations). For example, if you want to make sure that all your builds will only build the GUI for Mozilla Firefox create the $HOME/.m2/settings.xml file with the following content: oVirt oVirt gecko1_8 If you really need to build for all the browsers then you need to increase the available memory in your build environment. -- 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 eedri at redhat.com Thu Apr 4 06:25:20 2013 From: eedri at redhat.com (Eyal Edri) Date: Thu, 4 Apr 2013 02:25:20 -0400 (EDT) Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - Build # 3868 - Still Unstable! In-Reply-To: <1055735559.4842.1365054764222.JavaMail.jenkins@jenkins.ovirt.org> References: <1331011769.4769.1365015004313.JavaMail.jenkins@jenkins.ovirt.org> <1055735559.4842.1365054764222.JavaMail.jenkins@jenkins.ovirt.org> Message-ID: <1127172130.1098714.1365056720422.JavaMail.root@redhat.com> fyi, these commits introduced new HIGH priority BUGS (via findbugs) [1]: [Gerrit Code Review] webadmin: Disable destroy on Storage Domain when active [Gerrit Code Review] webadmin: Added POSIX options in Storage general sub tab [Gerrit Code Review] webadmin: Added NFS advanced options in Storage general please fix asap, Eyal Edri oVirt infra team [1] http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3868/findbugsResult/HIGH/? ----- Original Message ----- > From: "Jenkins ci oVirt Server" > To: eedri at redhat.com, engine-patches at ovirt.org, oliel at redhat.com, yzaslavs at redhat.com, dcaro at redhat.com, > gerrit2 at gerrit.ovirt.org > Sent: Thursday, April 4, 2013 8:52:43 AM > Subject: [oVirt Jenkins] ovirt_engine_find_bugs - Build # 3868 - Still Unstable! > > Project: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/ > Build: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3868/ > Build Number: 3868 > Build Status: Still Unstable > Triggered By: Started by an SCM change > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #3862 > [Gerrit Code Review] webadmin: Disable destroy on Storage Domain when active > > [Gerrit Code Review] webadmin: Added POSIX options in Storage general sub tab > > [Gerrit Code Review] webadmin: Added NFS advanced options in Storage general > sub tab > > > Changes for Build #3863 > [Gerrit Code Review] Revert "core: on handing over a VM mark it as > MigratingTo" > > > Changes for Build #3864 > [Gerrit Code Review] webadmin: 'Vnic status' column was truncated in 'ja' > locale > > [Gerrit Code Review] Edit Network dialog is cropped in 'es' locale > > [Einav Cohen] webadmin, userportal: translations update > > > Changes for Build #3865 > [Einav Cohen] webadmin, userportal: introducing German (de) - part 1 > > [Einav Cohen] userportal, webadmin: introducing German (de) - part 2 > > [Gerrit Code Review] history: fixed user usage data collection (#926952) > > [Gerrit Code Review] history: fixed storage domain status collection > (#922499) > > > Changes for Build #3866 > [Gerrit Code Review] core: on handing over a VM mark it as MigratingTo > > > Changes for Build #3867 > [Einav Cohen] webadmin: remove hide popup feature. > > > Changes for Build #3868 > [Gerrit Code Review] pki: cleanup: Found reliance on default encoding > > > > > ----------------- > Failed Tests: > ----------------- > No tests ran. > > From lhornyak at redhat.com Thu Apr 4 06:33:30 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Thu, 4 Apr 2013 02:33:30 -0400 (EDT) Subject: [Engine-devel] nfs storage domain creation hangs forever In-Reply-To: <1000125552.1365798.1365004208333.JavaMail.root@redhat.com> Message-ID: <1984155576.1813846.1365057210555.JavaMail.root@redhat.com> Hi, After fetch&rebase the NFS storage does not initialize. The master domain creation waits forever. I use Compat version 3.2. Does anyone have the same problem? Thank you, Laszlo From yzaslavs at redhat.com Thu Apr 4 06:35:33 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 4 Apr 2013 02:35:33 -0400 (EDT) Subject: [Engine-devel] nfs storage domain creation hangs forever In-Reply-To: <1984155576.1813846.1365057210555.JavaMail.root@redhat.com> References: <1984155576.1813846.1365057210555.JavaMail.root@redhat.com> Message-ID: <1601341173.1703533.1365057333402.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Laszlo Hornyak" > To: "engine-devel" > Sent: Thursday, April 4, 2013 9:33:30 AM > Subject: [Engine-devel] nfs storage domain creation hangs forever > > Hi, > > After fetch&rebase the NFS storage does not initialize. The master domain > creation waits forever. I use Compat version 3.2. Does anyone have the same > problem? Did you mean oVirt-3.2 by any chance? > > Thank you, > Laszlo > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From lhornyak at redhat.com Thu Apr 4 06:43:29 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Thu, 4 Apr 2013 02:43:29 -0400 (EDT) Subject: [Engine-devel] nfs storage domain creation hangs forever In-Reply-To: <1601341173.1703533.1365057333402.JavaMail.root@redhat.com> References: <1984155576.1813846.1365057210555.JavaMail.root@redhat.com> <1601341173.1703533.1365057333402.JavaMail.root@redhat.com> Message-ID: <833252283.1814766.1365057809581.JavaMail.root@redhat.com> No I mean DC compat version is set to 3.2. ----- Original Message ----- > From: "Yair Zaslavsky" > To: "Laszlo Hornyak" > Cc: "engine-devel" > Sent: Thursday, April 4, 2013 8:35:33 AM > Subject: Re: [Engine-devel] nfs storage domain creation hangs forever > > > > ----- Original Message ----- > > From: "Laszlo Hornyak" > > To: "engine-devel" > > Sent: Thursday, April 4, 2013 9:33:30 AM > > Subject: [Engine-devel] nfs storage domain creation hangs forever > > > > Hi, > > > > After fetch&rebase the NFS storage does not initialize. The master domain > > creation waits forever. I use Compat version 3.2. Does anyone have the same > > problem? > > Did you mean oVirt-3.2 by any chance? > > > > > Thank you, > > Laszlo > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From sabose at redhat.com Thu Apr 4 06:46:18 2013 From: sabose at redhat.com (Sahina Bose) Date: Thu, 04 Apr 2013 12:16:18 +0530 Subject: [Engine-devel] FeatureSupported and compatibility versions In-Reply-To: <515ABA63.4070106@redhat.com> References: <36623975.7044697.1364386718971.JavaMail.root@redhat.com> <51543BF5.3050505@redhat.com> <1842623267.574910.1364894251176.JavaMail.root@redhat.com> <515ABA63.4070106@redhat.com> Message-ID: <515D21BA.7000906@redhat.com> The idea should be to make sure that maintaining the feature supported matrix is not a nightmare. If we need to go and replicate entries in 0000_config.sql file for each new version, then this is an issue. And I think we are all in agreement that this is not the way to go. Either we go with [1]. default value in ConfigValues, and only changed value in db script like in patch set 5 (http://gerrit.ovirt.org/#/c/12970/5) If this mechanism is broken, do you know where/what is broken? or [2] . with the new approach where a Feature supported changes to true/false **from** a particular version. (I think, for gluster features, the Feature From works for us as we do not see it changing from version to version once supported. ) But if there's a way to fix 1, let's do that to get this moving. Mike, could you elaborate on what needs to be fixed in [1] ? On 04/02/2013 04:30 PM, Shireesh Anjal wrote: > On 04/02/2013 02:47 PM, Mike Kolesnik wrote: >> ------------------------------------------------------------------------ >> >> On 03/27/2013 05:48 PM, Mike Kolesnik wrote: >> >> ----- Original Message ----- >> >> On 03/20/2013 08:20 PM, Yair Zaslavsky wrote: >> >> ----- Original Message ----- >> >> From: "Shireesh Anjal" >> To: "Mike Kolesnik" >> Cc:engine-devel at ovirt.org >> Sent: Wednesday, March 20, 2013 4:47:08 PM >> Subject: Re: [Engine-devel] FeatureSupported and compatibility >> versions >> >> On 03/18/2013 01:11 PM, Shireesh Anjal wrote: >> >> On 03/18/2013 12:59 PM, Mike Kolesnik wrote: >> >> ----- Original Message ----- >> >> Hi all, >> >> The current mechanism in oVirt to check whether a feature is >> supported >> in a particular compatibility version is to use the >> FeatureSupported >> class. e.g. >> >> FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion()) >> >> >> Checks whether the "network linking" feature is supported for >> the >> the >> VM's cluster compatibility version. This internally checks >> whether >> the >> value of the corresponding config (NetworkLinkingSupported) for >> the >> given compatibility version is true/false. >> >> I'm not sure if this is a good idea, since a feature is >> typically >> supported "from" a particular version. E.g. Gluster support was >> introduced in 3.1, and it continues to be available in all >> subsequent >> versions. So I see no point in adding configuration for every >> version >> indicating whether the feature is supported in that version or >> not. I >> suggest to use either of the following options: >> >> You can "merge" the configs into a single config when older >> versions >> go out of the supported versions for the system. >> >> i.e. in 4.0 you can have upgrade script that merges all >> GlusterFeatureSupported to one entry instead of several. >> >> Why are we even storing this information in config? Is this >> something >> that can be "configured" at customer site? >> >> As previously explained (but off list :) ) , Config gives you the >> ability to have a cachable "map" of entry (i.e - "feature name") >> per version and value. >> I guess it was convinient for the developers to use that. >> I also mentioned that customers/oVirt users should config the >> entries of vdc_options using engine-config tool only. >> Not all entries are exposed via engine-config.properties (and no, >> not just "is feature supported" entries are hidden). >> >> >> >> >> 1) Instead of using a boolean config for each version, use a >> single >> string config that indicates the "supported from" version e.g. >> GlusterSupportedFrom = 3.1. There could be rare cases where a >> feature, >> for some reason, is removed in some release. In such cases, we >> could >> use >> one additional config for the "supported to" version. >> >> 2) Continue with the boolean approach, but do not have entries >> for >> every >> version; rather make use of the "default value" for majority of >> cases, >> and add the explicit version mapping for the minority e.g. >> GlusterSupported = true by default, and false in case of 3.0 >> (only >> one >> config required for 3.0) >> >> I'm not sure why we would want to complicate this simple >> mechanism? >> >> Is there much to gain? >> >> I think option 1 suggested above is simpler - to implement as >> well >> as >> to understand. >> >> Let me give you an example of why I don't like current mechanism. >> I >> introduce a version check for a feature that was introduced in >> 3.1. >> I'm being asked now to add three entries in config >> >> 3.0 - false >> 3.1 - true >> 3.2 - true >> >> It will also mean that when 3.3 goes out, someone has to make >> sure >> that another entry is added for 3.3-true. I think it is not >> logical >> as >> well as scalable if you have more versions. And it sounds far >> more >> complex (to maintain) than just having >> >> SupportedFrom = 3.1 >> >> So I would like to know if there are any objections to my >> proposal. >> I >> intend to use this for at least the gluster related features. >> >> I've sent a patch (http://gerrit.ovirt.org/12970) with following >> changes: >> >> 1) Introduced CompatibilityUtils that provides utility methods for >> checking if a given feature is supported in the config. One method to >> check based on boolean values (as is being done today for virt >> features), and nother to check based on a range (from, to) which I >> would >> like to use for gluster features. >> 2) Renamed FeatureSupported to VirtFeatureSupported, and made it use >> the >> first utility method from CompatibilityUtils >> 3) Introduced GlusterFeatureSupported for gluster features, which >> uses >> the second utility method from CompatibilityUtils >> >> Key advantage here is that >> - we don't have to touch any virt specifc source for adding >> compatibility checks for gluster features >> - virt features continue to use the existing boolean config check >> >> Any comments / suggestions / reviews will be highly appreciated :) >> >> I think splitting to two classes is OK, but the underlying mechanism IMO should be as Omer suggested: >> Use the default value from the java config file, and if in the DB there is a version specific value then use it for that version only. >> >> >> Review comments here are on the contrary: >> http://gerrit.ovirt.org/#/c/12970/5/backend/manager/dbscripts/upgrade/pre_upgrade/0000_config.sql >> >> The comment in the review simply states that the mechanism is >> probably broken, not that that's the way it has to be done. > > The comment explicitly asks me to add entries for every version. What > you have looked at is my response to this comment, which suggests that > the current mechanism is not great. In fact, what I had done in > patch-set 5 is exactly what you are suggesting : true as default value > and explicit entries in config for the "false" values. But it was not > accepted. > >> >> I don't think "From, To, etc" is a good design, it's not a standard way and is very restrictive. >> >> >> Can you please explain in what way is it restrictive? >> >> Also, what is the "etc" you are referring to? >> >> What if for certain version it is not supported, you add "except"? Or >> do you specify 2 ranges? >> >> Starting to add from/to creates a limited design of one range, which >> would be difficult to tune if necessary. > > Really? Does someone really think that there will be a feature that > will be supported in multiple different ranges of versions? I see zero > possibility for this. I would love to see some +1s on this concept > before I can accept this argument. > >> I think the design generally for config values is very simple and >> suits us well - use the default value, unless a specific version is >> configured differently. > > I think the current design is wrong. A feature gets supported "from" a > particular version, and that's all that is required in most of the > cases. Expecting developers to add version-by-version mapping for > features is bad. The "to" part in my patch is just to handle rare > cases, if at all they come up. I'm willing to even remove that if such > a case doesn't exist today. > > Also, even though I have followed it for the sake of consistency, I > don't think these values need to be stored in the config (db) at all. > Only explanation I've got for it is that it was probably 'convenient' > for developers to use the config mechanism. I'm for having this check > purely in code in a central place, and not the config (db). > >> This way you can specify the feature is supported, and disable it for >> specific versions. > > So one has to look at both code (FeatureSupported) as well as db > (config) to get an idea of what versions the feature is supported in. > Not great. > >> I think this direction gives us the flexibility that we would like to >> have. >> >> Currently it doesn't work that way, but I think it's not impossible >> to change, and more worthwhile than introducing a new mechanism. > > I disagree, and would like to use the "supported from" mechanism at > least for gluster features. > >> >> Thoughts? >> >> Regards, >> Shireesh >> >> >> > > > > _______________________________________________ > 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: From tjelinek at redhat.com Thu Apr 4 07:49:55 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Thu, 4 Apr 2013 03:49:55 -0400 (EDT) Subject: [Engine-devel] nfs storage domain creation hangs forever In-Reply-To: <833252283.1814766.1365057809581.JavaMail.root@redhat.com> References: <1984155576.1813846.1365057210555.JavaMail.root@redhat.com> <1601341173.1703533.1365057333402.JavaMail.root@redhat.com> <833252283.1814766.1365057809581.JavaMail.root@redhat.com> Message-ID: <1666126945.468897.1365061795868.JavaMail.root@redhat.com> hi Laszlo, I face the same issue. It is a NPE on the frontend: java.lang.NullPointerException: null at org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel.saveNfsStorage(StorageListModel.java:1474) at org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel.run(StorageListModel.java:2096) at org.ovirt.engine.ui.uicompat.Task.Run(Task.java:21) at org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel.saveNfsStorage(StorageListModel.java:948) at org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel.OnSavePostNameValidation(StorageListModel.java:907) at org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel.PostStorageNameValidation(StorageListModel.java:744) at org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel$7$1.OnSuccess(StorageListModel.java:729) at org.ovirt.engine.ui.uicommonweb.dataprovider.AsyncDataProvider.GetConfigFromCache(AsyncDataProvider.java:2229) at org.ovirt.engine.ui.uicommonweb.dataprovider.AsyncDataProvider.GetStorageDomainMaxNameLength(AsyncDataProvider.java:1621) at org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel$7.OnSuccess(StorageListModel.java:716) I'll have a look what is the problem Tomas ----- Original Message ----- > From: "Laszlo Hornyak" > To: "Yair Zaslavsky" > Cc: "engine-devel" > Sent: Thursday, April 4, 2013 8:43:29 AM > Subject: Re: [Engine-devel] nfs storage domain creation hangs forever > > No I mean DC compat version is set to 3.2. > > ----- Original Message ----- > > From: "Yair Zaslavsky" > > To: "Laszlo Hornyak" > > Cc: "engine-devel" > > Sent: Thursday, April 4, 2013 8:35:33 AM > > Subject: Re: [Engine-devel] nfs storage domain creation hangs forever > > > > > > > > ----- Original Message ----- > > > From: "Laszlo Hornyak" > > > To: "engine-devel" > > > Sent: Thursday, April 4, 2013 9:33:30 AM > > > Subject: [Engine-devel] nfs storage domain creation hangs forever > > > > > > Hi, > > > > > > After fetch&rebase the NFS storage does not initialize. The master domain > > > creation waits forever. I use Compat version 3.2. Does anyone have the > > > same > > > problem? > > > > Did you mean oVirt-3.2 by any chance? > > > > > > > > Thank you, > > > 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 tjelinek at redhat.com Thu Apr 4 08:16:06 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Thu, 4 Apr 2013 04:16:06 -0400 (EDT) Subject: [Engine-devel] nfs storage domain creation hangs forever In-Reply-To: <1666126945.468897.1365061795868.JavaMail.root@redhat.com> References: <1984155576.1813846.1365057210555.JavaMail.root@redhat.com> <1601341173.1703533.1365057333402.JavaMail.root@redhat.com> <833252283.1814766.1365057809581.JavaMail.root@redhat.com> <1666126945.468897.1365061795868.JavaMail.root@redhat.com> Message-ID: <807218003.476294.1365063366963.JavaMail.root@redhat.com> OK, this simple patch http://gerrit.ovirt.org/#/c/13573/ fixes it ----- Original Message ----- > From: "Tomas Jelinek" > To: "Laszlo Hornyak" > Cc: "engine-devel" > Sent: Thursday, April 4, 2013 9:49:55 AM > Subject: Re: [Engine-devel] nfs storage domain creation hangs forever > > hi Laszlo, > > I face the same issue. It is a NPE on the frontend: > > java.lang.NullPointerException: null at > org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel.saveNfsStorage(StorageListModel.java:1474) > at > org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel.run(StorageListModel.java:2096) > at org.ovirt.engine.ui.uicompat.Task.Run(Task.java:21) at > org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel.saveNfsStorage(StorageListModel.java:948) > at > org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel.OnSavePostNameValidation(StorageListModel.java:907) > at > org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel.PostStorageNameValidation(StorageListModel.java:744) > at > org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel$7$1.OnSuccess(StorageListModel.java:729) > at > org.ovirt.engine.ui.uicommonweb.dataprovider.AsyncDataProvider.GetConfigFromCache(AsyncDataProvider.java:2229) > at > org.ovirt.engine.ui.uicommonweb.dataprovider.AsyncDataProvider.GetStorageDomainMaxNameLength(AsyncDataProvi > der.java:1621) at > org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel$7.OnSuccess(StorageListModel.java:716) > > I'll have a look what is the problem > > Tomas > > ----- Original Message ----- > > From: "Laszlo Hornyak" > > To: "Yair Zaslavsky" > > Cc: "engine-devel" > > Sent: Thursday, April 4, 2013 8:43:29 AM > > Subject: Re: [Engine-devel] nfs storage domain creation hangs forever > > > > No I mean DC compat version is set to 3.2. > > > > ----- Original Message ----- > > > From: "Yair Zaslavsky" > > > To: "Laszlo Hornyak" > > > Cc: "engine-devel" > > > Sent: Thursday, April 4, 2013 8:35:33 AM > > > Subject: Re: [Engine-devel] nfs storage domain creation hangs forever > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Laszlo Hornyak" > > > > To: "engine-devel" > > > > Sent: Thursday, April 4, 2013 9:33:30 AM > > > > Subject: [Engine-devel] nfs storage domain creation hangs forever > > > > > > > > Hi, > > > > > > > > After fetch&rebase the NFS storage does not initialize. The master > > > > domain > > > > creation waits forever. I use Compat version 3.2. Does anyone have the > > > > same > > > > problem? > > > > > > Did you mean oVirt-3.2 by any chance? > > > > > > > > > > > Thank you, > > > > 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 > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From tjelinek at redhat.com Thu Apr 4 10:07:26 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Thu, 4 Apr 2013 06:07:26 -0400 (EDT) Subject: [Engine-devel] nfs storage domain creation hangs forever In-Reply-To: <807218003.476294.1365063366963.JavaMail.root@redhat.com> References: <1984155576.1813846.1365057210555.JavaMail.root@redhat.com> <1601341173.1703533.1365057333402.JavaMail.root@redhat.com> <833252283.1814766.1365057809581.JavaMail.root@redhat.com> <1666126945.468897.1365061795868.JavaMail.root@redhat.com> <807218003.476294.1365063366963.JavaMail.root@redhat.com> Message-ID: <1123148905.523916.1365070046192.JavaMail.root@redhat.com> OK, it is merged as 35b2ea7f9ff3d5dfc5aa74a14578b4784aedccf0 (thnx Daniel) If anyone faces this issue, please update your workspace ----- Original Message ----- > From: "Tomas Jelinek" > To: "Laszlo Hornyak" > Cc: "engine-devel" > Sent: Thursday, April 4, 2013 10:16:06 AM > Subject: Re: [Engine-devel] nfs storage domain creation hangs forever > > OK, this simple patch http://gerrit.ovirt.org/#/c/13573/ fixes it > > ----- Original Message ----- > > From: "Tomas Jelinek" > > To: "Laszlo Hornyak" > > Cc: "engine-devel" > > Sent: Thursday, April 4, 2013 9:49:55 AM > > Subject: Re: [Engine-devel] nfs storage domain creation hangs forever > > > > hi Laszlo, > > > > I face the same issue. It is a NPE on the frontend: > > > > java.lang.NullPointerException: null at > > org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel.saveNfsStorage(StorageListModel.java:1474) > > at > > org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel.run(StorageListModel.java:2096) > > at org.ovirt.engine.ui.uicompat.Task.Run(Task.java:21) at > > org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel.saveNfsStorage(StorageListModel.java:948) > > at > > org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel.OnSavePostNameValidation(StorageListModel.java:907) > > at > > org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel.PostStorageNameValidation(StorageListModel.java:744) > > at > > org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel$7$1.OnSuccess(StorageListModel.java:729) > > at > > org.ovirt.engine.ui.uicommonweb.dataprovider.AsyncDataProvider.GetConfigFromCache(AsyncDataProvider.java:2229) > > at > > org.ovirt.engine.ui.uicommonweb.dataprovider.AsyncDataProvider.GetStorageDomainMaxNameLength(AsyncDataProvi > > der.java:1621) at > > org.ovirt.engine.ui.uicommonweb.models.storage.StorageListModel$7.OnSuccess(StorageListModel.java:716) > > > > I'll have a look what is the problem > > > > Tomas > > > > ----- Original Message ----- > > > From: "Laszlo Hornyak" > > > To: "Yair Zaslavsky" > > > Cc: "engine-devel" > > > Sent: Thursday, April 4, 2013 8:43:29 AM > > > Subject: Re: [Engine-devel] nfs storage domain creation hangs forever > > > > > > No I mean DC compat version is set to 3.2. > > > > > > ----- Original Message ----- > > > > From: "Yair Zaslavsky" > > > > To: "Laszlo Hornyak" > > > > Cc: "engine-devel" > > > > Sent: Thursday, April 4, 2013 8:35:33 AM > > > > Subject: Re: [Engine-devel] nfs storage domain creation hangs forever > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Laszlo Hornyak" > > > > > To: "engine-devel" > > > > > Sent: Thursday, April 4, 2013 9:33:30 AM > > > > > Subject: [Engine-devel] nfs storage domain creation hangs forever > > > > > > > > > > Hi, > > > > > > > > > > After fetch&rebase the NFS storage does not initialize. The master > > > > > domain > > > > > creation waits forever. I use Compat version 3.2. Does anyone have > > > > > the > > > > > same > > > > > problem? > > > > > > > > Did you mean oVirt-3.2 by any chance? > > > > > > > > > > > > > > Thank you, > > > > > 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 > > > > > _______________________________________________ > > 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 mpastern at redhat.com Thu Apr 4 11:13:21 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 04 Apr 2013 14:13:21 +0300 Subject: [Engine-devel] ovirt-engine-sdk-java 1.0.0.6-1 released Message-ID: <515D6051.3090604@redhat.com> - added new collection ClusterGlusterVolumeGlusterBrickStatistics - added new properties to the GlusterBrick - to vm added cpu.mode - to host install action added "image" parameter - ignore case in factory method lookup More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D From r.koch at ovido.at Fri Apr 5 12:16:07 2013 From: r.koch at ovido.at (=?ISO-8859-1?Q?Ren=E9?= Koch (ovido)) Date: Fri, 05 Apr 2013 14:16:07 +0200 Subject: [Engine-devel] UI Plugin API improvements In-Reply-To: <51576799.8070206@redhat.com> References: <678163471.20791553.1364484299073.JavaMail.root@redhat.com> <51576799.8070206@redhat.com> Message-ID: <1365164167.12727.50.camel@pc-ovido02.lan.ovido.at> Sorry for my late answer - I'm quite busy at the moment. On Sun, 2013-03-31 at 01:30 +0300, Itamar Heim wrote: > On 03/30/2013 03:12 PM, Ren? Koch wrote: > > Hi Vojtech, > > > > Thanks a lot for the information. > > Are these changes already available in latest nightly repository or do I have to fetch them from git? > > > > As UI API gets more and more features I was wondering if I can get the UI plugin API version with a JavaScript call like api.getVersion(). > > I think it could sometimes be useful for UI plugin development to get the version of UI API to be able to use the right API call - at the moment only oVirt 3.2 is available which supports UI plugins, but in future there will be more oVirt version and hopefully RHEV will also support UI plugins (at least as tech preview). > > What do you think? > > interesting point. maybe less of an issue if the ui plugin is > distributed in rpm form, and can validate minimal version. This means for example to use %post section and patch the installed files according to the oVirt version? Or require min. version of oVirt in SPEC file and create multiple RPMs: ui-plugin-1.0-1.ov32.el6.noarch.rpm => Requires: ovirt-engine >= 3.2 ui-plugin-1.0-1.ov33.el6.noarch.rpm => Requires: ovirt-engine >= 3.3 > but if a single codebase for the uiplugin is to support multiple > versions for deployment, it may want to make some features available > only if engine version is X or >X. Exactly - either make it only available if engine version is >= X or provide a workaround if possible (depending on the importance of this feature). > > so just wondering: > - do you see uiplugins distributed as rpms or some other way? I'll distribute my plugins in RPM and src form for download. What I'm doing in general (not done yet for my first UI plugin, but will follow): - use autotools for ./configure; make; make install ./configure will allow you to set www document root and some other settings. - create RPM from SPEC > - do you see uiplugin codebase trying to accomodate multiple versions, > or branch/version similar to supported engine, and one needs latest > engine for latest uiplugin, etc. I prefer one codebase for max. 2 or 3 oVirt version and branch each release. e.g: ui-plugin-1.0.x => includes code for oVirt 3.2 and oVirt 3.3 ui-plugin-1.1.x => includes code for oVirt 3.2, 3.3 and 3.4 and tag each release. More then 3 oVirt version aren't maintainable and this doesn't make sense as there want be bug fixes from oVirt team for these old version (I think). But always requiring the latest oVirt version for latest UI plugin version is also not the way I want to go, as I know that it takes some time to upgrade to newer oVirt version... I personally prefer to check UI API version in source code and decide what to do over other methods like multiple RPMs or %post patch scripts... Regards, Ren? > > Thanks, > Itamar > > > > > > > Thanks, > > Ren? > > > > > > > > -----Original message----- > >> From:Vojtech Szocs > >> Sent: Thursday 28th March 2013 16:25 > >> To: engine-devel > >> Cc: Keith Robertson ; Spenser Shumaker ; Christopher Morrissey ; Ren? Koch > >> Subject: UI Plugin API improvements > >> > >> Hi guys, > >> > >> I've just merged some UI Plugin patches that improve existing API functions, as well as add some new API functions. Please read on to learn what's new. > >> > >> > >> Modal dialog API > >> ================ > >> > >> Function improved: showDialog > >> > >> New signature: > >> showDialog(title, dialogToken, contentUrl, width, height [, options]) > >> > >> Example usage: > >> showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', '600px', { > >> // Default value = empty array (no buttons) > >> buttons: [ > >> { > >> label: 'Do stuff', > >> onClick: function() { > >> alert('Bump!'); > >> } > >> } > >> ], > >> > >> // Default value = false > >> resizeEnabled: true, > >> > >> // Default value = true > >> closeIconVisible: true, > >> > >> // Default value = true > >> closeOnEscKey: true > >> }); > >> > >> Notable changes: > >> * modal dialogs now look & feel the same as standard WebAdmin dialogs > >> * width & height are strings containing CSS units > >> * the reason why buttons default to empty array is to give plugin authors the choice to provide custom buttons (or similar input elements) via dialog content (iframe), and use HTML5 window.postMessage to call the plugin (coming soon!) > >> > >> -- > >> > >> New function: setDialogContentUrl > >> > >> New signature: > >> setDialogContentUrl(dialogToken, contentUrl) > >> > >> Example usage: > >> setDialogContentUrl('my-dialog', 'http://www.example.com/') > >> > >> -- > >> > >> New function: closeDialog > >> > >> New signature: > >> closeDialog(dialogToken) > >> > >> Example usage: > >> closeDialog('my-dialog') > >> > >> > >> Tab API > >> ======= > >> > >> Functions improved: addMainTab & addSubTab > >> > >> New signatures: > >> addMainTab(label, historyToken, contentUrl [, options]) > >> addSubTab(entityTypeName, label, historyToken, contentUrl [, options]) > >> > >> Example usage: > >> > >> // Tab is left-aligned by default > >> addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/'); > >> > >> // Tab is right-aligned via options object > >> addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { > >> alignRight: true > >> }); > >> > >> -- > >> > >> Regards, > >> Vojtech > >> > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From Christopher.Morrissey at netapp.com Fri Apr 5 14:11:56 2013 From: Christopher.Morrissey at netapp.com (Morrissey, Christopher) Date: Fri, 5 Apr 2013 14:11:56 +0000 Subject: [Engine-devel] UI Plugin API improvements References: <1401998609.20784520.1364483303436.JavaMail.root@redhat.com> <678163471.20791553.1364484299073.JavaMail.root@redhat.com> Message-ID: Just to reply to my own question, I've done some further investigation and it appears that the session wasn't timing out. It looks like the request from the heartbeat itself was causing the session to be invalidated and a new session to be created. When I modified the code to stop the heartbeat I was able to use the session without problem. Looking at the requests from the browser, it appears that Jboss is creating a new session with each request. I'm guessing this is a side effect of a combination of the basic authentication information in the header and the server essentially re-authenticating on each request and generating a new session ID to prevent session fixation security issues. Has anyone else used the REST session ID that is provided through the plugin API? Have you run into this issue? I think the overall issue is exacerbated by the fact that we are making calls outside of the context of the client from our server and don't have the basic authentication header information. Because the client has this, all requests are re-athenticated whether the REST session ID is valid or not. My calls are getting blocked. Any ideas on how to fix this? A change in the Jboss settings maybe? -Chris > -----Original Message----- > From: Morrissey, Christopher > Sent: Tuesday, April 02, 2013 7:18 PM > To: 'Vojtech Szocs'; engine-devel > Cc: Spenser Shumaker; Ren? Koch > Subject: RE: [Engine-devel] UI Plugin API improvements > > Great job on the dialog support, Vojtech! It's working very well for me. > > I am having an issue with the REST session ID that I haven't been able to nail > down. It seems to be timing out rather quickly. Somewhere between 15 and > 30 seconds if I don't use it explicitly. I've seen the code that is scheduled to > run every minute to keep it alive, but it looks like the timeout is happening so > quickly that the heartbeat can't keep it alive. Any idea on why this would be > happening? > > -Chris > > > > -----Original Message----- > > From: engine-devel-bounces at ovirt.org [mailto:engine-devel- > > bounces at ovirt.org] On Behalf Of Vojtech Szocs > > Sent: Thursday, March 28, 2013 11:25 AM > > To: engine-devel > > Cc: Spenser Shumaker; Ren? Koch; Morrissey, Christopher > > Subject: [Engine-devel] UI Plugin API improvements > > > > Hi guys, > > > > I've just merged some UI Plugin patches that improve existing API > > functions, as well as add some new API functions. Please read on to learn > what's new. > > > > > > Modal dialog API > > ================ > > > > Function improved: showDialog > > > > New signature: > > showDialog(title, dialogToken, contentUrl, width, height [, > > options]) > > > > Example usage: > > showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', > > '800px', '600px', { > > // Default value = empty array (no buttons) > > buttons: [ > > { > > label: 'Do stuff', > > onClick: function() { > > alert('Bump!'); > > } > > } > > ], > > > > // Default value = false > > resizeEnabled: true, > > > > // Default value = true > > closeIconVisible: true, > > > > // Default value = true > > closeOnEscKey: true > > }); > > > > Notable changes: > > * modal dialogs now look & feel the same as standard WebAdmin dialogs > > * width & height are strings containing CSS units > > * the reason why buttons default to empty array is to give plugin > > authors the choice to provide custom buttons (or similar input > > elements) via dialog content (iframe), and use HTML5 > > window.postMessage to call the plugin (coming soon!) > > > > -- > > > > New function: setDialogContentUrl > > > > New signature: > > setDialogContentUrl(dialogToken, contentUrl) > > > > Example usage: > > setDialogContentUrl('my-dialog', 'http://www.example.com/') > > > > -- > > > > New function: closeDialog > > > > New signature: > > closeDialog(dialogToken) > > > > Example usage: > > closeDialog('my-dialog') > > > > > > Tab API > > ======= > > > > Functions improved: addMainTab & addSubTab > > > > New signatures: > > addMainTab(label, historyToken, contentUrl [, options]) > > addSubTab(entityTypeName, label, historyToken, contentUrl [, > > options]) > > > > Example usage: > > > > // Tab is left-aligned by default > > addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/'); > > > > // Tab is right-aligned via options object > > addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', > { > > alignRight: true > > }); > > > > -- > > > > Regards, > > Vojtech > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel From vszocs at redhat.com Fri Apr 5 15:52:51 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 5 Apr 2013 11:52:51 -0400 (EDT) Subject: [Engine-devel] UI Plugin API improvements In-Reply-To: <51576799.8070206@redhat.com> References: <678163471.20791553.1364484299073.JavaMail.root@redhat.com> <51576799.8070206@redhat.com> Message-ID: <1005402278.1530327.1365177171863.JavaMail.root@redhat.com> Hi guys, > Are these changes already available in latest nightly repository or do I have to fetch them from git? These changes are already present in oVirt git "master" branch, so if your current work branch is based on "master", you can fetch these changes via "git fetch && git rebase origin/master". (No need to download and apply patches manually from git web interface, as these patches are merged already.) > As UI API gets more and more features I was wondering if I can get the UI plugin API version with a JavaScript call like api.getVersion(). > I think it could sometimes be useful for UI plugin development to get the version of UI API to be able to use the right API call - at the moment only oVirt 3.2 is available which supports UI plugins, but in future there will be more oVirt version and hopefully RHEV will also support UI plugins (at least as tech preview). > What do you think? You're right, this is something I've been thinking about lately as well. Since UI Plugins is oVirt feature, we can have two levels of versioning: * level-1 = oVirt version, e.g. "3.2" * level-2 = UI Plugin feature/API version, e.g. "1" [the number always goes up, i.e. new oVirt release does *not* reset this number] As Itamar mentioned below, UI plugins distributed as RPM packages can use "level-1" version to make sure that given plugin is installed only for supported oVirt version. >From UI plugin perspective, "level-2" version would be used to determine actual API compliance. For example, plugin descriptor could specify supported API version(s): [file:/usr/share/ovirt-engine/ui-plugins/showcase.json] { "name": "showcase", "apiVersion": "xxx", "url": "/webadmin/webadmin/plugin/showcase/start.html", "resourcePath": "showcase-files" } [/file] In the example above, "apiVersion" could follow interval-like syntax, similar to [http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html]: * "[2]" --> apiVersion == 2 * "[2,3]" --> 2 <= apiVersion <= 3 * "(2,)" --> 2 < apiVersion Such API compliance checking could be done early on during UI plugin discovery process, with "apiVersion" attribute being optional within the plugin descriptor. (If not specified, the plugin meta-data & configuration would be always sent alongside WebAdmin, just like today.) As suggested by Ren?, there would still be an API function to determine current UI Plugin API version. This could be used to support situations like "plugin supports version 2 and above [via apiVersion], but for version 3 it needs to do something differently". > - do you see uiplugins distributed as rpms or some other way? We should make RPM packaging a good habit (best practice?) documented on oVirt wiki, but IMHO oVirt version ("level-1") is not enough, we should also track feature/API version ("level-2") separately. Example: * oVirt version 3.2 --> feature/API version 1 * oVirt version 3.3 --> feature/API version 2 (For RHEV, where backports are important, we could have multiple feature/API versions within a single RHEV version.) > - do you see uiplugin codebase trying to accomodate multiple versions, > or branch/version similar to supported engine, and one needs latest > engine for latest uiplugin, etc. IIUC this can be covered with combination of "apiVersion" + runtime API like api.getVersion(). So guys, what do you think? Regards, Vojtech ----- Original Message ----- From: "Itamar Heim" To: "Ren? Koch" Cc: "Vojtech Szocs" , "engine-devel" Sent: Saturday, March 30, 2013 11:30:49 PM Subject: Re: [Engine-devel] UI Plugin API improvements On 03/30/2013 03:12 PM, Ren? Koch wrote: > Hi Vojtech, > > Thanks a lot for the information. > Are these changes already available in latest nightly repository or do I have to fetch them from git? > > As UI API gets more and more features I was wondering if I can get the UI plugin API version with a JavaScript call like api.getVersion(). > I think it could sometimes be useful for UI plugin development to get the version of UI API to be able to use the right API call - at the moment only oVirt 3.2 is available which supports UI plugins, but in future there will be more oVirt version and hopefully RHEV will also support UI plugins (at least as tech preview). > What do you think? interesting point. maybe less of an issue if the ui plugin is distributed in rpm form, and can validate minimal version. but if a single codebase for the uiplugin is to support multiple versions for deployment, it may want to make some features available only if engine version is X or >X. so just wondering: - do you see uiplugins distributed as rpms or some other way? - do you see uiplugin codebase trying to accomodate multiple versions, or branch/version similar to supported engine, and one needs latest engine for latest uiplugin, etc. Thanks, Itamar > > > Thanks, > Ren? > > > > -----Original message----- >> From:Vojtech Szocs >> Sent: Thursday 28th March 2013 16:25 >> To: engine-devel >> Cc: Keith Robertson ; Spenser Shumaker ; Christopher Morrissey ; Ren? Koch >> Subject: UI Plugin API improvements >> >> Hi guys, >> >> I've just merged some UI Plugin patches that improve existing API functions, as well as add some new API functions. Please read on to learn what's new. >> >> >> Modal dialog API >> ================ >> >> Function improved: showDialog >> >> New signature: >> showDialog(title, dialogToken, contentUrl, width, height [, options]) >> >> Example usage: >> showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', '600px', { >> // Default value = empty array (no buttons) >> buttons: [ >> { >> label: 'Do stuff', >> onClick: function() { >> alert('Bump!'); >> } >> } >> ], >> >> // Default value = false >> resizeEnabled: true, >> >> // Default value = true >> closeIconVisible: true, >> >> // Default value = true >> closeOnEscKey: true >> }); >> >> Notable changes: >> * modal dialogs now look & feel the same as standard WebAdmin dialogs >> * width & height are strings containing CSS units >> * the reason why buttons default to empty array is to give plugin authors the choice to provide custom buttons (or similar input elements) via dialog content (iframe), and use HTML5 window.postMessage to call the plugin (coming soon!) >> >> -- >> >> New function: setDialogContentUrl >> >> New signature: >> setDialogContentUrl(dialogToken, contentUrl) >> >> Example usage: >> setDialogContentUrl('my-dialog', 'http://www.example.com/') >> >> -- >> >> New function: closeDialog >> >> New signature: >> closeDialog(dialogToken) >> >> Example usage: >> closeDialog('my-dialog') >> >> >> Tab API >> ======= >> >> Functions improved: addMainTab & addSubTab >> >> New signatures: >> addMainTab(label, historyToken, contentUrl [, options]) >> addSubTab(entityTypeName, label, historyToken, contentUrl [, options]) >> >> Example usage: >> >> // Tab is left-aligned by default >> addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/'); >> >> // Tab is right-aligned via options object >> addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { >> alignRight: true >> }); >> >> -- >> >> Regards, >> Vojtech >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From vszocs at redhat.com Fri Apr 5 20:49:48 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 5 Apr 2013 16:49:48 -0400 (EDT) Subject: [Engine-devel] UI Plugin API improvements In-Reply-To: References: <1401998609.20784520.1364483303436.JavaMail.root@redhat.com> <678163471.20791553.1364484299073.JavaMail.root@redhat.com> Message-ID: <28045762.1752532.1365194988673.JavaMail.root@redhat.com> Hi Chris, with patch [1] merged recently, default REST API session timeout is explicitly set to 180 minutes. First, please check in: * $OVIRT_HOME/backend/manager/modules/restapi/webapp/src/main/webapp/WEB-INF/web.xml * $JBOSS_HOME/standalone/deployments/engine.ear/restapi.war/WEB-INF/web.xml (Both should contain set to 180.) When making REST API request, make sure not to accidentally close the session: * set "JSESSIONID" cookie for "/api" path * set "Prefer:persistent-auth" header --> without this, REST API session will perform logout after processing request If you still experience timeouts: * make REST API request that includes "Session-TTL:30" --> enforce timeout 30 minutes Let me know how it goes. [1] http://gerrit.ovirt.org/#/c/13044/ Regards, Vojtech ----- Original Message ----- From: "Christopher Morrissey" To: "Vojtech Szocs" , "engine-devel" Cc: "Spenser Shumaker" , "Ren? Koch" Sent: Wednesday, April 3, 2013 1:17:31 AM Subject: RE: [Engine-devel] UI Plugin API improvements Great job on the dialog support, Vojtech! It's working very well for me. I am having an issue with the REST session ID that I haven't been able to nail down. It seems to be timing out rather quickly. Somewhere between 15 and 30 seconds if I don't use it explicitly. I've seen the code that is scheduled to run every minute to keep it alive, but it looks like the timeout is happening so quickly that the heartbeat can't keep it alive. Any idea on why this would be happening? -Chris > -----Original Message----- > From: engine-devel-bounces at ovirt.org [mailto:engine-devel- > bounces at ovirt.org] On Behalf Of Vojtech Szocs > Sent: Thursday, March 28, 2013 11:25 AM > To: engine-devel > Cc: Spenser Shumaker; Ren? Koch; Morrissey, Christopher > Subject: [Engine-devel] UI Plugin API improvements > > Hi guys, > > I've just merged some UI Plugin patches that improve existing API functions, > as well as add some new API functions. Please read on to learn what's new. > > > Modal dialog API > ================ > > Function improved: showDialog > > New signature: > showDialog(title, dialogToken, contentUrl, width, height [, options]) > > Example usage: > showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', > '600px', { > // Default value = empty array (no buttons) > buttons: [ > { > label: 'Do stuff', > onClick: function() { > alert('Bump!'); > } > } > ], > > // Default value = false > resizeEnabled: true, > > // Default value = true > closeIconVisible: true, > > // Default value = true > closeOnEscKey: true > }); > > Notable changes: > * modal dialogs now look & feel the same as standard WebAdmin dialogs > * width & height are strings containing CSS units > * the reason why buttons default to empty array is to give plugin authors the > choice to provide custom buttons (or similar input elements) via dialog > content (iframe), and use HTML5 window.postMessage to call the plugin > (coming soon!) > > -- > > New function: setDialogContentUrl > > New signature: > setDialogContentUrl(dialogToken, contentUrl) > > Example usage: > setDialogContentUrl('my-dialog', 'http://www.example.com/') > > -- > > New function: closeDialog > > New signature: > closeDialog(dialogToken) > > Example usage: > closeDialog('my-dialog') > > > Tab API > ======= > > Functions improved: addMainTab & addSubTab > > New signatures: > addMainTab(label, historyToken, contentUrl [, options]) > addSubTab(entityTypeName, label, historyToken, contentUrl [, options]) > > Example usage: > > // Tab is left-aligned by default > addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/'); > > // Tab is right-aligned via options object > addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { > alignRight: true > }); > > -- > > Regards, > Vojtech > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From vszocs at redhat.com Fri Apr 5 22:08:04 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 5 Apr 2013 18:08:04 -0400 (EDT) Subject: [Engine-devel] UI Plugin API improvements In-Reply-To: References: <1401998609.20784520.1364483303436.JavaMail.root@redhat.com> <678163471.20791553.1364484299073.JavaMail.root@redhat.com> Message-ID: <309053730.9822.1365199684842.JavaMail.root@redhat.com> Thanks Chris, this is very useful information! I'm aware of the issue with heartbeat request performing re-login on server [1], the issue you encountered confirms that the root cause is the way how heartbeat requests are made from WebAdmin client (browser). I suspect this has to do something with cookies, i.e. JSESSIONID cookie for /api path used to transmit REST API session ID. I need to check that the browser eventually sends this cookie alongside Prefer:persistent-auth header within the heartbeat request. Handling cookies is always problematic in JavaScript, as WebAdmin code (i.e. /webadmin) cannot get/set cookies for different paths (i.e. /api) and therefore must rely on browser-specific cookie handling for all outgoing requests. This is quite important issue, I'll look into this next week. Again, many thanks for the feedback. [1] https://bugzilla.redhat.com/906046 Thanks, Vojtech ----- Original Message ----- From: "Christopher Morrissey" To: "Vojtech Szocs" , "engine-devel" Cc: "Spenser Shumaker" , "Ren? Koch" Sent: Friday, April 5, 2013 4:11:56 PM Subject: RE: [Engine-devel] UI Plugin API improvements Just to reply to my own question, I've done some further investigation and it appears that the session wasn't timing out. It looks like the request from the heartbeat itself was causing the session to be invalidated and a new session to be created. When I modified the code to stop the heartbeat I was able to use the session without problem. Looking at the requests from the browser, it appears that Jboss is creating a new session with each request. I'm guessing this is a side effect of a combination of the basic authentication information in the header and the server essentially re-authenticating on each request and generating a new session ID to prevent session fixation security issues. Has anyone else used the REST session ID that is provided through the plugin API? Have you run into this issue? I think the overall issue is exacerbated by the fact that we are making calls outside of the context of the client from our server and don't have the basic authentication header information. Because the client has this, all requests are re-athenticated whether the REST session ID is valid or not. My calls are getting blocked. Any ideas on how to fix this? A change in the Jboss settings maybe? -Chris > -----Original Message----- > From: Morrissey, Christopher > Sent: Tuesday, April 02, 2013 7:18 PM > To: 'Vojtech Szocs'; engine-devel > Cc: Spenser Shumaker; Ren? Koch > Subject: RE: [Engine-devel] UI Plugin API improvements > > Great job on the dialog support, Vojtech! It's working very well for me. > > I am having an issue with the REST session ID that I haven't been able to nail > down. It seems to be timing out rather quickly. Somewhere between 15 and > 30 seconds if I don't use it explicitly. I've seen the code that is scheduled to > run every minute to keep it alive, but it looks like the timeout is happening so > quickly that the heartbeat can't keep it alive. Any idea on why this would be > happening? > > -Chris > > > > -----Original Message----- > > From: engine-devel-bounces at ovirt.org [mailto:engine-devel- > > bounces at ovirt.org] On Behalf Of Vojtech Szocs > > Sent: Thursday, March 28, 2013 11:25 AM > > To: engine-devel > > Cc: Spenser Shumaker; Ren? Koch; Morrissey, Christopher > > Subject: [Engine-devel] UI Plugin API improvements > > > > Hi guys, > > > > I've just merged some UI Plugin patches that improve existing API > > functions, as well as add some new API functions. Please read on to learn > what's new. > > > > > > Modal dialog API > > ================ > > > > Function improved: showDialog > > > > New signature: > > showDialog(title, dialogToken, contentUrl, width, height [, > > options]) > > > > Example usage: > > showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', > > '800px', '600px', { > > // Default value = empty array (no buttons) > > buttons: [ > > { > > label: 'Do stuff', > > onClick: function() { > > alert('Bump!'); > > } > > } > > ], > > > > // Default value = false > > resizeEnabled: true, > > > > // Default value = true > > closeIconVisible: true, > > > > // Default value = true > > closeOnEscKey: true > > }); > > > > Notable changes: > > * modal dialogs now look & feel the same as standard WebAdmin dialogs > > * width & height are strings containing CSS units > > * the reason why buttons default to empty array is to give plugin > > authors the choice to provide custom buttons (or similar input > > elements) via dialog content (iframe), and use HTML5 > > window.postMessage to call the plugin (coming soon!) > > > > -- > > > > New function: setDialogContentUrl > > > > New signature: > > setDialogContentUrl(dialogToken, contentUrl) > > > > Example usage: > > setDialogContentUrl('my-dialog', 'http://www.example.com/') > > > > -- > > > > New function: closeDialog > > > > New signature: > > closeDialog(dialogToken) > > > > Example usage: > > closeDialog('my-dialog') > > > > > > Tab API > > ======= > > > > Functions improved: addMainTab & addSubTab > > > > New signatures: > > addMainTab(label, historyToken, contentUrl [, options]) > > addSubTab(entityTypeName, label, historyToken, contentUrl [, > > options]) > > > > Example usage: > > > > // Tab is left-aligned by default > > addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/'); > > > > // Tab is right-aligned via options object > > addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', > { > > alignRight: true > > }); > > > > -- > > > > Regards, > > Vojtech > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel From shuming at linux.vnet.ibm.com Mon Apr 8 08:59:16 2013 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Mon, 08 Apr 2013 16:59:16 +0800 Subject: [Engine-devel] How to map the oVirt engine version to VDSM version by git tags? Message-ID: <516286E4.4090507@linux.vnet.ibm.com> Hi, I am looking for a way to map the oVirt version to VDSM version and engine version by git tags. I can run "git tag -l" under engine git workspace and vdsm git workspace. Here are the output from these two "git tag -l" command. Under oVirt engine workspace: -bash-4.1$ git tag -l ovirt-engine-3.0.0_0001 ovirt-engine-3.1.0 ovirt-engine-3.2.0 ovirt-engine-3.2.1 Under vdsm workspace: -bash-4.1$ git tag -l v4.10.0 v4.10.1 v4.10.2 v4.10.3 v4.9.0 v4.9.1 v4.9.2 v4.9.3 v4.9.3.1 v4.9.3.2 v4.9.3.3 v4.9.4 v4.9.5 v4.9.6 I can checkout the oVirt 3.2.1 snapshot in engine workspace by "git checkout ovirt-engine-3.2.1". But how can I get the VDSM snapshot by the tags in VDSM workspace? How can I know which change-set is for oVirt 3.2.1 in VDSM workspace? -- --- ?? Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming at cn.ibm.com or shuming at linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC From wlbleaboy at 126.com Mon Apr 8 10:09:03 2013 From: wlbleaboy at 126.com (leaboy@126) Date: Mon, 8 Apr 2013 18:09:03 +0800 Subject: [Engine-devel] about ca-file Message-ID: <001001ce3441$19bb58b0$4d320a10$@com> Question 1: Hi,all: I'm in troubling with ca-file, who can tell me which the direction assigned to CA_FILE On the webpage http://www.ovirt.org/How_to_Connect_to_SPICE_Console_Without_Portal saided from the web: wget -O ${CA_FILE} http://${OVIRT}/ca.crt When I use overt-shell, I get ca.pem like this : [leaboy at Leaboy ovirt_ca]$ pwd /home/leaboy/ovirt_ca [leaboy at Leaboy ovirt_ca]$ wget -o ca-cert.pem http://192.168.1.181/ca.pem [leaboy at Leaboy ovirt_ca]$ ls ca-cert.pem [leaboy at Leaboy ovirt_ca]$ And then, I launched overt-shell and connect to overt-engine like this: ++++++++++++++++++++++++++++++++++++++++++ Welcome to oVirt shell ++++++++++++++++++++++++++++++++++++++++++ [oVirt shell (disconnected)]# connect --url https://192.168.1.181 --user admin at internal --password 111111 --ca-file /home/leaboy/ovirt_ca/ca_cear.pem error: [ERROR]::oVirt API connection failure, [Errno 185090050] _ssl.c:340: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib [oVirt shell (disconnected)]# Questioin 2: When I connect the vm use spicec , get a error message like this: leaboy at leaboy:~/.spicec$ spicec -h 192.168.1.219 -p 5900 -s 5901 Error: SSL_CTX_load_verify_locations failed CA_file=/home/leaboy/.spicec/spice_truststore.pem Warning: SSL Error: leaboy at leaboy:~/.spicec$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alonbl at redhat.com Mon Apr 8 11:01:19 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 8 Apr 2013 07:01:19 -0400 (EDT) Subject: [Engine-devel] about ca-file In-Reply-To: <001001ce3441$19bb58b0$4d320a10$@com> References: <001001ce3441$19bb58b0$4d320a10$@com> Message-ID: <2109668963.244809.1365418879341.JavaMail.root@redhat.com> $ wget -o ca-cert.pem http://192.168.1.181/ca.crt ----- Original Message ----- > From: "leaboy at 126" > To: engine-devel at ovirt.org > Sent: Monday, April 8, 2013 1:09:03 PM > Subject: [Engine-devel] about ca-file > > > > Question 1: > > Hi,all: > > I?m in troubling with ca-file, who can tell me which the direction assigned > to CA_FILE > > On the webpage > http://www.ovirt.org/How_to_Connect_to_SPICE_Console_Without_Portal > > saided from the web: wget -O ${CA_FILE} http://${OVIRT}/ca.crt > > When I use overt-shell, I get ca.pem like this : > > > > [leaboy at Leaboy ovirt_ca]$ pwd > > /home/leaboy/ovirt_ca > > [leaboy at Leaboy ovirt_ca]$ wget -o ca-cert.pem http://192.168.1.181/ca.pem > > [leaboy at Leaboy ovirt_ca]$ ls > > ca-cert.pem > > [leaboy at Leaboy ovirt_ca]$ > > > > And then, I launched overt-shell and connect to overt-engine like this: > > > > ++++++++++++++++++++++++++++++++++++++++++ > > > > Welcome to oVirt shell > > > > ++++++++++++++++++++++++++++++++++++++++++ > > > > > > [oVirt shell (disconnected)]# connect --url https://192.168.1.181 --user > admin at internal --password 111111 --ca-file /home/leaboy/ovirt_ca/ca_cear.pem > > > > > > error: [ERROR]::oVirt API connection failure, [Errno 185090050] _ssl.c:340: > error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib > > > > > > [oVirt shell (disconnected)]# > > > > Questioin 2: > > When I connect the vm use spicec , get a error message like this: > > leaboy at leaboy:~/.spicec$ spicec -h 192.168.1.219 -p 5900 -s 5901 > > Error: SSL_CTX_load_verify_locations failed > CA_file=/home/leaboy/.spicec/spice_truststore.pem > > Warning: SSL Error: > > leaboy at leaboy:~/.spicec$ > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From alonbl at redhat.com Mon Apr 8 12:07:26 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 8 Apr 2013 08:07:26 -0400 (EDT) Subject: [Engine-devel] =?utf-8?b?562U5aSNOiAgYWJvdXQgY2EtZmlsZQ==?= In-Reply-To: <001501ce344f$e7c82f40$b7588dc0$@com> References: <001001ce3441$19bb58b0$4d320a10$@com> <2109668963.244809.1365418879341.JavaMail.root@redhat.com> <001501ce344f$e7c82f40$b7588dc0$@com> Message-ID: <582890255.258465.1365422846670.JavaMail.root@redhat.com> Please reply to list... You should put ca.crt at /home/leaboy/.spicec/spice_truststore.pem or specify --ca-file ca.crt at spicec command-line. Alon ----- Original Message ----- > From: "leaboy at 126" > To: "Alon Bar-Lev" > Sent: Monday, April 8, 2013 2:55:00 PM > Subject: ??: [Engine-devel] about ca-file > > Thinks! Question 1 is resolved. > But, when I connected, I must assigned the --ca-file > /home/leaboy/overt_ca/ca.crt. > How can I connect just use --url --user --password without assigned > --ca-file, I mean > which directory I put the ca.crt > > in Question 2, when I connect vm use spicec directly , how can spicec to find > the ca.crt > > Leaboy Beijing > Thinks to abarlev > > -----????----- > ???: abarlev at redhat.com [mailto:abarlev at redhat.com] ?? Alon Bar-Lev > ????: 2013?4?8? 19:01 > ???: leaboy at 126 > ??: engine-devel at ovirt.org > ??: Re: [Engine-devel] about ca-file > > > $ wget -o ca-cert.pem http://192.168.1.181/ca.crt > > ----- Original Message ----- > > From: "leaboy at 126" > > To: engine-devel at ovirt.org > > Sent: Monday, April 8, 2013 1:09:03 PM > > Subject: [Engine-devel] about ca-file > > > > > > > > Question 1: > > > > Hi,all: > > > > I?m in troubling with ca-file, who can tell me which the direction assigned > > to CA_FILE > > > > On the webpage > > http://www.ovirt.org/How_to_Connect_to_SPICE_Console_Without_Portal > > > > saided from the web: wget -O ${CA_FILE} http://${OVIRT}/ca.crt > > > > When I use overt-shell, I get ca.pem like this : > > > > > > > > [leaboy at Leaboy ovirt_ca]$ pwd > > > > /home/leaboy/ovirt_ca > > > > [leaboy at Leaboy ovirt_ca]$ wget -o ca-cert.pem http://192.168.1.181/ca.pem > > > > [leaboy at Leaboy ovirt_ca]$ ls > > > > ca-cert.pem > > > > [leaboy at Leaboy ovirt_ca]$ > > > > > > > > And then, I launched overt-shell and connect to overt-engine like this: > > > > > > > > ++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > Welcome to oVirt shell > > > > > > > > ++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > > > > [oVirt shell (disconnected)]# connect --url https://192.168.1.181 --user > > admin at internal --password 111111 --ca-file > > /home/leaboy/ovirt_ca/ca_cear.pem > > > > > > > > > > > > error: [ERROR]::oVirt API connection failure, [Errno 185090050] _ssl.c:340: > > error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib > > > > > > > > > > > > [oVirt shell (disconnected)]# > > > > > > > > Questioin 2: > > > > When I connect the vm use spicec , get a error message like this: > > > > leaboy at leaboy:~/.spicec$ spicec -h 192.168.1.219 -p 5900 -s 5901 > > > > Error: SSL_CTX_load_verify_locations failed > > CA_file=/home/leaboy/.spicec/spice_truststore.pem > > > > Warning: SSL Error: > > > > leaboy at leaboy:~/.spicec$ > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > From ecohen at redhat.com Mon Apr 8 15:35:47 2013 From: ecohen at redhat.com (Einav Cohen) Date: Mon, 8 Apr 2013 11:35:47 -0400 (EDT) Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? In-Reply-To: <169884175.905225.1365434858189.JavaMail.root@redhat.com> Message-ID: <1409255709.910788.1365435347766.JavaMail.root@redhat.com> Hi, When trying to compile oVirt (with tests - see [1]), my compilation seems to get stuck on RemoveSnapshotCommandTest (see [2] for test file full path, [3] for output). When eliminating this test (e.g. I removed [2] locally from my file-system), compilation (including tests) is completed successfully. Anyone else encountered this problem / any idea what the problem might be? ---- Thanks, Einav [1] performed the following on the latest upstream: mvn clean mvn install -Pgwt-user,gwt-admin,all-langs -Dgwt.userAgent=gecko1_8 [2] ../backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/RemoveSnapshotCommandTest.java [3] last lines in compilation output: ... [INFO] ------------------------------------------------------------------------ [INFO] Building Backend Logic @Service bean 3.3.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ ... Running org.ovirt.engine.core.bll.network.host.SetupNetworksHelperTest Tests run: 56, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.74 sec Running org.ovirt.engine.core.bll.network.cluster.GetAllNetworksByClusterIdQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec Running org.ovirt.engine.core.bll.network.cluster.AttachNetworkToVdsGroupCommandTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec Running org.ovirt.engine.core.bll.network.cluster.NetworkClusterValidatorTest Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec Running org.ovirt.engine.core.bll.network.cluster.GetVdsGroupsAndNetworksByNetworkIdQueryTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec Running org.ovirt.engine.core.bll.network.vm.GetVmInterfacesByVmIdQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec Running org.ovirt.engine.core.bll.network.vm.GetVmsAndNetworkInterfacesByNetworkIdQueryTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec Running org.ovirt.engine.core.bll.network.VmInterfaceManagerTest Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.321 sec Running org.ovirt.engine.core.bll.network.template.GetTemplateInterfacesByTemplateIdQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec Running org.ovirt.engine.core.bll.network.template.GetVmTemplatesAndNetworkInterfacesByNetworkIdQueryTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec Running org.ovirt.engine.core.bll.GetCommandsCompatibilityVersionsQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec Running org.ovirt.engine.core.bll.GetClustersWithPermittedActionQueryTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec Running org.ovirt.engine.core.bll.RemoveSnapshotCommandTest [no more output after this point; waited ~20 minutes in this state before hitting "Ctrl+C"] From amureini at redhat.com Tue Apr 9 06:39:41 2013 From: amureini at redhat.com (Allon Mureinik) Date: Tue, 9 Apr 2013 02:39:41 -0400 (EDT) Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? In-Reply-To: <1409255709.910788.1365435347766.JavaMail.root@redhat.com> References: <1409255709.910788.1365435347766.JavaMail.root@redhat.com> Message-ID: <678555862.996554.1365489581763.JavaMail.root@redhat.com> When running [1] on this morning's master (commit hash eca9964, merged April 8th, 20:15 IST) I didn't notice any issues (built the entire project in ~3 minutes, backend took 27 seconds), but when running this test alone in eclipse it definitely took much longer. I'm guessing it lacks some mocking, which some earlier test is doing by mistake. Since JUnit does not enforce any ordering, we may be running our tests in a slightly different order (due to different maven/java/os minor versions, etc.), which makes the problem visible on your setup but not mine. I'll do somemore digging and see if I can pinpoint it. ----- Original Message ----- > From: "Einav Cohen" > To: "engine-devel" > Sent: Monday, April 8, 2013 6:35:47 PM > Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? > > Hi, > > When trying to compile oVirt (with tests - see [1]), my compilation seems to > get stuck on > RemoveSnapshotCommandTest (see [2] for test file full path, [3] for output). > > When eliminating this test (e.g. I removed [2] locally from my file-system), > compilation > (including tests) is completed successfully. > > Anyone else encountered this problem / any idea what the problem might be? > > ---- > Thanks, > Einav > > > [1] performed the following on the latest upstream: > mvn clean > mvn install -Pgwt-user,gwt-admin,all-langs -Dgwt.userAgent=gecko1_8 > > [2] > ../backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/RemoveSnapshotCommandTest.java > > [3] last lines in compilation output: > ... > [INFO] > ------------------------------------------------------------------------ > [INFO] Building Backend Logic @Service bean 3.3.0-SNAPSHOT > [INFO] > ------------------------------------------------------------------------ > ... > > Running org.ovirt.engine.core.bll.network.host.SetupNetworksHelperTest > Tests run: 56, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.74 sec > Running > org.ovirt.engine.core.bll.network.cluster.GetAllNetworksByClusterIdQueryTest > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec > Running > org.ovirt.engine.core.bll.network.cluster.AttachNetworkToVdsGroupCommandTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec > Running org.ovirt.engine.core.bll.network.cluster.NetworkClusterValidatorTest > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec > Running > org.ovirt.engine.core.bll.network.cluster.GetVdsGroupsAndNetworksByNetworkIdQueryTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec > Running org.ovirt.engine.core.bll.network.vm.GetVmInterfacesByVmIdQueryTest > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec > Running > org.ovirt.engine.core.bll.network.vm.GetVmsAndNetworkInterfacesByNetworkIdQueryTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec > Running org.ovirt.engine.core.bll.network.VmInterfaceManagerTest > Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.321 sec > Running > org.ovirt.engine.core.bll.network.template.GetTemplateInterfacesByTemplateIdQueryTest > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec > Running > org.ovirt.engine.core.bll.network.template.GetVmTemplatesAndNetworkInterfacesByNetworkIdQueryTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec > Running org.ovirt.engine.core.bll.GetCommandsCompatibilityVersionsQueryTest > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec > Running org.ovirt.engine.core.bll.GetClustersWithPermittedActionQueryTest > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec > Running org.ovirt.engine.core.bll.RemoveSnapshotCommandTest > [no more output after this point; waited ~20 minutes in this state before > hitting "Ctrl+C"] > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From amureini at redhat.com Tue Apr 9 07:22:38 2013 From: amureini at redhat.com (Allon Mureinik) Date: Tue, 9 Apr 2013 03:22:38 -0400 (EDT) Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? In-Reply-To: <678555862.996554.1365489581763.JavaMail.root@redhat.com> References: <1409255709.910788.1365435347766.JavaMail.root@redhat.com> <678555862.996554.1365489581763.JavaMail.root@redhat.com> Message-ID: <73600709.1019869.1365492158323.JavaMail.root@redhat.com> OK, my guess is that test uses Mockito Matchers carelessly. I removed them, and on my setup I reduced the time it takes to run this test alone in eclipse from ~70 seconds to ~0.7 seconds (i.e., removed 99% of the runtime). Please check it solves the issue on your setup too. Thanks, Allon ----- Original Message ----- > From: "Allon Mureinik" > To: "Einav Cohen" > Cc: "engine-devel" > Sent: Tuesday, April 9, 2013 9:39:41 AM > Subject: Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? > > When running [1] on this morning's master (commit hash eca9964, merged April > 8th, 20:15 IST) I didn't notice any issues (built the entire project in ~3 > minutes, backend took 27 seconds), but when running this test alone in > eclipse it definitely took much longer. > > I'm guessing it lacks some mocking, which some earlier test is doing by > mistake. > Since JUnit does not enforce any ordering, we may be running our tests in a > slightly different order (due to different maven/java/os minor versions, > etc.), which makes the problem visible on your setup but not mine. > > I'll do somemore digging and see if I can pinpoint it. > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "engine-devel" > > Sent: Monday, April 8, 2013 6:35:47 PM > > Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? > > > > Hi, > > > > When trying to compile oVirt (with tests - see [1]), my compilation seems > > to > > get stuck on > > RemoveSnapshotCommandTest (see [2] for test file full path, [3] for > > output). > > > > When eliminating this test (e.g. I removed [2] locally from my > > file-system), > > compilation > > (including tests) is completed successfully. > > > > Anyone else encountered this problem / any idea what the problem might be? > > > > ---- > > Thanks, > > Einav > > > > > > [1] performed the following on the latest upstream: > > mvn clean > > mvn install -Pgwt-user,gwt-admin,all-langs -Dgwt.userAgent=gecko1_8 > > > > [2] > > ../backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/RemoveSnapshotCommandTest.java > > > > [3] last lines in compilation output: > > ... > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] Building Backend Logic @Service bean 3.3.0-SNAPSHOT > > [INFO] > > ------------------------------------------------------------------------ > > ... > > > > Running org.ovirt.engine.core.bll.network.host.SetupNetworksHelperTest > > Tests run: 56, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.74 sec > > Running > > org.ovirt.engine.core.bll.network.cluster.GetAllNetworksByClusterIdQueryTest > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec > > Running > > org.ovirt.engine.core.bll.network.cluster.AttachNetworkToVdsGroupCommandTest > > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec > > Running > > org.ovirt.engine.core.bll.network.cluster.NetworkClusterValidatorTest > > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec > > Running > > org.ovirt.engine.core.bll.network.cluster.GetVdsGroupsAndNetworksByNetworkIdQueryTest > > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec > > Running org.ovirt.engine.core.bll.network.vm.GetVmInterfacesByVmIdQueryTest > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec > > Running > > org.ovirt.engine.core.bll.network.vm.GetVmsAndNetworkInterfacesByNetworkIdQueryTest > > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec > > Running org.ovirt.engine.core.bll.network.VmInterfaceManagerTest > > Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.321 sec > > Running > > org.ovirt.engine.core.bll.network.template.GetTemplateInterfacesByTemplateIdQueryTest > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec > > Running > > org.ovirt.engine.core.bll.network.template.GetVmTemplatesAndNetworkInterfacesByNetworkIdQueryTest > > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec > > Running org.ovirt.engine.core.bll.GetCommandsCompatibilityVersionsQueryTest > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec > > Running org.ovirt.engine.core.bll.GetClustersWithPermittedActionQueryTest > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec > > Running org.ovirt.engine.core.bll.RemoveSnapshotCommandTest > > [no more output after this point; waited ~20 minutes in this state before > > hitting "Ctrl+C"] > > _______________________________________________ > > 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 amureini at redhat.com Tue Apr 9 07:24:02 2013 From: amureini at redhat.com (Allon Mureinik) Date: Tue, 9 Apr 2013 03:24:02 -0400 (EDT) Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? In-Reply-To: <73600709.1019869.1365492158323.JavaMail.root@redhat.com> References: <1409255709.910788.1365435347766.JavaMail.root@redhat.com> <678555862.996554.1365489581763.JavaMail.root@redhat.com> <73600709.1019869.1365492158323.JavaMail.root@redhat.com> Message-ID: <1076269299.1020635.1365492242560.JavaMail.root@redhat.com> The last message would have been much more useful if I'd actually attached the link to my patch: http://gerrit.ovirt.org/#/c/13733/ Note that it is /not/ merge yet - review would be appreciated. ----- Original Message ----- > From: "Allon Mureinik" > To: "Einav Cohen" > Cc: "engine-devel" > Sent: Tuesday, April 9, 2013 10:22:38 AM > Subject: Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? > > OK, my guess is that test uses Mockito Matchers carelessly. > > I removed them, and on my setup I reduced the time it takes to run this test > alone in eclipse from ~70 seconds to ~0.7 seconds (i.e., removed 99% of the > runtime). > > Please check it solves the issue on your setup too. > > > Thanks, > Allon > > ----- Original Message ----- > > From: "Allon Mureinik" > > To: "Einav Cohen" > > Cc: "engine-devel" > > Sent: Tuesday, April 9, 2013 9:39:41 AM > > Subject: Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? > > > > When running [1] on this morning's master (commit hash eca9964, merged > > April > > 8th, 20:15 IST) I didn't notice any issues (built the entire project in ~3 > > minutes, backend took 27 seconds), but when running this test alone in > > eclipse it definitely took much longer. > > > > I'm guessing it lacks some mocking, which some earlier test is doing by > > mistake. > > Since JUnit does not enforce any ordering, we may be running our tests in a > > slightly different order (due to different maven/java/os minor versions, > > etc.), which makes the problem visible on your setup but not mine. > > > > I'll do somemore digging and see if I can pinpoint it. > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "engine-devel" > > > Sent: Monday, April 8, 2013 6:35:47 PM > > > Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? > > > > > > Hi, > > > > > > When trying to compile oVirt (with tests - see [1]), my compilation seems > > > to > > > get stuck on > > > RemoveSnapshotCommandTest (see [2] for test file full path, [3] for > > > output). > > > > > > When eliminating this test (e.g. I removed [2] locally from my > > > file-system), > > > compilation > > > (including tests) is completed successfully. > > > > > > Anyone else encountered this problem / any idea what the problem might > > > be? > > > > > > ---- > > > Thanks, > > > Einav > > > > > > > > > [1] performed the following on the latest upstream: > > > mvn clean > > > mvn install -Pgwt-user,gwt-admin,all-langs -Dgwt.userAgent=gecko1_8 > > > > > > [2] > > > ../backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/RemoveSnapshotCommandTest.java > > > > > > [3] last lines in compilation output: > > > ... > > > [INFO] > > > ------------------------------------------------------------------------ > > > [INFO] Building Backend Logic @Service bean 3.3.0-SNAPSHOT > > > [INFO] > > > ------------------------------------------------------------------------ > > > ... > > > > > > Running org.ovirt.engine.core.bll.network.host.SetupNetworksHelperTest > > > Tests run: 56, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.74 sec > > > Running > > > org.ovirt.engine.core.bll.network.cluster.GetAllNetworksByClusterIdQueryTest > > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec > > > Running > > > org.ovirt.engine.core.bll.network.cluster.AttachNetworkToVdsGroupCommandTest > > > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec > > > Running > > > org.ovirt.engine.core.bll.network.cluster.NetworkClusterValidatorTest > > > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec > > > Running > > > org.ovirt.engine.core.bll.network.cluster.GetVdsGroupsAndNetworksByNetworkIdQueryTest > > > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec > > > Running > > > org.ovirt.engine.core.bll.network.vm.GetVmInterfacesByVmIdQueryTest > > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec > > > Running > > > org.ovirt.engine.core.bll.network.vm.GetVmsAndNetworkInterfacesByNetworkIdQueryTest > > > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec > > > Running org.ovirt.engine.core.bll.network.VmInterfaceManagerTest > > > Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.321 > > > sec > > > Running > > > org.ovirt.engine.core.bll.network.template.GetTemplateInterfacesByTemplateIdQueryTest > > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec > > > Running > > > org.ovirt.engine.core.bll.network.template.GetVmTemplatesAndNetworkInterfacesByNetworkIdQueryTest > > > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec > > > Running > > > org.ovirt.engine.core.bll.GetCommandsCompatibilityVersionsQueryTest > > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec > > > Running org.ovirt.engine.core.bll.GetClustersWithPermittedActionQueryTest > > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec > > > Running org.ovirt.engine.core.bll.RemoveSnapshotCommandTest > > > [no more output after this point; waited ~20 minutes in this state before > > > hitting "Ctrl+C"] > > > _______________________________________________ > > > 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 wanglibo at tongfangcloud.com Mon Apr 8 10:00:01 2013 From: wanglibo at tongfangcloud.com (wanglibo) Date: Mon, 8 Apr 2013 18:00:01 +0800 Subject: [Engine-devel] about ca-file Message-ID: <000101ce343f$db1518e0$913f4aa0$@com> Hi,all: I'm in troubling with ca-file, who can tell me which the direction assigned to CA_FILE On the webpage http://www.ovirt.org/How_to_Connect_to_SPICE_Console_Without_Portal saided from the web: wget -O ${CA_FILE} http://${OVIRT}/ca.crt When I use overt-shell, I get ca.pem like this : [leaboy at Leaboy ovirt_ca]$ pwd /home/leaboy/ovirt_ca [leaboy at Leaboy ovirt_ca]$ wget -o ca-cert.pem http://192.168.1.181/ca.pem [leaboy at Leaboy ovirt_ca]$ ls ca-cert.pem [leaboy at Leaboy ovirt_ca]$ And then, I launched overt-shell and connect to overt-engine like this: ++++++++++++++++++++++++++++++++++++++++++ Welcome to oVirt shell ++++++++++++++++++++++++++++++++++++++++++ [oVirt shell (disconnected)]# connect --url https://192.168.1.181 --user admin at internal --password 111111 --ca-file /home/leaboy/ovirt_ca/ca_cear.pem error: [ERROR]::oVirt API connection failure, [Errno 185090050] _ssl.c:340: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib [oVirt shell (disconnected)]# -------------- next part -------------- An HTML attachment was scrubbed... URL: From wanglibo at tongfangcloud.com Mon Apr 8 10:02:37 2013 From: wanglibo at tongfangcloud.com (wanglibo) Date: Mon, 8 Apr 2013 18:02:37 +0800 Subject: [Engine-devel] about ca-file Message-ID: <000b01ce3440$36159b20$a240d160$@com> Hi,all: I'm in troubling with ca-file, who can tell me which the direction assigned to CA_FILE On the webpage http://www.ovirt.org/How_to_Connect_to_SPICE_Console_Without_Portal saided from the web: wget -O ${CA_FILE} http://${OVIRT}/ca.crt When I use overt-shell, I get ca.pem like this : [leaboy at Leaboy ovirt_ca]$ pwd /home/leaboy/ovirt_ca [leaboy at Leaboy ovirt_ca]$ wget -o ca-cert.pem http://192.168.1.181/ca.pem [leaboy at Leaboy ovirt_ca]$ ls ca-cert.pem [leaboy at Leaboy ovirt_ca]$ And then, I launched overt-shell and connect to overt-engine like this: ++++++++++++++++++++++++++++++++++++++++++ Welcome to oVirt shell ++++++++++++++++++++++++++++++++++++++++++ [oVirt shell (disconnected)]# connect --url https://192.168.1.181 --user admin at internal --password 111111 --ca-file /home/leaboy/ovirt_ca/ca_cear.pem error: [ERROR]::oVirt API connection failure, [Errno 185090050] _ssl.c:340: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib [oVirt shell (disconnected)]# -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahadas at redhat.com Tue Apr 9 08:01:36 2013 From: ahadas at redhat.com (Arik Hadas) Date: Tue, 9 Apr 2013 04:01:36 -0400 (EDT) Subject: [Engine-devel] Snapshots with RAM feature In-Reply-To: <2072928864.762753.1365492262298.JavaMail.root@redhat.com> Message-ID: <319368954.768893.1365494496958.JavaMail.root@redhat.com> Hi All, The proposed feature will make it possible to run a VM which was reverted to live snapshot or created from live snapshot with the same memory state as it was at the moment the live snapshot was taken. http://www.ovirt.org/Features/RAM_Snapshots All feedback is welcome! Regards, Arik From scohen at redhat.com Tue Apr 9 08:29:36 2013 From: scohen at redhat.com (Sean Cohen) Date: Tue, 9 Apr 2013 04:29:36 -0400 (EDT) Subject: [Engine-devel] [vdsm] Snapshots with RAM feature In-Reply-To: <319368954.768893.1365494496958.JavaMail.root@redhat.com> References: <319368954.768893.1365494496958.JavaMail.root@redhat.com> Message-ID: <24146623.346.1365496174436.JavaMail.scohen@scohen.csb> ----- Original Message ----- > From: "Arik Hadas" > To: engine-devel at ovirt.org, vdsm-devel at lists.fedorahosted.org > Sent: Tuesday, April 9, 2013 11:01:36 AM > Subject: [vdsm] Snapshots with RAM feature > > Hi All, > > The proposed feature will make it possible to run a VM which was > reverted to live snapshot > or created from live snapshot with the same memory state as it was at > the moment the live > snapshot was taken. > > http://www.ovirt.org/Features/RAM_Snapshots > > All feedback is welcome! Thanks Arik, I beleive we will be able to levarage it with the new Backup API that we are planning for 3.3 (http://www.ovirt.org/Features/Backup-Restore_API_Integration) Sean > > Regards, > Arik > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > From amureini at redhat.com Tue Apr 9 08:46:58 2013 From: amureini at redhat.com (Allon Mureinik) Date: Tue, 9 Apr 2013 04:46:58 -0400 (EDT) Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? In-Reply-To: <1076269299.1020635.1365492242560.JavaMail.root@redhat.com> References: <1409255709.910788.1365435347766.JavaMail.root@redhat.com> <678555862.996554.1365489581763.JavaMail.root@redhat.com> <73600709.1019869.1365492158323.JavaMail.root@redhat.com> <1076269299.1020635.1365492242560.JavaMail.root@redhat.com> Message-ID: <1925308784.1473910.1365497218477.JavaMail.root@redhat.com> OK, patch is merged (thanks kind reviewers!) Einav - please check that this also solves the issue in /your/ setup and let us all know. Thanks, Allon ----- Original Message ----- > From: "Allon Mureinik" > To: "Einav Cohen" > Cc: "engine-devel" > Sent: Tuesday, April 9, 2013 10:24:02 AM > Subject: Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? > > The last message would have been much more useful if I'd actually attached > the link to my patch: > http://gerrit.ovirt.org/#/c/13733/ > > Note that it is /not/ merge yet - review would be appreciated. > ----- Original Message ----- > > From: "Allon Mureinik" > > To: "Einav Cohen" > > Cc: "engine-devel" > > Sent: Tuesday, April 9, 2013 10:22:38 AM > > Subject: Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? > > > > OK, my guess is that test uses Mockito Matchers carelessly. > > > > I removed them, and on my setup I reduced the time it takes to run this > > test > > alone in eclipse from ~70 seconds to ~0.7 seconds (i.e., removed 99% of the > > runtime). > > > > Please check it solves the issue on your setup too. > > > > > > Thanks, > > Allon > > > > ----- Original Message ----- > > > From: "Allon Mureinik" > > > To: "Einav Cohen" > > > Cc: "engine-devel" > > > Sent: Tuesday, April 9, 2013 9:39:41 AM > > > Subject: Re: [Engine-devel] compilation stuck on > > > RemoveSnapshotCommandTest? > > > > > > When running [1] on this morning's master (commit hash eca9964, merged > > > April > > > 8th, 20:15 IST) I didn't notice any issues (built the entire project in > > > ~3 > > > minutes, backend took 27 seconds), but when running this test alone in > > > eclipse it definitely took much longer. > > > > > > I'm guessing it lacks some mocking, which some earlier test is doing by > > > mistake. > > > Since JUnit does not enforce any ordering, we may be running our tests in > > > a > > > slightly different order (due to different maven/java/os minor versions, > > > etc.), which makes the problem visible on your setup but not mine. > > > > > > I'll do somemore digging and see if I can pinpoint it. > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "engine-devel" > > > > Sent: Monday, April 8, 2013 6:35:47 PM > > > > Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? > > > > > > > > Hi, > > > > > > > > When trying to compile oVirt (with tests - see [1]), my compilation > > > > seems > > > > to > > > > get stuck on > > > > RemoveSnapshotCommandTest (see [2] for test file full path, [3] for > > > > output). > > > > > > > > When eliminating this test (e.g. I removed [2] locally from my > > > > file-system), > > > > compilation > > > > (including tests) is completed successfully. > > > > > > > > Anyone else encountered this problem / any idea what the problem might > > > > be? > > > > > > > > ---- > > > > Thanks, > > > > Einav > > > > > > > > > > > > [1] performed the following on the latest upstream: > > > > mvn clean > > > > mvn install -Pgwt-user,gwt-admin,all-langs -Dgwt.userAgent=gecko1_8 > > > > > > > > [2] > > > > ../backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/RemoveSnapshotCommandTest.java > > > > > > > > [3] last lines in compilation output: > > > > ... > > > > [INFO] > > > > ------------------------------------------------------------------------ > > > > [INFO] Building Backend Logic @Service bean 3.3.0-SNAPSHOT > > > > [INFO] > > > > ------------------------------------------------------------------------ > > > > ... > > > > > > > > Running org.ovirt.engine.core.bll.network.host.SetupNetworksHelperTest > > > > Tests run: 56, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.74 > > > > sec > > > > Running > > > > org.ovirt.engine.core.bll.network.cluster.GetAllNetworksByClusterIdQueryTest > > > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 > > > > sec > > > > Running > > > > org.ovirt.engine.core.bll.network.cluster.AttachNetworkToVdsGroupCommandTest > > > > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 > > > > sec > > > > Running > > > > org.ovirt.engine.core.bll.network.cluster.NetworkClusterValidatorTest > > > > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 > > > > sec > > > > Running > > > > org.ovirt.engine.core.bll.network.cluster.GetVdsGroupsAndNetworksByNetworkIdQueryTest > > > > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 > > > > sec > > > > Running > > > > org.ovirt.engine.core.bll.network.vm.GetVmInterfacesByVmIdQueryTest > > > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 > > > > sec > > > > Running > > > > org.ovirt.engine.core.bll.network.vm.GetVmsAndNetworkInterfacesByNetworkIdQueryTest > > > > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056 > > > > sec > > > > Running org.ovirt.engine.core.bll.network.VmInterfaceManagerTest > > > > Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.321 > > > > sec > > > > Running > > > > org.ovirt.engine.core.bll.network.template.GetTemplateInterfacesByTemplateIdQueryTest > > > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 > > > > sec > > > > Running > > > > org.ovirt.engine.core.bll.network.template.GetVmTemplatesAndNetworkInterfacesByNetworkIdQueryTest > > > > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 > > > > sec > > > > Running > > > > org.ovirt.engine.core.bll.GetCommandsCompatibilityVersionsQueryTest > > > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 > > > > sec > > > > Running > > > > org.ovirt.engine.core.bll.GetClustersWithPermittedActionQueryTest > > > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 > > > > sec > > > > Running org.ovirt.engine.core.bll.RemoveSnapshotCommandTest > > > > [no more output after this point; waited ~20 minutes in this state > > > > before > > > > hitting "Ctrl+C"] > > > > _______________________________________________ > > > > 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 sabose at redhat.com Tue Apr 9 10:10:58 2013 From: sabose at redhat.com (Sahina Bose) Date: Tue, 09 Apr 2013 15:40:58 +0530 Subject: [Engine-devel] ovirt-host-deploy and multible bridges Message-ID: <5163E932.8040300@redhat.com> Hi all, I'm testing the bootstrapping of host without reboot on Fedora 18. After host's bootstrap, Ifconfig output returns this: ovirtmgmt: flags=4163 mtu 1500 inet 10.70.37.219 netmask 255.255.254.0 broadcast 10.70.37.255 virbr0: flags=4099 mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 Running*glusterHostsList* vdsm verb, returns the ip address 192.168.122.1, whereas my host has been added with ip address 10.70.37.219 If I reboot the host, the virbr0 bridge is removed, and there's no issue. The vdsm verb glusterHostsList - returns ipAddress of host + output of gluster peer probe. This is needed because a periodic sync job needs to make sure that the hosts added in engine are in sync with the gluster cli (hosts could also be added/removed from gluster cli). How can we make sure glusterHostsList picks the correct ipAddress? Reading the inetinfo based on bridge has been vetoed as we are doing away with bridges. It would also work if virbr0 was updated in vds_interfaces table. Since this is not happening either - we have an issue. thanks sahina -------------- next part -------------- An HTML attachment was scrubbed... URL: From sabose at redhat.com Tue Apr 9 10:25:25 2013 From: sabose at redhat.com (Sahina Bose) Date: Tue, 09 Apr 2013 15:55:25 +0530 Subject: [Engine-devel] ovirt-host-deploy and multible bridges In-Reply-To: <5163E932.8040300@redhat.com> References: <5163E932.8040300@redhat.com> Message-ID: <5163EC95.50901@redhat.com> [Adding vdsm-devel] On 04/09/2013 03:40 PM, Sahina Bose wrote: > Hi all, > > I'm testing the bootstrapping of host without reboot on Fedora 18. After > host's bootstrap, > Ifconfig output returns this: > > ovirtmgmt: flags=4163 mtu 1500 > inet 10.70.37.219 netmask 255.255.254.0 broadcast 10.70.37.255 > > > virbr0: flags=4099 mtu 1500 > inet 192.168.122.1 netmask 255.255.255.0 broadcast > 192.168.122.255 > > > Running*glusterHostsList* vdsm verb, returns the ip address > 192.168.122.1, whereas my host has been added with ip address 10.70.37.219 > > If I reboot the host, the virbr0 bridge is removed, and there's no issue. > > The vdsm verb glusterHostsList - returns ipAddress of host + output of > gluster peer probe. This is needed because a periodic sync job needs > to make sure that the hosts added in engine are in sync with the > gluster cli (hosts could also be added/removed from gluster cli). > > How can we make sure glusterHostsList picks the correct ipAddress? > Reading the inetinfo based on bridge has been vetoed as we are doing > away with bridges. > > It would also work if virbr0 was updated in vds_interfaces table. > Since this is not happening either - we have an issue. > > thanks > sahina > > > > _______________________________________________ > 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: From djasa at redhat.com Tue Apr 9 12:08:02 2013 From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=) Date: Tue, 09 Apr 2013 14:08:02 +0200 Subject: [Engine-devel] RFC: is it possible to configure hosts in cluster to be NTP peers Message-ID: <1365509282.28990.39.camel@cihla.usersys.redhat.com> Hi, ovirt still doesn't configure NTP on host installation and relies on administrator not forgetting to set it up correctly, mainly because it is quite hard to configure it correctly automatically. There is one thing IMO that could be configured automatically and that could alleviate situation somewhat: make hosts in the cluster NTP peers so that when clocks go wrong in the cluster for any reason, the error is the same on all hosts in the cluster. The files could be stored in /etc/{ntp,chrony}/vdsm.conf for instance and referenced with includefile or include ..." in /etc/ntp.conf or /etc/chrony.conf respectively. What seems tricky though is that non-Up hosts should be excluded from peer list because there are higher chances that their clocks are not configured properly, so engine (or some host?) should trigger changes to NTP configuration pretty frequently. What do you think about these issues? I don't want to report bugs/RFEs on topic before I'll see your reply. David -- David Ja?a, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 From danken at redhat.com Tue Apr 9 12:35:35 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Tue, 9 Apr 2013 15:35:35 +0300 Subject: [Engine-devel] ovirt-host-deploy and multible bridges In-Reply-To: <5163EC95.50901@redhat.com> References: <5163E932.8040300@redhat.com> <5163EC95.50901@redhat.com> Message-ID: <20130409123535.GK26069@redhat.com> On Tue, Apr 09, 2013 at 03:55:25PM +0530, Sahina Bose wrote: > [Adding vdsm-devel] > > On 04/09/2013 03:40 PM, Sahina Bose wrote: > >Hi all, > > > >I'm testing the bootstrapping of host without reboot on Fedora 18. After > >host's bootstrap, > >Ifconfig output returns this: > > > >ovirtmgmt: flags=4163 mtu 1500 > > inet 10.70.37.219 netmask 255.255.254.0 broadcast 10.70.37.255 > > > > > >virbr0: flags=4099 mtu 1500 > > inet 192.168.122.1 netmask 255.255.255.0 broadcast > >192.168.122.255 > > > > > >Running*glusterHostsList* vdsm verb, returns the ip address > >192.168.122.1, whereas my host has been added with ip address 10.70.37.219 > > > >If I reboot the host, the virbr0 bridge is removed, and there's no issue. > > > >The vdsm verb glusterHostsList - returns ipAddress of host + > >output of gluster peer probe. This is needed because a periodic > >sync job needs to make sure that the hosts added in engine are in > >sync with the gluster cli (hosts could also be added/removed from > >gluster cli). > > > >How can we make sure glusterHostsList picks the correct ipAddress? Can you define (in plain English) what is the "correct" address? The host may have multiple valid addresses (storage, migration, display, whatnot). Only when it's clear to us, we can start expressing this in Python. > >Reading the inetinfo based on bridge has been vetoed as we are > >doing away with bridges. > > > >It would also work if virbr0 was updated in vds_interfaces table. > >Since this is not happening either - we have an issue. It might be a valid hack to drop this default virbr0 on vdsm start - not only the libvirt definition thereof, but also the running kernel device. However, as expressed above, this would not solve your problem when you have a currently-running host with multiple addresses. Dan. From amureini at redhat.com Tue Apr 9 13:02:52 2013 From: amureini at redhat.com (Allon Mureinik) Date: Tue, 9 Apr 2013 09:02:52 -0400 (EDT) Subject: [Engine-devel] Java 7, revisited again In-Reply-To: <532853312.532229.1364972794164.JavaMail.root@redhat.com> References: <1300679206.218645.1364909600566.JavaMail.root@redhat.com> <515BAEB4.4060301@redhat.com> <532853312.532229.1364972794164.JavaMail.root@redhat.com> Message-ID: <32467228.1594528.1365512572630.JavaMail.root@redhat.com> After a week of positive reviews in gerrit, and no objections voiced here, patch was merged. piped catch clauses, here we come. ----- Original Message ----- > From: "Allon Mureinik" > To: "Kanagaraj" > Cc: "engine-devel" > Sent: Wednesday, April 3, 2013 10:06:34 AM > Subject: Re: [Engine-devel] Java 7, revisited again > > Good point, thanks! > > Fixed up the patch and uploaded a new version. > > ----- Original Message ----- > > From: "Kanagaraj" > > To: "Allon Mureinik" > > Cc: "engine-devel" > > Sent: Wednesday, April 3, 2013 7:23:16 AM > > Subject: Re: [Engine-devel] Java 7, revisited again > > > > On 04/02/2013 07:03 PM, Allon Mureinik wrote: > > > Hola, > > > > > > A couple of weeks (months?) ago we discussed upgrading to Java 7.[1] > > > Generally, there was a positive vibe about moving forward with > > > technology, > > > although we noted that this should not be done for common, compat and the > > > GWT modules, > > > > searchbackend is also used by GWT, this needs to be excluded as well. > > > > Thanks, > > Kanagaraj > > > > > under the limitation of the current GWT version we're using. > > > > > > Here's an initial suggestion for this upgrade: > > > http://gerrit.ovirt.org/#/c/13519/ > > > > > > Areas handled and checked: > > > 1. compilation (including GWT compilation)[2] > > > 2. animal-sniffer validations for to makes sure that modules that aren't > > > supposed to use JDK7 features really don't[2] > > > 3. Running and making sure the UI still works :-) > > > (checkstyle issues which Laslo pointed out in the original discussion > > > were > > > already solved in a different patch merged long ago) > > > > > > > > > Sincerely, > > > Allon and Alissa > > > > > > [1] > > > http://lists.ovirt.org/pipermail/engine-devel/2012-December/003139.html > > > [2] This includes, of course, purposely introducing Java 7 syntax and JDK > > > 7 > > > features to modules that aren't supposed to have them, > > > and making sure that the build fails early, as expected, without > > > having to add the -Pgwt-admin or -Pgwt-user profiles. > > > _______________________________________________ > > > 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 Tue Apr 9 13:07:56 2013 From: sabose at redhat.com (Sahina Bose) Date: Tue, 09 Apr 2013 18:37:56 +0530 Subject: [Engine-devel] ovirt-host-deploy and multible bridges In-Reply-To: <20130409123535.GK26069@redhat.com> References: <5163E932.8040300@redhat.com> <5163EC95.50901@redhat.com> <20130409123535.GK26069@redhat.com> Message-ID: <516412AC.7060907@redhat.com> Decoding "correct address" - glusterHostsList should return any ipAddress that engine knows as being associated with host. It could be either ipAddress used while adding host (stored as hostname in vds_static) or any of the ipAddresses populated in vds_interface table (addr column) . I do not have enough knowledge about this bit of code to say what entries are made in vds_interface table. I know there's an entry for ovirtmgmt here but not sure if this gets added as part of addHost flow or not. thx sahina On 04/09/2013 06:05 PM, Dan Kenigsberg wrote: > On Tue, Apr 09, 2013 at 03:55:25PM +0530, Sahina Bose wrote: >> [Adding vdsm-devel] >> >> On 04/09/2013 03:40 PM, Sahina Bose wrote: >>> Hi all, >>> >>> I'm testing the bootstrapping of host without reboot on Fedora 18. After >>> host's bootstrap, >>> Ifconfig output returns this: >>> >>> ovirtmgmt: flags=4163 mtu 1500 >>> inet 10.70.37.219 netmask 255.255.254.0 broadcast 10.70.37.255 >>> >>> >>> virbr0: flags=4099 mtu 1500 >>> inet 192.168.122.1 netmask 255.255.255.0 broadcast >>> 192.168.122.255 >>> >>> >>> Running*glusterHostsList* vdsm verb, returns the ip address >>> 192.168.122.1, whereas my host has been added with ip address 10.70.37.219 >>> >>> If I reboot the host, the virbr0 bridge is removed, and there's no issue. >>> >>> The vdsm verb glusterHostsList - returns ipAddress of host + >>> output of gluster peer probe. This is needed because a periodic >>> sync job needs to make sure that the hosts added in engine are in >>> sync with the gluster cli (hosts could also be added/removed from >>> gluster cli). >>> >>> How can we make sure glusterHostsList picks the correct ipAddress? > Can you define (in plain English) what is the "correct" address? > The host may have multiple valid addresses (storage, migration, display, > whatnot). > > Only when it's clear to us, we can start expressing this in Python. > >>> Reading the inetinfo based on bridge has been vetoed as we are >>> doing away with bridges. >>> >>> It would also work if virbr0 was updated in vds_interfaces table. >>> Since this is not happening either - we have an issue. > It might be a valid hack to drop this default virbr0 on vdsm start - not > only the libvirt definition thereof, but also the running kernel device. > > However, as expressed above, this would not solve your problem when you > have a currently-running host with multiple addresses. > > Dan. From barumuga at redhat.com Tue Apr 9 13:58:17 2013 From: barumuga at redhat.com (Balamurugan Arumugam) Date: Tue, 09 Apr 2013 19:28:17 +0530 Subject: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges In-Reply-To: <516412AC.7060907@redhat.com> References: <5163E932.8040300@redhat.com> <5163EC95.50901@redhat.com> <20130409123535.GK26069@redhat.com> <516412AC.7060907@redhat.com> Message-ID: <51641E79.5030506@redhat.com> On 04/09/2013 06:37 PM, Sahina Bose wrote: > Decoding "correct address" - glusterHostsList should return any > ipAddress that engine knows as being associated with host. > It could be either ipAddress used while adding host (stored as hostname > in vds_static) or any of the ipAddresses populated in vds_interface > table (addr column) . > I do not have enough knowledge about this bit of code to say what > entries are made in vds_interface table. I know there's an entry for > ovirtmgmt here but not sure if this gets added as part of addHost flow > or not. > I guess, vds_interface table is populated by ips given by vdsm through getVdsCaps. Current glusterHostsList provides one of ipaddress of the local host (other than 127.*.*.*). If virbr0 is enabled, it picks up 192.168.122.1 ip address of the bridge and sends to the engine, but this entry is missing in the table. The requirement is that we need a ip of the local host which is also stored in the database. The database has entries of ips of a host those are from physical nics and/or bridges who has slaves to nics. Regards, Bala > thx > sahina > > On 04/09/2013 06:05 PM, Dan Kenigsberg wrote: >> On Tue, Apr 09, 2013 at 03:55:25PM +0530, Sahina Bose wrote: >>> [Adding vdsm-devel] >>> >>> On 04/09/2013 03:40 PM, Sahina Bose wrote: >>>> Hi all, >>>> >>>> I'm testing the bootstrapping of host without reboot on Fedora 18. >>>> After >>>> host's bootstrap, >>>> Ifconfig output returns this: >>>> >>>> ovirtmgmt: flags=4163 mtu 1500 >>>> inet 10.70.37.219 netmask 255.255.254.0 broadcast >>>> 10.70.37.255 >>>> >>>> >>>> virbr0: flags=4099 mtu 1500 >>>> inet 192.168.122.1 netmask 255.255.255.0 broadcast >>>> 192.168.122.255 >>>> >>>> >>>> Running*glusterHostsList* vdsm verb, returns the ip address >>>> 192.168.122.1, whereas my host has been added with ip address >>>> 10.70.37.219 >>>> >>>> If I reboot the host, the virbr0 bridge is removed, and there's no >>>> issue. >>>> >>>> The vdsm verb glusterHostsList - returns ipAddress of host + >>>> output of gluster peer probe. This is needed because a periodic >>>> sync job needs to make sure that the hosts added in engine are in >>>> sync with the gluster cli (hosts could also be added/removed from >>>> gluster cli). >>>> >>>> How can we make sure glusterHostsList picks the correct ipAddress? >> Can you define (in plain English) what is the "correct" address? >> The host may have multiple valid addresses (storage, migration, display, >> whatnot). >> >> Only when it's clear to us, we can start expressing this in Python. >> >>>> Reading the inetinfo based on bridge has been vetoed as we are >>>> doing away with bridges. >>>> >>>> It would also work if virbr0 was updated in vds_interfaces table. >>>> Since this is not happening either - we have an issue. >> It might be a valid hack to drop this default virbr0 on vdsm start - not >> only the libvirt definition thereof, but also the running kernel device. >> >> However, as expressed above, this would not solve your problem when you >> have a currently-running host with multiple addresses. >> >> Dan. > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel From ecohen at redhat.com Tue Apr 9 18:46:12 2013 From: ecohen at redhat.com (Einav Cohen) Date: Tue, 9 Apr 2013 14:46:12 -0400 (EDT) Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? In-Reply-To: <1925308784.1473910.1365497218477.JavaMail.root@redhat.com> References: <1409255709.910788.1365435347766.JavaMail.root@redhat.com> <678555862.996554.1365489581763.JavaMail.root@redhat.com> <73600709.1019869.1365492158323.JavaMail.root@redhat.com> <1076269299.1020635.1365492242560.JavaMail.root@redhat.com> <1925308784.1473910.1365497218477.JavaMail.root@redhat.com> Message-ID: <458706000.1893571.1365533172289.JavaMail.root@redhat.com> > ----- Original Message ----- > From: "Allon Mureinik" > Sent: Tuesday, April 9, 2013 4:46:58 AM > > OK, patch is merged (thanks kind reviewers!) > > Einav - please check that this also solves the issue in /your/ setup and let > us all know. Hi Allon, I apologize for my late answer - I just took latest upstream and compilation including tests has passed successfully - many thanks for your prompt and helpful response - I appreciate it! > > > Thanks, > Allon > > ----- Original Message ----- > > From: "Allon Mureinik" > > To: "Einav Cohen" > > Cc: "engine-devel" > > Sent: Tuesday, April 9, 2013 10:24:02 AM > > Subject: Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest? > > > > The last message would have been much more useful if I'd actually attached > > the link to my patch: > > http://gerrit.ovirt.org/#/c/13733/ > > > > Note that it is /not/ merge yet - review would be appreciated. > > ----- Original Message ----- > > > From: "Allon Mureinik" > > > To: "Einav Cohen" > > > Cc: "engine-devel" > > > Sent: Tuesday, April 9, 2013 10:22:38 AM > > > Subject: Re: [Engine-devel] compilation stuck on > > > RemoveSnapshotCommandTest? > > > > > > OK, my guess is that test uses Mockito Matchers carelessly. > > > > > > I removed them, and on my setup I reduced the time it takes to run this > > > test > > > alone in eclipse from ~70 seconds to ~0.7 seconds (i.e., removed 99% of > > > the > > > runtime). > > > > > > Please check it solves the issue on your setup too. > > > > > > > > > Thanks, > > > Allon > > > > > > ----- Original Message ----- > > > > From: "Allon Mureinik" > > > > To: "Einav Cohen" > > > > Cc: "engine-devel" > > > > Sent: Tuesday, April 9, 2013 9:39:41 AM > > > > Subject: Re: [Engine-devel] compilation stuck on > > > > RemoveSnapshotCommandTest? > > > > > > > > When running [1] on this morning's master (commit hash eca9964, merged > > > > April > > > > 8th, 20:15 IST) I didn't notice any issues (built the entire project in > > > > ~3 > > > > minutes, backend took 27 seconds), but when running this test alone in > > > > eclipse it definitely took much longer. > > > > > > > > I'm guessing it lacks some mocking, which some earlier test is doing by > > > > mistake. > > > > Since JUnit does not enforce any ordering, we may be running our tests > > > > in > > > > a > > > > slightly different order (due to different maven/java/os minor > > > > versions, > > > > etc.), which makes the problem visible on your setup but not mine. > > > > > > > > I'll do somemore digging and see if I can pinpoint it. > > > > > > > > ----- Original Message ----- > > > > > From: "Einav Cohen" > > > > > To: "engine-devel" > > > > > Sent: Monday, April 8, 2013 6:35:47 PM > > > > > Subject: [Engine-devel] compilation stuck on > > > > > RemoveSnapshotCommandTest? > > > > > > > > > > Hi, > > > > > > > > > > When trying to compile oVirt (with tests - see [1]), my compilation > > > > > seems > > > > > to > > > > > get stuck on > > > > > RemoveSnapshotCommandTest (see [2] for test file full path, [3] for > > > > > output). > > > > > > > > > > When eliminating this test (e.g. I removed [2] locally from my > > > > > file-system), > > > > > compilation > > > > > (including tests) is completed successfully. > > > > > > > > > > Anyone else encountered this problem / any idea what the problem > > > > > might > > > > > be? > > > > > > > > > > ---- > > > > > Thanks, > > > > > Einav > > > > > > > > > > > > > > > [1] performed the following on the latest upstream: > > > > > mvn clean > > > > > mvn install -Pgwt-user,gwt-admin,all-langs -Dgwt.userAgent=gecko1_8 > > > > > > > > > > [2] > > > > > ../backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/RemoveSnapshotCommandTest.java > > > > > > > > > > [3] last lines in compilation output: > > > > > ... > > > > > [INFO] > > > > > ------------------------------------------------------------------------ > > > > > [INFO] Building Backend Logic @Service bean 3.3.0-SNAPSHOT > > > > > [INFO] > > > > > ------------------------------------------------------------------------ > > > > > ... > > > > > > > > > > Running > > > > > org.ovirt.engine.core.bll.network.host.SetupNetworksHelperTest > > > > > Tests run: 56, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.74 > > > > > sec > > > > > Running > > > > > org.ovirt.engine.core.bll.network.cluster.GetAllNetworksByClusterIdQueryTest > > > > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 > > > > > sec > > > > > Running > > > > > org.ovirt.engine.core.bll.network.cluster.AttachNetworkToVdsGroupCommandTest > > > > > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 > > > > > sec > > > > > Running > > > > > org.ovirt.engine.core.bll.network.cluster.NetworkClusterValidatorTest > > > > > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 > > > > > sec > > > > > Running > > > > > org.ovirt.engine.core.bll.network.cluster.GetVdsGroupsAndNetworksByNetworkIdQueryTest > > > > > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 > > > > > sec > > > > > Running > > > > > org.ovirt.engine.core.bll.network.vm.GetVmInterfacesByVmIdQueryTest > > > > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 > > > > > sec > > > > > Running > > > > > org.ovirt.engine.core.bll.network.vm.GetVmsAndNetworkInterfacesByNetworkIdQueryTest > > > > > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056 > > > > > sec > > > > > Running org.ovirt.engine.core.bll.network.VmInterfaceManagerTest > > > > > Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > > > > > 0.321 > > > > > sec > > > > > Running > > > > > org.ovirt.engine.core.bll.network.template.GetTemplateInterfacesByTemplateIdQueryTest > > > > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 > > > > > sec > > > > > Running > > > > > org.ovirt.engine.core.bll.network.template.GetVmTemplatesAndNetworkInterfacesByNetworkIdQueryTest > > > > > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 > > > > > sec > > > > > Running > > > > > org.ovirt.engine.core.bll.GetCommandsCompatibilityVersionsQueryTest > > > > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 > > > > > sec > > > > > Running > > > > > org.ovirt.engine.core.bll.GetClustersWithPermittedActionQueryTest > > > > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 > > > > > sec > > > > > Running org.ovirt.engine.core.bll.RemoveSnapshotCommandTest > > > > > [no more output after this point; waited ~20 minutes in this state > > > > > before > > > > > hitting "Ctrl+C"] > > > > > _______________________________________________ > > > > > 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 > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From danken at redhat.com Tue Apr 9 18:55:55 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Tue, 9 Apr 2013 21:55:55 +0300 Subject: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges In-Reply-To: <51641E79.5030506@redhat.com> References: <5163E932.8040300@redhat.com> <5163EC95.50901@redhat.com> <20130409123535.GK26069@redhat.com> <516412AC.7060907@redhat.com> <51641E79.5030506@redhat.com> Message-ID: <20130409185555.GD11630@redhat.com> On Tue, Apr 09, 2013 at 07:28:17PM +0530, Balamurugan Arumugam wrote: > On 04/09/2013 06:37 PM, Sahina Bose wrote: > >Decoding "correct address" - glusterHostsList should return any > >ipAddress that engine knows as being associated with host. > >It could be either ipAddress used while adding host (stored as hostname > >in vds_static) or any of the ipAddresses populated in vds_interface > >table (addr column) . > >I do not have enough knowledge about this bit of code to say what > >entries are made in vds_interface table. I know there's an entry for > >ovirtmgmt here but not sure if this gets added as part of addHost flow > >or not. > > > > I guess, vds_interface table is populated by ips given by vdsm > through getVdsCaps. > > Current glusterHostsList provides one of ipaddress of the local host > (other than 127.*.*.*). If virbr0 is enabled, it picks up > 192.168.122.1 ip address of the bridge and sends to the engine, but > this entry is missing in the table. > > The requirement is that we need a ip of the local host which is also > stored in the database. > > The database has entries of ips of a host those are from physical > nics and/or bridges who has slaves to nics. It's not something I've tested, or want to encourage, but currently, outside of gluster, Vdsm may run behind a fancy NAT as a virtual server. I.e., its local undress may be utterly different from the address used by Engine. I'd like to keep having this flexibility, and not to assume otherwise. Why does glusterHostsList need to return the ip of the management network? The client that issued this verb has to know that IP in the first place. I notice that the idiom "_getLocalIpAddress() or _getGlusterHostName()" is used all too often in vdsm/gluster/cli.py. How about changing the Vdsm/Engine API so that the string "localhost" is returned instead? Then, Engine can replace it with whatever it seems fit. Dan. From sabose at redhat.com Wed Apr 10 05:48:54 2013 From: sabose at redhat.com (Sahina Bose) Date: Wed, 10 Apr 2013 11:18:54 +0530 Subject: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges In-Reply-To: <20130409185555.GD11630@redhat.com> References: <5163E932.8040300@redhat.com> <5163EC95.50901@redhat.com> <20130409123535.GK26069@redhat.com> <516412AC.7060907@redhat.com> <51641E79.5030506@redhat.com> <20130409185555.GD11630@redhat.com> Message-ID: <5164FD46.7010107@redhat.com> On 04/10/2013 12:25 AM, Dan Kenigsberg wrote: > On Tue, Apr 09, 2013 at 07:28:17PM +0530, Balamurugan Arumugam wrote: >> On 04/09/2013 06:37 PM, Sahina Bose wrote: >>> Decoding "correct address" - glusterHostsList should return any >>> ipAddress that engine knows as being associated with host. >>> It could be either ipAddress used while adding host (stored as hostname >>> in vds_static) or any of the ipAddresses populated in vds_interface >>> table (addr column) . >>> I do not have enough knowledge about this bit of code to say what >>> entries are made in vds_interface table. I know there's an entry for >>> ovirtmgmt here but not sure if this gets added as part of addHost flow >>> or not. >>> >> I guess, vds_interface table is populated by ips given by vdsm >> through getVdsCaps. >> >> Current glusterHostsList provides one of ipaddress of the local host >> (other than 127.*.*.*). If virbr0 is enabled, it picks up >> 192.168.122.1 ip address of the bridge and sends to the engine, but >> this entry is missing in the table. >> >> The requirement is that we need a ip of the local host which is also >> stored in the database. >> >> The database has entries of ips of a host those are from physical >> nics and/or bridges who has slaves to nics. > It's not something I've tested, or want to encourage, but currently, > outside of gluster, Vdsm may run behind a fancy NAT as a virtual server. > I.e., its local undress may be utterly different from the address used > by Engine. > > I'd like to keep having this flexibility, and not to assume otherwise. > > Why does glusterHostsList need to return the ip of the management > network? The client that issued this verb has to know that IP in the > first place. > > I notice that the idiom "_getLocalIpAddress() or _getGlusterHostName()" > is used all too often in vdsm/gluster/cli.py. > > How about changing the Vdsm/Engine API so that the string "localhost" is > returned instead? Then, Engine can replace it with whatever it seems > fit. > > Dan. Dan, Thanks for clarifying. Looks like relying on the IpAddress to determine the host will be prone to errors going forward. We will change the approach and start using the UUID that gluster peer status returns to identify host - will create a new verb glusterPeerList that does this. And for the current host, like you mentioned, since the engine already knows which vdsm host this command is executed on, the engine will not rely on vdsm to return the host's IP. thanks sahina From mskrivan at redhat.com Wed Apr 10 06:12:20 2013 From: mskrivan at redhat.com (Michal Skrivanek) Date: Wed, 10 Apr 2013 02:12:20 -0400 (EDT) Subject: [Engine-devel] [vdsm] Snapshots with RAM feature In-Reply-To: <319368954.768893.1365494496958.JavaMail.root@redhat.com> References: <319368954.768893.1365494496958.JavaMail.root@redhat.com> Message-ID: <720BEF86-8C5F-43AC-8EE2-6CCD05AD8107@redhat.com> On 9 Apr 2013, at 10:01, Arik Hadas wrote: > Hi All, > > The proposed feature will make it possible to run a VM which was reverted to live snapshot > or created from live snapshot with the same memory state as it was at the moment the live > snapshot was taken. > > http://www.ovirt.org/Features/RAM_Snapshots > > All feedback is welcome! Nice! Perhaps on "Run VM" - how about instead of giving an option on start we'd have the possibility to strip the saved ram in snapshot beforehand? And keep the run logic as always start with ram when it exists. Also it is important to discard the ram on all forms of Run VM. Better discard it on error than mistakenly rerun with ram twice > > Regards, > Arik > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel From sanjal at redhat.com Wed Apr 10 06:40:19 2013 From: sanjal at redhat.com (Shireesh Anjal) Date: Wed, 10 Apr 2013 12:10:19 +0530 Subject: [Engine-devel] build stuck on RunVmCommandTest Message-ID: <51650953.4000405@redhat.com> Hi, From last night onwards, my mvn build is getting stuck for a long time ( > 30 minutes) on RunVmCommandTest Running org.ovirt.engine.core.bll.MoveDisksCommandTest Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec *Running org.ovirt.engine.core.bll.RunVmCommandTest** **Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1,983.033 sec** *Running org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.ovirt.engine.core.bll.RemoveImageCommandTest The same issue is happening on one of my colleague's system as well. Any help in fixing this will be highly appreciated. Regards, Shireesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From amureini at redhat.com Wed Apr 10 08:09:29 2013 From: amureini at redhat.com (Allon Mureinik) Date: Wed, 10 Apr 2013 04:09:29 -0400 (EDT) Subject: [Engine-devel] build stuck on RunVmCommandTest In-Reply-To: <51650953.4000405@redhat.com> References: <51650953.4000405@redhat.com> Message-ID: <1352516269.1980766.1365581369908.JavaMail.root@redhat.com> Real oddness. out of interest, can you run "java -version" and report the version here? ----- Original Message ----- > From: "Shireesh Anjal" > To: engine-devel at ovirt.org > Sent: Wednesday, April 10, 2013 9:40:19 AM > Subject: [Engine-devel] build stuck on RunVmCommandTest > Hi, > From last night onwards, my mvn build is getting stuck for a long time ( > 30 > minutes) on RunVmCommandTest > Running org.ovirt.engine.core.bll.MoveDisksCommandTest > Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec > Running org.ovirt.engine.core.bll.RunVmCommandTest > Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1,983.033 > sec > Running org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec > Running org.ovirt.engine.core.bll.RemoveImageCommandTest > The same issue is happening on one of my colleague's system as well. Any help > in fixing this will be highly appreciated. > Regards, > Shireesh > _______________________________________________ > 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: From sanjal at redhat.com Wed Apr 10 08:15:40 2013 From: sanjal at redhat.com (Shireesh Anjal) Date: Wed, 10 Apr 2013 13:45:40 +0530 Subject: [Engine-devel] build stuck on RunVmCommandTest In-Reply-To: <1352516269.1980766.1365581369908.JavaMail.root@redhat.com> References: <51650953.4000405@redhat.com> <1352516269.1980766.1365581369908.JavaMail.root@redhat.com> Message-ID: <51651FAC.5050508@redhat.com> On 04/10/2013 01:39 PM, Allon Mureinik wrote: > Real oddness. > out of interest, can you run > "java -version" > > and report the version here? shireesh at localhost ovirt-engine]$ java -version java version "1.7.0_09-icedtea" OpenJDK Runtime Environment (fedora-2.3.4.fc18-x86_64) OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) > > > ------------------------------------------------------------------------ > > *From: *"Shireesh Anjal" > *To: *engine-devel at ovirt.org > *Sent: *Wednesday, April 10, 2013 9:40:19 AM > *Subject: *[Engine-devel] build stuck on RunVmCommandTest > > Hi, > > From last night onwards, my mvn build is getting stuck for a long > time ( > 30 minutes) on RunVmCommandTest > > Running org.ovirt.engine.core.bll.MoveDisksCommandTest > Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 0.04 sec > *Running org.ovirt.engine.core.bll.RunVmCommandTest** > **Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 1,983.033 sec** > *Running org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 0.007 sec > Running org.ovirt.engine.core.bll.RemoveImageCommandTest > > The same issue is happening on one of my colleague's system as > well. Any help in fixing this will be highly appreciated. > > Regards, > Shireesh > > _______________________________________________ > 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: From amureini at redhat.com Wed Apr 10 08:31:00 2013 From: amureini at redhat.com (Allon Mureinik) Date: Wed, 10 Apr 2013 04:31:00 -0400 (EDT) Subject: [Engine-devel] build stuck on RunVmCommandTest In-Reply-To: <51651FAC.5050508@redhat.com> References: <51650953.4000405@redhat.com> <1352516269.1980766.1365581369908.JavaMail.root@redhat.com> <51651FAC.5050508@redhat.com> Message-ID: <1791575171.1993238.1365582660654.JavaMail.root@redhat.com> Einav had a similar issue yesterday with RemoveDiskTest (IIRC), which at first pointed me to the direction of Java 7, but this is unrelated. The root of all these problems is commit fd6835059f110f4e14d67c9d2d31aa786a822f4b (core: Locate data source in a loop) - now, whenever we have unmocked DAO calls (like in RunVmCommand), instead of failing them fast and silently, we'll get stuck in a loop. We need to see if we can offer a quick workaround, or perhaps revert this patch until we can offer such a solution. Juan, your input would be appreciates here. Thanks, Allon ----- Original Message ----- > From: "Shireesh Anjal" > To: "Allon Mureinik" > Cc: engine-devel at ovirt.org > Sent: Wednesday, April 10, 2013 11:15:40 AM > Subject: Re: [Engine-devel] build stuck on RunVmCommandTest > On 04/10/2013 01:39 PM, Allon Mureinik wrote: > > Real oddness. > > > out of interest, can you run > > > "java -version" > > > and report the version here? > > shireesh at localhost ovirt-engine]$ java -version > java version "1.7.0_09-icedtea" > OpenJDK Runtime Environment (fedora-2.3.4.fc18-x86_64) > OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) > > ----- Original Message ----- > > > > From: "Shireesh Anjal" > > > > > > To: engine-devel at ovirt.org > > > > > > Sent: Wednesday, April 10, 2013 9:40:19 AM > > > > > > Subject: [Engine-devel] build stuck on RunVmCommandTest > > > > > > Hi, > > > > > > From last night onwards, my mvn build is getting stuck for a long time ( > > > > > > > 30 > > > minutes) on RunVmCommandTest > > > > > > Running org.ovirt.engine.core.bll.MoveDisksCommandTest > > > > > > Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec > > > > > > Running org.ovirt.engine.core.bll.RunVmCommandTest > > > > > > Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > > > 1,983.033 > > > sec > > > > > > Running org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest > > > > > > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec > > > > > > Running org.ovirt.engine.core.bll.RemoveImageCommandTest > > > > > > The same issue is happening on one of my colleague's system as well. Any > > > help > > > in fixing this will be highly appreciated. > > > > > > Regards, > > > > > > Shireesh > > > > > > _______________________________________________ > > > > > > 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: From mperina at redhat.com Wed Apr 10 08:31:08 2013 From: mperina at redhat.com (Martin Perina) Date: Wed, 10 Apr 2013 04:31:08 -0400 (EDT) Subject: [Engine-devel] Added support for POSIX and GNU long parameters to engine-manage-domains In-Reply-To: <767857389.1986553.1365581891260.JavaMail.root@redhat.com> Message-ID: <419122359.1993879.1365582668909.JavaMail.root@redhat.com> Hi, I've created a patch that adds support for POSIX and GNU long paramaters. Patch is using argparse4j library (argparse4j.sourceforge.net), which suites our needs in my opinion better than other libraries I've tested (JCommander, commons-cli, args4j). Patch includes these changes: 1) "-action" parameter has been removed, each action is specified directly, for example "engine-manage-domains list" 2) "-interactive" parameter has been removed, if "--passwordFile" parameter is not specified, then the password will be read interactively 3) "-addPermissions" parameter has been rename to "--superuser" with "-s" short version 4) Each parameter has POSIX variant ("-p PROVIDER") and corresponding GNU long variant ("--provider=PROVIDER") 5) Commands and parameters names can be abbreviated as long as the abbreviation is unambiguous (for example "list" command can be specified like "engine-manage-domains l") So for example command to create a domain now may look like this: engine-manage-domains add -d xyz.com -p IPA -u admin engine-manage-domains add --domain=xyz.com --provider=IPA --user=admin engine-manage-domains a -d xyz.com -p ipa --user=admin All variants do the same. If you're interested, please review the patch: http://gerrit.ovirt.org/#/c/13776/ Regards Martin Perina From sabose at redhat.com Wed Apr 10 08:32:21 2013 From: sabose at redhat.com (Sahina Bose) Date: Wed, 10 Apr 2013 14:02:21 +0530 Subject: [Engine-devel] build stuck on RunVmCommandTest In-Reply-To: <51651FAC.5050508@redhat.com> References: <51650953.4000405@redhat.com> <1352516269.1980766.1365581369908.JavaMail.root@redhat.com> <51651FAC.5050508@redhat.com> Message-ID: <51652395.3070401@redhat.com> I have the same issue. My build was getting stuck on RunVmCommandTest. When I commented out tests in this, it is now getting stuck at AddVmTemplateCommandTest. java version "1.7.0_17" OpenJDK Runtime Environment (fedora-2.3.8.3.fc17-x86_64) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) On 04/10/2013 01:45 PM, Shireesh Anjal wrote: > On 04/10/2013 01:39 PM, Allon Mureinik wrote: >> Real oddness. >> out of interest, can you run >> "java -version" >> >> and report the version here? > > shireesh at localhost ovirt-engine]$ java -version > java version "1.7.0_09-icedtea" > OpenJDK Runtime Environment (fedora-2.3.4.fc18-x86_64) > OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) > >> >> >> ------------------------------------------------------------------------ >> >> *From: *"Shireesh Anjal" >> *To: *engine-devel at ovirt.org >> *Sent: *Wednesday, April 10, 2013 9:40:19 AM >> *Subject: *[Engine-devel] build stuck on RunVmCommandTest >> >> Hi, >> >> From last night onwards, my mvn build is getting stuck for a long >> time ( > 30 minutes) on RunVmCommandTest >> >> Running org.ovirt.engine.core.bll.MoveDisksCommandTest >> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: >> 0.04 sec >> *Running org.ovirt.engine.core.bll.RunVmCommandTest** >> **Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time >> elapsed: 1,983.033 sec** >> *Running org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest >> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: >> 0.007 sec >> Running org.ovirt.engine.core.bll.RemoveImageCommandTest >> >> The same issue is happening on one of my colleague's system as >> well. Any help in fixing this will be highly appreciated. >> >> Regards, >> Shireesh >> >> _______________________________________________ >> 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: From danken at redhat.com Wed Apr 10 08:43:12 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Wed, 10 Apr 2013 11:43:12 +0300 Subject: [Engine-devel] [vdsm] Snapshots with RAM feature In-Reply-To: <720BEF86-8C5F-43AC-8EE2-6CCD05AD8107@redhat.com> References: <319368954.768893.1365494496958.JavaMail.root@redhat.com> <720BEF86-8C5F-43AC-8EE2-6CCD05AD8107@redhat.com> Message-ID: <20130410084312.GD32275@redhat.com> On Wed, Apr 10, 2013 at 02:12:20AM -0400, Michal Skrivanek wrote: > > > On 9 Apr 2013, at 10:01, Arik Hadas wrote: > > > Hi All, > > > > The proposed feature will make it possible to run a VM which was reverted to live snapshot > > or created from live snapshot with the same memory state as it was at the moment the live > > snapshot was taken. > > > > http://www.ovirt.org/Features/RAM_Snapshots > > > > All feedback is welcome! > Nice! (I prefer to inline the document when discussing it) > VDSM changes > > Default parameter will be added to vmSnapshot verb that maps string to string. > The map will include two keys for now: > 'mode' that can be mapped to 'disks_only' or 'disks_memory' to > indicate if memory state should be saved. > 'memVol' that will be mapped to a string that represent the two > volums that will be used to save the memory state and the > VM configuration. The default map will include the > mapping of 'mode':'disks_only' only. > > If the 'mode' value in the map decribed above is > 'disks_memory' the first volume in 'memVol' will be > passed to libvirt in order to dump the memory to > it, and the second volume in 'memVol' will be used > to save the VM configuration (the same way it is > done for hibernate operation). This definition of 'memVol' would not allow saving the state to another storage domain, or a direct lun or whatever. I suggest that you have two independet arguments, say memVol and vmConfVol. Both may have the standard pool-domain-image-volume quartet, or a lun specification, or a local path. From barumuga at redhat.com Wed Apr 10 08:49:11 2013 From: barumuga at redhat.com (Balamurugan Arumugam) Date: Wed, 10 Apr 2013 14:19:11 +0530 Subject: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges In-Reply-To: <5164FD46.7010107@redhat.com> References: <5163E932.8040300@redhat.com> <5163EC95.50901@redhat.com> <20130409123535.GK26069@redhat.com> <516412AC.7060907@redhat.com> <51641E79.5030506@redhat.com> <20130409185555.GD11630@redhat.com> <5164FD46.7010107@redhat.com> Message-ID: <51652787.8020205@redhat.com> On 04/10/2013 11:18 AM, Sahina Bose wrote: > > On 04/10/2013 12:25 AM, Dan Kenigsberg wrote: >> On Tue, Apr 09, 2013 at 07:28:17PM +0530, Balamurugan Arumugam wrote: >>> On 04/09/2013 06:37 PM, Sahina Bose wrote: >>>> Decoding "correct address" - glusterHostsList should return any >>>> ipAddress that engine knows as being associated with host. >>>> It could be either ipAddress used while adding host (stored as hostname >>>> in vds_static) or any of the ipAddresses populated in vds_interface >>>> table (addr column) . >>>> I do not have enough knowledge about this bit of code to say what >>>> entries are made in vds_interface table. I know there's an entry for >>>> ovirtmgmt here but not sure if this gets added as part of addHost flow >>>> or not. >>>> >>> I guess, vds_interface table is populated by ips given by vdsm >>> through getVdsCaps. >>> >>> Current glusterHostsList provides one of ipaddress of the local host >>> (other than 127.*.*.*). If virbr0 is enabled, it picks up >>> 192.168.122.1 ip address of the bridge and sends to the engine, but >>> this entry is missing in the table. >>> >>> The requirement is that we need a ip of the local host which is also >>> stored in the database. >>> >>> The database has entries of ips of a host those are from physical >>> nics and/or bridges who has slaves to nics. >> It's not something I've tested, or want to encourage, but currently, >> outside of gluster, Vdsm may run behind a fancy NAT as a virtual server. >> I.e., its local undress may be utterly different from the address used >> by Engine. >> >> I'd like to keep having this flexibility, and not to assume otherwise. >> >> Why does glusterHostsList need to return the ip of the management >> network? The client that issued this verb has to know that IP in the >> first place. >> >> I notice that the idiom "_getLocalIpAddress() or _getGlusterHostName()" >> is used all too often in vdsm/gluster/cli.py. >> >> How about changing the Vdsm/Engine API so that the string "localhost" is >> returned instead? Then, Engine can replace it with whatever it seems >> fit. >> >> Dan. > Dan, > > Thanks for clarifying. Looks like relying on the IpAddress to determine > the host will be prone to errors going forward. > We will change the approach and start using the UUID that gluster peer > status returns to identify host - will create a new verb glusterPeerList > that does this. > Current glusterHostsList provides list of {'hostname': HOSTNAME, 'uuid': UUID, 'status': STATE} including local host. What will be the difference between new glusterPeerList and existing glusterHostsList? > And for the current host, like you mentioned, since the engine already > knows which vdsm host this command is executed on, the engine will not > rely on vdsm to return the host's IP. > Regards, Bala From sabose at redhat.com Wed Apr 10 08:53:14 2013 From: sabose at redhat.com (Sahina Bose) Date: Wed, 10 Apr 2013 14:23:14 +0530 Subject: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges In-Reply-To: <51652787.8020205@redhat.com> References: <5163E932.8040300@redhat.com> <5163EC95.50901@redhat.com> <20130409123535.GK26069@redhat.com> <516412AC.7060907@redhat.com> <51641E79.5030506@redhat.com> <20130409185555.GD11630@redhat.com> <5164FD46.7010107@redhat.com> <51652787.8020205@redhat.com> Message-ID: <5165287A.1010003@redhat.com> On 04/10/2013 02:19 PM, Balamurugan Arumugam wrote: > On 04/10/2013 11:18 AM, Sahina Bose wrote: >> >> On 04/10/2013 12:25 AM, Dan Kenigsberg wrote: >>> On Tue, Apr 09, 2013 at 07:28:17PM +0530, Balamurugan Arumugam wrote: >>>> On 04/09/2013 06:37 PM, Sahina Bose wrote: >>>>> Decoding "correct address" - glusterHostsList should return any >>>>> ipAddress that engine knows as being associated with host. >>>>> It could be either ipAddress used while adding host (stored as >>>>> hostname >>>>> in vds_static) or any of the ipAddresses populated in vds_interface >>>>> table (addr column) . >>>>> I do not have enough knowledge about this bit of code to say what >>>>> entries are made in vds_interface table. I know there's an entry for >>>>> ovirtmgmt here but not sure if this gets added as part of addHost >>>>> flow >>>>> or not. >>>>> >>>> I guess, vds_interface table is populated by ips given by vdsm >>>> through getVdsCaps. >>>> >>>> Current glusterHostsList provides one of ipaddress of the local host >>>> (other than 127.*.*.*). If virbr0 is enabled, it picks up >>>> 192.168.122.1 ip address of the bridge and sends to the engine, but >>>> this entry is missing in the table. >>>> >>>> The requirement is that we need a ip of the local host which is also >>>> stored in the database. >>>> >>>> The database has entries of ips of a host those are from physical >>>> nics and/or bridges who has slaves to nics. >>> It's not something I've tested, or want to encourage, but currently, >>> outside of gluster, Vdsm may run behind a fancy NAT as a virtual >>> server. >>> I.e., its local undress may be utterly different from the address used >>> by Engine. >>> >>> I'd like to keep having this flexibility, and not to assume otherwise. >>> >>> Why does glusterHostsList need to return the ip of the management >>> network? The client that issued this verb has to know that IP in the >>> first place. >>> >>> I notice that the idiom "_getLocalIpAddress() or _getGlusterHostName()" >>> is used all too often in vdsm/gluster/cli.py. >>> >>> How about changing the Vdsm/Engine API so that the string >>> "localhost" is >>> returned instead? Then, Engine can replace it with whatever it seems >>> fit. >>> >>> Dan. >> Dan, >> >> Thanks for clarifying. Looks like relying on the IpAddress to determine >> the host will be prone to errors going forward. >> We will change the approach and start using the UUID that gluster peer >> status returns to identify host - will create a new verb glusterPeerList >> that does this. >> > > Current glusterHostsList provides list of > {'hostname': HOSTNAME, 'uuid': UUID, 'status': STATE} including local > host. > > What will be the difference between new glusterPeerList and existing > glusterHostsList? > If this is the case, we just need to make sure at engine we use UUID and not IP address to identify host. We would still need a vdsm verb that will return the current host gluster UUID, to store in engine in case of Add Host flow. > > >> And for the current host, like you mentioned, since the engine already >> knows which vdsm host this command is executed on, the engine will not >> rely on vdsm to return the host's IP. >> > > > Regards, > Bala > > From barumuga at redhat.com Wed Apr 10 08:57:55 2013 From: barumuga at redhat.com (Balamurugan Arumugam) Date: Wed, 10 Apr 2013 14:27:55 +0530 Subject: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges In-Reply-To: <5165287A.1010003@redhat.com> References: <5163E932.8040300@redhat.com> <5163EC95.50901@redhat.com> <20130409123535.GK26069@redhat.com> <516412AC.7060907@redhat.com> <51641E79.5030506@redhat.com> <20130409185555.GD11630@redhat.com> <5164FD46.7010107@redhat.com> <51652787.8020205@redhat.com> <5165287A.1010003@redhat.com> Message-ID: <51652993.1000906@redhat.com> On 04/10/2013 02:23 PM, Sahina Bose wrote: > > On 04/10/2013 02:19 PM, Balamurugan Arumugam wrote: >> On 04/10/2013 11:18 AM, Sahina Bose wrote: >>> >>> On 04/10/2013 12:25 AM, Dan Kenigsberg wrote: >>>> On Tue, Apr 09, 2013 at 07:28:17PM +0530, Balamurugan Arumugam wrote: >>>>> On 04/09/2013 06:37 PM, Sahina Bose wrote: >>>>>> Decoding "correct address" - glusterHostsList should return any >>>>>> ipAddress that engine knows as being associated with host. >>>>>> It could be either ipAddress used while adding host (stored as >>>>>> hostname >>>>>> in vds_static) or any of the ipAddresses populated in vds_interface >>>>>> table (addr column) . >>>>>> I do not have enough knowledge about this bit of code to say what >>>>>> entries are made in vds_interface table. I know there's an entry for >>>>>> ovirtmgmt here but not sure if this gets added as part of addHost >>>>>> flow >>>>>> or not. >>>>>> >>>>> I guess, vds_interface table is populated by ips given by vdsm >>>>> through getVdsCaps. >>>>> >>>>> Current glusterHostsList provides one of ipaddress of the local host >>>>> (other than 127.*.*.*). If virbr0 is enabled, it picks up >>>>> 192.168.122.1 ip address of the bridge and sends to the engine, but >>>>> this entry is missing in the table. >>>>> >>>>> The requirement is that we need a ip of the local host which is also >>>>> stored in the database. >>>>> >>>>> The database has entries of ips of a host those are from physical >>>>> nics and/or bridges who has slaves to nics. >>>> It's not something I've tested, or want to encourage, but currently, >>>> outside of gluster, Vdsm may run behind a fancy NAT as a virtual >>>> server. >>>> I.e., its local undress may be utterly different from the address used >>>> by Engine. >>>> >>>> I'd like to keep having this flexibility, and not to assume otherwise. >>>> >>>> Why does glusterHostsList need to return the ip of the management >>>> network? The client that issued this verb has to know that IP in the >>>> first place. >>>> >>>> I notice that the idiom "_getLocalIpAddress() or _getGlusterHostName()" >>>> is used all too often in vdsm/gluster/cli.py. >>>> >>>> How about changing the Vdsm/Engine API so that the string >>>> "localhost" is >>>> returned instead? Then, Engine can replace it with whatever it seems >>>> fit. >>>> >>>> Dan. >>> Dan, >>> >>> Thanks for clarifying. Looks like relying on the IpAddress to determine >>> the host will be prone to errors going forward. >>> We will change the approach and start using the UUID that gluster peer >>> status returns to identify host - will create a new verb glusterPeerList >>> that does this. >>> >> >> Current glusterHostsList provides list of >> {'hostname': HOSTNAME, 'uuid': UUID, 'status': STATE} including local >> host. >> >> What will be the difference between new glusterPeerList and existing >> glusterHostsList? >> > If this is the case, we just need to make sure at engine we use UUID and > not IP address to identify host. We would still need a vdsm verb that > will return the current host gluster UUID, to store in engine in case of > Add Host flow. I think, getVdsCaps can include this. Dan, is it good idea? >> >> >>> And for the current host, like you mentioned, since the engine already >>> knows which vdsm host this command is executed on, the engine will not >>> rely on vdsm to return the host's IP. >>> >> >> Regards, Bala From jhernand at redhat.com Wed Apr 10 10:12:16 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Wed, 10 Apr 2013 12:12:16 +0200 Subject: [Engine-devel] build stuck on RunVmCommandTest In-Reply-To: <1791575171.1993238.1365582660654.JavaMail.root@redhat.com> References: <51650953.4000405@redhat.com> <1352516269.1980766.1365581369908.JavaMail.root@redhat.com> <51651FAC.5050508@redhat.com> <1791575171.1993238.1365582660654.JavaMail.root@redhat.com> Message-ID: <51653B00.8030005@redhat.com> On 04/10/2013 10:31 AM, Allon Mureinik wrote: > Einav had a similar issue yesterday with RemoveDiskTest (IIRC), which at > first pointed me to the direction of Java 7, but this is unrelated. > > The root of all these problems is commit > fd6835059f110f4e14d67c9d2d31aa786a822f4b (core: Locate data source in a > loop) - now, whenever we have unmocked DAO calls (like in RunVmCommand), > instead of failing them fast and silently, we'll get stuck in a loop. > > We need to see if we can offer a quick workaround, or perhaps revert > this patch until we can offer such a solution. > Juan, your input would be appreciates here. > As a workaround create /etc/ovirt-engine/engine.conf and add the following two lines: ENGINE_DB_CONNECTION_TIMEOUT=0 ENGINE_DB_CHECK_INTERVAL=0 Then the tests should run faster. > > Thanks, > Allon > > ------------------------------------------------------------------------ > > *From: *"Shireesh Anjal" > *To: *"Allon Mureinik" > *Cc: *engine-devel at ovirt.org > *Sent: *Wednesday, April 10, 2013 11:15:40 AM > *Subject: *Re: [Engine-devel] build stuck on RunVmCommandTest > > On 04/10/2013 01:39 PM, Allon Mureinik wrote: > > Real oddness. > out of interest, can you run > "java -version" > > and report the version here? > > > shireesh at localhost ovirt-engine]$ java -version > java version "1.7.0_09-icedtea" > OpenJDK Runtime Environment (fedora-2.3.4.fc18-x86_64) > OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) > > > > ------------------------------------------------------------------------ > > *From: *"Shireesh Anjal" > *To: *engine-devel at ovirt.org > *Sent: *Wednesday, April 10, 2013 9:40:19 AM > *Subject: *[Engine-devel] build stuck on RunVmCommandTest > > Hi, > > From last night onwards, my mvn build is getting stuck for > a long time ( > 30 minutes) on RunVmCommandTest > > Running org.ovirt.engine.core.bll.MoveDisksCommandTest > Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time > elapsed: 0.04 sec > *Running org.ovirt.engine.core.bll.RunVmCommandTest** > **Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time > elapsed: 1,983.033 sec** > *Running org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time > elapsed: 0.007 sec > Running org.ovirt.engine.core.bll.RemoveImageCommandTest > > The same issue is happening on one of my colleague's system > as well. Any help in fixing this will be highly appreciated. > > Regards, > Shireesh > > _______________________________________________ > 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 > -- 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 jhernand at redhat.com Wed Apr 10 10:58:17 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Wed, 10 Apr 2013 12:58:17 +0200 Subject: [Engine-devel] build stuck on RunVmCommandTest In-Reply-To: <51653B00.8030005@redhat.com> References: <51650953.4000405@redhat.com> <1352516269.1980766.1365581369908.JavaMail.root@redhat.com> <51651FAC.5050508@redhat.com> <1791575171.1993238.1365582660654.JavaMail.root@redhat.com> <51653B00.8030005@redhat.com> Message-ID: <516545C9.9080209@redhat.com> On 04/10/2013 12:12 PM, Juan Hernandez wrote: > On 04/10/2013 10:31 AM, Allon Mureinik wrote: >> Einav had a similar issue yesterday with RemoveDiskTest (IIRC), which at >> first pointed me to the direction of Java 7, but this is unrelated. >> >> The root of all these problems is commit >> fd6835059f110f4e14d67c9d2d31aa786a822f4b (core: Locate data source in a >> loop) - now, whenever we have unmocked DAO calls (like in RunVmCommand), >> instead of failing them fast and silently, we'll get stuck in a loop. >> >> We need to see if we can offer a quick workaround, or perhaps revert >> this patch until we can offer such a solution. >> Juan, your input would be appreciates here. >> > > As a workaround create /etc/ovirt-engine/engine.conf and add the > following two lines: > > ENGINE_DB_CONNECTION_TIMEOUT=0 > ENGINE_DB_CHECK_INTERVAL=0 > > Then the tests should run faster. > This is a way to solve it: http://gerrit.ovirt.org/13782 >> >> Thanks, >> Allon >> >> ------------------------------------------------------------------------ >> >> *From: *"Shireesh Anjal" >> *To: *"Allon Mureinik" >> *Cc: *engine-devel at ovirt.org >> *Sent: *Wednesday, April 10, 2013 11:15:40 AM >> *Subject: *Re: [Engine-devel] build stuck on RunVmCommandTest >> >> On 04/10/2013 01:39 PM, Allon Mureinik wrote: >> >> Real oddness. >> out of interest, can you run >> "java -version" >> >> and report the version here? >> >> >> shireesh at localhost ovirt-engine]$ java -version >> java version "1.7.0_09-icedtea" >> OpenJDK Runtime Environment (fedora-2.3.4.fc18-x86_64) >> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) >> >> >> >> ------------------------------------------------------------------------ >> >> *From: *"Shireesh Anjal" >> *To: *engine-devel at ovirt.org >> *Sent: *Wednesday, April 10, 2013 9:40:19 AM >> *Subject: *[Engine-devel] build stuck on RunVmCommandTest >> >> Hi, >> >> From last night onwards, my mvn build is getting stuck for >> a long time ( > 30 minutes) on RunVmCommandTest >> >> Running org.ovirt.engine.core.bll.MoveDisksCommandTest >> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time >> elapsed: 0.04 sec >> *Running org.ovirt.engine.core.bll.RunVmCommandTest** >> **Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time >> elapsed: 1,983.033 sec** >> *Running org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest >> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time >> elapsed: 0.007 sec >> Running org.ovirt.engine.core.bll.RemoveImageCommandTest >> >> The same issue is happening on one of my colleague's system >> as well. Any help in fixing this will be highly appreciated. >> >> Regards, >> Shireesh >> >> _______________________________________________ >> 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 >> > > -- 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 sabose at redhat.com Wed Apr 10 11:16:46 2013 From: sabose at redhat.com (Sahina Bose) Date: Wed, 10 Apr 2013 16:46:46 +0530 Subject: [Engine-devel] build stuck on RunVmCommandTest In-Reply-To: <516545C9.9080209@redhat.com> References: <51650953.4000405@redhat.com> <1352516269.1980766.1365581369908.JavaMail.root@redhat.com> <51651FAC.5050508@redhat.com> <1791575171.1993238.1365582660654.JavaMail.root@redhat.com> <51653B00.8030005@redhat.com> <516545C9.9080209@redhat.com> Message-ID: <51654A1E.6090108@redhat.com> Juan, thanks! This patch fixed the problem. On 04/10/2013 04:28 PM, Juan Hernandez wrote: > On 04/10/2013 12:12 PM, Juan Hernandez wrote: >> On 04/10/2013 10:31 AM, Allon Mureinik wrote: >>> Einav had a similar issue yesterday with RemoveDiskTest (IIRC), >>> which at >>> first pointed me to the direction of Java 7, but this is unrelated. >>> >>> The root of all these problems is commit >>> fd6835059f110f4e14d67c9d2d31aa786a822f4b (core: Locate data source in a >>> loop) - now, whenever we have unmocked DAO calls (like in >>> RunVmCommand), >>> instead of failing them fast and silently, we'll get stuck in a loop. >>> >>> We need to see if we can offer a quick workaround, or perhaps revert >>> this patch until we can offer such a solution. >>> Juan, your input would be appreciates here. >>> >> >> As a workaround create /etc/ovirt-engine/engine.conf and add the >> following two lines: >> >> ENGINE_DB_CONNECTION_TIMEOUT=0 >> ENGINE_DB_CHECK_INTERVAL=0 >> >> Then the tests should run faster. >> > > This is a way to solve it: > > http://gerrit.ovirt.org/13782 > >>> >>> Thanks, >>> Allon >>> >>> ------------------------------------------------------------------------ >>> >>> >>> *From: *"Shireesh Anjal" >>> *To: *"Allon Mureinik" >>> *Cc: *engine-devel at ovirt.org >>> *Sent: *Wednesday, April 10, 2013 11:15:40 AM >>> *Subject: *Re: [Engine-devel] build stuck on RunVmCommandTest >>> >>> On 04/10/2013 01:39 PM, Allon Mureinik wrote: >>> >>> Real oddness. >>> out of interest, can you run >>> "java -version" >>> >>> and report the version here? >>> >>> >>> shireesh at localhost ovirt-engine]$ java -version >>> java version "1.7.0_09-icedtea" >>> OpenJDK Runtime Environment (fedora-2.3.4.fc18-x86_64) >>> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> *From: *"Shireesh Anjal" >>> *To: *engine-devel at ovirt.org >>> *Sent: *Wednesday, April 10, 2013 9:40:19 AM >>> *Subject: *[Engine-devel] build stuck on RunVmCommandTest >>> >>> Hi, >>> >>> From last night onwards, my mvn build is getting stuck >>> for >>> a long time ( > 30 minutes) on RunVmCommandTest >>> >>> Running org.ovirt.engine.core.bll.MoveDisksCommandTest >>> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time >>> elapsed: 0.04 sec >>> *Running org.ovirt.engine.core.bll.RunVmCommandTest** >>> **Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time >>> elapsed: 1,983.033 sec** >>> *Running >>> org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest >>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time >>> elapsed: 0.007 sec >>> Running org.ovirt.engine.core.bll.RemoveImageCommandTest >>> >>> The same issue is happening on one of my colleague's >>> system >>> as well. Any help in fixing this will be highly >>> appreciated. >>> >>> Regards, >>> Shireesh >>> >>> _______________________________________________ >>> 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 danken at redhat.com Wed Apr 10 11:41:42 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Wed, 10 Apr 2013 14:41:42 +0300 Subject: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges In-Reply-To: <51652993.1000906@redhat.com> References: <5163E932.8040300@redhat.com> <5163EC95.50901@redhat.com> <20130409123535.GK26069@redhat.com> <516412AC.7060907@redhat.com> <51641E79.5030506@redhat.com> <20130409185555.GD11630@redhat.com> <5164FD46.7010107@redhat.com> <51652787.8020205@redhat.com> <5165287A.1010003@redhat.com> <51652993.1000906@redhat.com> Message-ID: <20130410114142.GE32275@redhat.com> On Wed, Apr 10, 2013 at 02:27:55PM +0530, Balamurugan Arumugam wrote: > On 04/10/2013 02:23 PM, Sahina Bose wrote: > > > >On 04/10/2013 02:19 PM, Balamurugan Arumugam wrote: > >>On 04/10/2013 11:18 AM, Sahina Bose wrote: > >>> > >>>On 04/10/2013 12:25 AM, Dan Kenigsberg wrote: > >>>>On Tue, Apr 09, 2013 at 07:28:17PM +0530, Balamurugan Arumugam wrote: > >>>>>On 04/09/2013 06:37 PM, Sahina Bose wrote: > >>>>>>Decoding "correct address" - glusterHostsList should return any > >>>>>>ipAddress that engine knows as being associated with host. > >>>>>>It could be either ipAddress used while adding host (stored as > >>>>>>hostname > >>>>>>in vds_static) or any of the ipAddresses populated in vds_interface > >>>>>>table (addr column) . > >>>>>>I do not have enough knowledge about this bit of code to say what > >>>>>>entries are made in vds_interface table. I know there's an entry for > >>>>>>ovirtmgmt here but not sure if this gets added as part of addHost > >>>>>>flow > >>>>>>or not. > >>>>>> > >>>>>I guess, vds_interface table is populated by ips given by vdsm > >>>>>through getVdsCaps. > >>>>> > >>>>>Current glusterHostsList provides one of ipaddress of the local host > >>>>>(other than 127.*.*.*). If virbr0 is enabled, it picks up > >>>>>192.168.122.1 ip address of the bridge and sends to the engine, but > >>>>>this entry is missing in the table. > >>>>> > >>>>>The requirement is that we need a ip of the local host which is also > >>>>>stored in the database. > >>>>> > >>>>>The database has entries of ips of a host those are from physical > >>>>>nics and/or bridges who has slaves to nics. > >>>>It's not something I've tested, or want to encourage, but currently, > >>>>outside of gluster, Vdsm may run behind a fancy NAT as a virtual > >>>>server. > >>>>I.e., its local undress may be utterly different from the address used > >>>>by Engine. > >>>> > >>>>I'd like to keep having this flexibility, and not to assume otherwise. > >>>> > >>>>Why does glusterHostsList need to return the ip of the management > >>>>network? The client that issued this verb has to know that IP in the > >>>>first place. > >>>> > >>>>I notice that the idiom "_getLocalIpAddress() or _getGlusterHostName()" > >>>>is used all too often in vdsm/gluster/cli.py. > >>>> > >>>>How about changing the Vdsm/Engine API so that the string > >>>>"localhost" is > >>>>returned instead? Then, Engine can replace it with whatever it seems > >>>>fit. > >>>> > >>>>Dan. > >>>Dan, > >>> > >>>Thanks for clarifying. Looks like relying on the IpAddress to determine > >>>the host will be prone to errors going forward. > >>>We will change the approach and start using the UUID that gluster peer > >>>status returns to identify host - will create a new verb glusterPeerList > >>>that does this. > >>> > >> > >>Current glusterHostsList provides list of > >>{'hostname': HOSTNAME, 'uuid': UUID, 'status': STATE} including local > >>host. > >> > >>What will be the difference between new glusterPeerList and existing > >>glusterHostsList? > >> > >If this is the case, we just need to make sure at engine we use UUID and > >not IP address to identify host. We would still need a vdsm verb that > >will return the current host gluster UUID, to store in engine in case of > >Add Host flow. > > > I think, getVdsCaps can include this. Dan, is it good idea? I do not mind adding glusterUUID to this "bag of things". (preferably impleneting it within the vdsm-gluster subpackage) I hope Saggi or Adam do not mind making getVdsCaps a little bit more dirty - they may sagguest that you add a getGlusterUUID verb. Dan. From amureini at redhat.com Wed Apr 10 13:42:05 2013 From: amureini at redhat.com (Allon Mureinik) Date: Wed, 10 Apr 2013 09:42:05 -0400 (EDT) Subject: [Engine-devel] build stuck on RunVmCommandTest In-Reply-To: <516545C9.9080209@redhat.com> References: <51650953.4000405@redhat.com> <1352516269.1980766.1365581369908.JavaMail.root@redhat.com> <51651FAC.5050508@redhat.com> <1791575171.1993238.1365582660654.JavaMail.root@redhat.com> <51653B00.8030005@redhat.com> <516545C9.9080209@redhat.com> Message-ID: <1123008125.2179478.1365601325052.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Juan Hernandez" > To: "Allon Mureinik" > Cc: "Shireesh Anjal" , engine-devel at ovirt.org > Sent: Wednesday, April 10, 2013 1:58:17 PM > Subject: Re: [Engine-devel] build stuck on RunVmCommandTest > > On 04/10/2013 12:12 PM, Juan Hernandez wrote: > > On 04/10/2013 10:31 AM, Allon Mureinik wrote: > >> Einav had a similar issue yesterday with RemoveDiskTest (IIRC), which at > >> first pointed me to the direction of Java 7, but this is unrelated. > >> > >> The root of all these problems is commit > >> fd6835059f110f4e14d67c9d2d31aa786a822f4b (core: Locate data source in a > >> loop) - now, whenever we have unmocked DAO calls (like in RunVmCommand), > >> instead of failing them fast and silently, we'll get stuck in a loop. > >> > >> We need to see if we can offer a quick workaround, or perhaps revert > >> this patch until we can offer such a solution. > >> Juan, your input would be appreciates here. > >> > > > > As a workaround create /etc/ovirt-engine/engine.conf and add the > > following two lines: > > > > ENGINE_DB_CONNECTION_TIMEOUT=0 > > ENGINE_DB_CHECK_INTERVAL=0 > > > > Then the tests should run faster. > > > > This is a way to solve it: > > http://gerrit.ovirt.org/13782 Didn't get a chance to look at it before it was merged, but looks great. Thanks Juan! > > >> > >> Thanks, > >> Allon > >> > >> ------------------------------------------------------------------------ > >> > >> *From: *"Shireesh Anjal" > >> *To: *"Allon Mureinik" > >> *Cc: *engine-devel at ovirt.org > >> *Sent: *Wednesday, April 10, 2013 11:15:40 AM > >> *Subject: *Re: [Engine-devel] build stuck on RunVmCommandTest > >> > >> On 04/10/2013 01:39 PM, Allon Mureinik wrote: > >> > >> Real oddness. > >> out of interest, can you run > >> "java -version" > >> > >> and report the version here? > >> > >> > >> shireesh at localhost ovirt-engine]$ java -version > >> java version "1.7.0_09-icedtea" > >> OpenJDK Runtime Environment (fedora-2.3.4.fc18-x86_64) > >> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) > >> > >> > >> > >> ------------------------------------------------------------------------ > >> > >> *From: *"Shireesh Anjal" > >> *To: *engine-devel at ovirt.org > >> *Sent: *Wednesday, April 10, 2013 9:40:19 AM > >> *Subject: *[Engine-devel] build stuck on RunVmCommandTest > >> > >> Hi, > >> > >> From last night onwards, my mvn build is getting stuck for > >> a long time ( > 30 minutes) on RunVmCommandTest > >> > >> Running org.ovirt.engine.core.bll.MoveDisksCommandTest > >> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time > >> elapsed: 0.04 sec > >> *Running org.ovirt.engine.core.bll.RunVmCommandTest** > >> **Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time > >> elapsed: 1,983.033 sec** > >> *Running > >> org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest > >> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time > >> elapsed: 0.007 sec > >> Running org.ovirt.engine.core.bll.RemoveImageCommandTest > >> > >> The same issue is happening on one of my colleague's system > >> as well. Any help in fixing this will be highly appreciated. > >> > >> Regards, > >> Shireesh > >> > >> _______________________________________________ > >> 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 > >> > > > > > > > -- > 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 lhornyak at redhat.com Wed Apr 10 13:59:42 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Wed, 10 Apr 2013 09:59:42 -0400 (EDT) Subject: [Engine-devel] watchdog In-Reply-To: <1447454875.1495872.1365601657115.JavaMail.root@redhat.com> Message-ID: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> Hi, A new version of the watchd?g feature is available in gerrit: http://gerrit.ovirt.org/13057 - db http://gerrit.ovirt.org/13058 - bll http://gerrit.ovirt.org/13059 - frontend http://gerrit.ovirt.org/13060 - rest http://www.ovirt.org/Features/Watchdog_engine_support Since the last update the patchset has gone through major changes to meet the new architectureal and functional requirements. Also because of the rewrite this is again a preview version under testing with some missing functionality, therefore I re-introduced the [wip] flag on it. Thx, Laszlo From ahadas at redhat.com Wed Apr 10 14:16:42 2013 From: ahadas at redhat.com (Arik Hadas) Date: Wed, 10 Apr 2013 10:16:42 -0400 (EDT) Subject: [Engine-devel] [vdsm] Snapshots with RAM feature In-Reply-To: <720BEF86-8C5F-43AC-8EE2-6CCD05AD8107@redhat.com> References: <319368954.768893.1365494496958.JavaMail.root@redhat.com> <720BEF86-8C5F-43AC-8EE2-6CCD05AD8107@redhat.com> Message-ID: <2073421298.1508445.1365603402200.JavaMail.root@redhat.com> ----- Original Message ----- > > > On 9 Apr 2013, at 10:01, Arik Hadas wrote: > > > Hi All, > > > > The proposed feature will make it possible to run a VM which was reverted > > to live snapshot > > or created from live snapshot with the same memory state as it was at the > > moment the live > > snapshot was taken. > > > > http://www.ovirt.org/Features/RAM_Snapshots > > > > All feedback is welcome! > Nice! > Perhaps on "Run VM" - how about instead of giving an option on start we'd > have the possibility to strip the saved ram in snapshot beforehand? And keep > the run logic as always start with ram when it exists. Yes, it makes sense to keep the run vm process short and simple by using the logic you propose and not to display any dialog in the process. An alternative approach for the removal of the ram from the snapshot can be to display a check box in the clone vm from snapshot dialog so that the user will be able to select whether to take the memory from the snapshot or not. and in the preview snapshot process to display a dialog with such check box also. that way we will be able to create both with memory state and without memory state VMs from snapshot that contains memory state. > Also it is important to discard the ram on all forms of Run VM. Better > discard it on error than mistakenly rerun with ram twice Absolutely, we should ensure that we remove the ram from the VM configuration if there's a chance that either the disks or the memory was changed since the VM was created from/reverted to the snapshot. > > > > > Regards, > > Arik > > _______________________________________________ > > vdsm-devel mailing list > > vdsm-devel at lists.fedorahosted.org > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > From iheim at redhat.com Wed Apr 10 19:38:15 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 10 Apr 2013 22:38:15 +0300 Subject: [Engine-devel] watchdog In-Reply-To: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> Message-ID: <5165BFA7.3080207@redhat.com> On 04/10/2013 04:59 PM, Laszlo Hornyak wrote: > Hi, > > A new version of the watchd?g feature is available in gerrit: > > http://gerrit.ovirt.org/13057 - db > http://gerrit.ovirt.org/13058 - bll > http://gerrit.ovirt.org/13059 - frontend > http://gerrit.ovirt.org/13060 - rest > > http://www.ovirt.org/Features/Watchdog_engine_support > > Since the last update the patchset has gone through major changes to meet the new architectureal and functional requirements. > Also because of the rewrite this is again a preview version under testing with some missing functionality, therefore I re-introduced the [wip] flag on it. > > Thx, > Laszlo > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > just a thought after looking at the feature page having different HA dialog for server/desktop - I'd consider removing the distinction between desktop and server in the GUI wrt HA (i.e., just both have same set of options) (not blocking for this patch) From deadhorseconsulting at gmail.com Wed Apr 10 20:23:10 2013 From: deadhorseconsulting at gmail.com (Dead Horse) Date: Wed, 10 Apr 2013 15:23:10 -0500 Subject: [Engine-devel] upgrade failing with latest master Message-ID: logs attached First attempt: 2013-04-10 13:57:32::ERROR::common_utils::355::root:: YUM: FAIL: Error in PREUN scriptlet in rpm package ovirt-engine-backend-3.3.0-15.fc17.noarch 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: Script sink: /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet failed, exit status 1 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: Done: ovirt-engine-backend-3.3.0-15.fc17.noarch Second attempt: 2013-04-10 15:12:11::DEBUG::common_utils::347::root:: YUM: VERB: Building transaction 2013-04-10 15:12:12::ERROR::common_utils::355::root:: YUM: FAIL: [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires ovirt-engine = 3.3.0-14.fc17'] 2013-04-10 15:12:12::DEBUG::common_utils::347::root:: YUM: VERB: Performing rollback 2013-04-10 15:12:12::DEBUG::common_utils::1410::root:: Locking rpms in yum-version-lock 2013-04-10 15:12:12::ERROR::engine-upgrade::1299::root:: Traceback (most recent call last): File "/bin/engine-upgrade", line 1292, in main(options) File "/bin/engine-upgrade", line 1142, in main runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) File "/bin/engine-upgrade", line 617, in runFunc func() File "/bin/engine-upgrade", line 310, in begin self.emptyTransaction = not self._miniyum.buildTransaction() File "/usr/share/ovirt-engine/scripts/miniyum.py", line 761, in buildTransaction raise yum.Errors.YumBaseError(msg) YumBaseError: [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires ovirt-engine = 3.3.0-14.fc17'] Realizing things were now hosed: [root at ovirtfoo /]# yum erase ovirt-* otopi-* Loaded plugins: langpacks, presto, refresh-packagekit, versionlock Resolving Dependencies --> Running transaction check ---> Package otopi.noarch 0:3.3.0-15.fc17 will be erased ---> Package otopi-java.noarch 0:3.3.0-15.fc17 will be erased ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 will be erased ---> Package ovirt-engine-backend.noarch 0:3.3.0-14.fc17 will be erased ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be erased ---> Package ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 will be erased ---> Package ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 will be erased ---> Package ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 will be erased ---> Package ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 will be erased ---> Package ovirt-engine-setup.noarch 0:3.3.0-15.fc17 will be erased ---> Package ovirt-engine-tools.noarch 0:3.3.0-14.fc17 will be erased ---> Package ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 will be erased ---> Package ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 will be erased ---> Package ovirt-host-deploy.noarch 0:3.3.0-15.fc17 will be erased ---> Package ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 will be erased ---> Package ovirt-image-uploader.noarch 0:3.3.0-15.fc17 will be erased ---> Package ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 will be erased ---> Package ovirt-log-collector.noarch 0:3.3.0-15.fc17 will be erased --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine 1.3 M ovirt-engine-backend noarch 3.3.0-14.fc17 @ovirt-engine 20 M ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M ovirt-engine-cli noarch 3.3.0.1-15.fc17 @ovirt-engine 557 k ovirt-engine-dbscripts noarch 3.3.0-14.fc17 @ovirt-engine 816 k ovirt-engine-restapi noarch 3.3.0-14.fc17 @ovirt-engine 1.0 M ovirt-engine-sdk noarch 3.3.0.1-15.fc17 @ovirt-engine 3.1 M ovirt-engine-setup noarch 3.3.0-15.fc17 @ovirt-engine 653 k ovirt-engine-tools noarch 3.3.0-14.fc17 @ovirt-engine 178 k ovirt-engine-userportal noarch 3.3.0-14.fc17 @ovirt-engine 23 M ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 @ovirt-engine 32 M ovirt-host-deploy noarch 3.3.0-15.fc17 @ovirt-engine 211 k ovirt-host-deploy-java noarch 3.3.0-15.fc17 @ovirt-engine 11 k ovirt-image-uploader noarch 3.3.0-15.fc17 @ovirt-engine 923 k ovirt-iso-uploader noarch 3.3.0-15.fc17 @ovirt-engine 98 k ovirt-log-collector noarch 3.3.0-15.fc17 @ovirt-engine 133 k Transaction Summary ================================================================================ Remove 18 Packages Installed size: 104 M Is this ok [y/N]: y Downloading Packages: Running Transaction Check Running Transaction Test Transaction Test Succeeded Running Transaction Erasing : ovirt-engine-backend.noarch 1/18 Erasing : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 2/18 Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch 3/18 Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch 4/18 Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch 5/18 Erasing : ovirt-engine-userportal-3.3.0-14.fc17.noarch 6/18 Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 warning: /etc/ovirt-engine/engine.conf saved as /etc/ovirt-engine/engine.conf.rpmsave Erasing : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 8/18 Erasing : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 9/18 Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch 11/18 Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 warning: /etc/ovirt-engine/imageuploader.conf saved as /etc/ovirt-engine/imageuploader.conf.rpmsave Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 warning: /etc/ovirt-engine/isouploader.conf saved as /etc/ovirt-engine/isouploader.conf.rpmsave Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch 14/18 warning: /etc/ovirt-engine/logcollector.conf saved as /etc/ovirt-engine/logcollector.conf.rpmsave Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 15/18 Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 16/18 Erasing : otopi-3.3.0-15.fc17.noarch 17/18 Error in PREUN scriptlet in rpm package ovirt-engine-backend /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet failed, exit status 1 Verifying : otopi-3.3.0-15.fc17.noarch 1/18 Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 Verifying : ovirt-log-collector-3.3.0-15.fc17.noarch 3/18 Verifying : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 4/18 Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch 5/18 Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch 6/18 Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch 7/18 Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 8/18 Verifying : ovirt-engine-restapi-3.3.0-14.fc17.noarch 9/18 Verifying : ovirt-engine-userportal-3.3.0-14.fc17.noarch 10/18 Verifying : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 11/18 Verifying : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 14/18 ovirt-engine-backend-3.3.0-15.fc17.noarch was supposed to be removed but is not! Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 15/18 Verifying : ovirt-engine-backend-3.3.0-14.fc17.noarch 16/18 Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 Verifying : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 18/18 Removed: otopi.noarch 0:3.3.0-15.fc17 otopi-java.noarch 0:3.3.0-15.fc17 ovirt-engine.noarch 0:3.3.0-14.fc17 ovirt-engine-backend.noarch 0:3.3.0-14.fc17 ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 ovirt-engine-setup.noarch 0:3.3.0-15.fc17 ovirt-engine-tools.noarch 0:3.3.0-14.fc17 ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 ovirt-host-deploy.noarch 0:3.3.0-15.fc17 ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 ovirt-image-uploader.noarch 0:3.3.0-15.fc17 ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 ovirt-log-collector.noarch 0:3.3.0-15.fc17 Failed: ovirt-engine-backend.noarch 0:3.3.0-15.fc17 Complete! [root at ovirtfoo /]# rpm -qa | grep oto protobuf-java-2.4.1-12.fc17.x86_64 libgphoto2-2.4.14-1.fc17.x86_64 [root at ovirtfoo /]# rpm -qa | grep ovirt ovirt-engine-backend-3.3.0-15.fc17.noarch [root at ovirtfoo /]# yum erase ovirt-engine-backend-3.3.0-15.fc17.noarch Loaded plugins: langpacks, presto, refresh-packagekit, versionlock Resolving Dependencies --> Running transaction check ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be erased --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M Transaction Summary ================================================================================ Remove 1 Package Installed size: 20 M Is this ok [y/N]: y Downloading Packages: Running Transaction Check Running Transaction Test Transaction Test Succeeded Running Transaction Error in PREUN scriptlet in rpm package ovirt-engine-backend-3.3.0-15.fc17.noarch /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet failed, exit status 1 Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 1/1 Failed: ovirt-engine-backend.noarch 0:3.3.0-15.fc17 Complete! - DHC -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ovirt-engine-upgrade_2013_04_10_13_51_45.log Type: application/octet-stream Size: 90825 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ovirt-engine-upgrade_2013_04_10_15_12_07.log Type: application/octet-stream Size: 6058 bytes Desc: not available URL: From alonbl at redhat.com Wed Apr 10 20:32:34 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Wed, 10 Apr 2013 16:32:34 -0400 (EDT) Subject: [Engine-devel] upgrade failing with latest master In-Reply-To: References: Message-ID: <499700726.1036974.1365625954171.JavaMail.root@redhat.com> Is this fedora 17 or 18? I guess it is fedora 17. ----- Original Message ----- > From: "Dead Horse" > To: engine-devel at ovirt.org > Sent: Wednesday, April 10, 2013 11:23:10 PM > Subject: [Engine-devel] upgrade failing with latest master > > logs attached > > First attempt: > 2013-04-10 13:57:32::ERROR::common_utils::355::root:: YUM: FAIL: Error in > PREUN scriptlet in rpm package ovirt-engine-backend-3.3.0-15.fc17.noarch > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: Script sink: > /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet failed, > exit status 1 > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: Done: > ovirt-engine-backend-3.3.0-15.fc17.noarch > > Second attempt: > 2013-04-10 15:12:11::DEBUG::common_utils::347::root:: YUM: VERB: Building > transaction > 2013-04-10 15:12:12::ERROR::common_utils::355::root:: YUM: FAIL: > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires ovirt-engine = > 3.3.0-14.fc17'] > 2013-04-10 15:12:12::DEBUG::common_utils::347::root:: YUM: VERB: Performing > rollback > 2013-04-10 15:12:12::DEBUG::common_utils::1410::root:: Locking rpms in > yum-version-lock > 2013-04-10 15:12:12::ERROR::engine-upgrade::1299::root:: Traceback (most > recent call last): > File "/bin/engine-upgrade", line 1292, in > main(options) > File "/bin/engine-upgrade", line 1142, in main > runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) > File "/bin/engine-upgrade", line 617, in runFunc > func() > File "/bin/engine-upgrade", line 310, in begin > self.emptyTransaction = not self._miniyum.buildTransaction() > File "/usr/share/ovirt-engine/scripts/miniyum.py", line 761, in > buildTransaction > raise yum.Errors.YumBaseError(msg) > YumBaseError: [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires > ovirt-engine = 3.3.0-14.fc17'] > > Realizing things were now hosed: > [root at ovirtfoo /]# yum erase ovirt-* otopi-* > Loaded plugins: langpacks, presto, refresh-packagekit, versionlock > Resolving Dependencies > --> Running transaction check > ---> Package otopi.noarch 0:3.3.0-15.fc17 will be erased > ---> Package otopi-java.noarch 0:3.3.0-15.fc17 will be erased > ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 will be erased > ---> Package ovirt-engine-backend.noarch 0:3.3.0-14.fc17 will be erased > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be erased > ---> Package ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 will be erased > ---> Package ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 will be erased > ---> Package ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 will be erased > ---> Package ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 will be erased > ---> Package ovirt-engine-setup.noarch 0:3.3.0-15.fc17 will be erased > ---> Package ovirt-engine-tools.noarch 0:3.3.0-14.fc17 will be erased > ---> Package ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 will be erased > ---> Package ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 will be > erased > ---> Package ovirt-host-deploy.noarch 0:3.3.0-15.fc17 will be erased > ---> Package ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 will be erased > ---> Package ovirt-image-uploader.noarch 0:3.3.0-15.fc17 will be erased > ---> Package ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 will be erased > ---> Package ovirt-log-collector.noarch 0:3.3.0-15.fc17 will be erased > --> Finished Dependency Resolution > > Dependencies Resolved > > ================================================================================ > Package Arch Version Repository Size > ================================================================================ > Removing: > otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k > otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k > ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine 1.3 M > ovirt-engine-backend noarch 3.3.0-14.fc17 @ovirt-engine 20 M > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > ovirt-engine-cli noarch 3.3.0.1-15.fc17 @ovirt-engine 557 k > ovirt-engine-dbscripts noarch 3.3.0-14.fc17 @ovirt-engine 816 k > ovirt-engine-restapi noarch 3.3.0-14.fc17 @ovirt-engine 1.0 M > ovirt-engine-sdk noarch 3.3.0.1-15.fc17 @ovirt-engine 3.1 M > ovirt-engine-setup noarch 3.3.0-15.fc17 @ovirt-engine 653 k > ovirt-engine-tools noarch 3.3.0-14.fc17 @ovirt-engine 178 k > ovirt-engine-userportal noarch 3.3.0-14.fc17 @ovirt-engine 23 M > ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 @ovirt-engine 32 M > ovirt-host-deploy noarch 3.3.0-15.fc17 @ovirt-engine 211 k > ovirt-host-deploy-java noarch 3.3.0-15.fc17 @ovirt-engine 11 k > ovirt-image-uploader noarch 3.3.0-15.fc17 @ovirt-engine 923 k > ovirt-iso-uploader noarch 3.3.0-15.fc17 @ovirt-engine 98 k > ovirt-log-collector noarch 3.3.0-15.fc17 @ovirt-engine 133 k > > Transaction Summary > ================================================================================ > Remove 18 Packages > > Installed size: 104 M > Is this ok [y/N]: y > Downloading Packages: > Running Transaction Check > Running Transaction Test > Transaction Test Succeeded > Running Transaction > Erasing : ovirt-engine-backend.noarch 1/18 > Erasing : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 2/18 > Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch 3/18 > Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch 4/18 > Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch 5/18 > Erasing : ovirt-engine-userportal-3.3.0-14.fc17.noarch 6/18 > Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 > warning: /etc/ovirt-engine/engine.conf saved as > /etc/ovirt-engine/engine.conf.rpmsave > Erasing : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 8/18 > Erasing : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 9/18 > Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 > Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch 11/18 > Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > warning: /etc/ovirt-engine/imageuploader.conf saved as > /etc/ovirt-engine/imageuploader.conf.rpmsave > Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > warning: /etc/ovirt-engine/isouploader.conf saved as > /etc/ovirt-engine/isouploader.conf.rpmsave > Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch 14/18 > warning: /etc/ovirt-engine/logcollector.conf saved as > /etc/ovirt-engine/logcollector.conf.rpmsave > Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 15/18 > Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 16/18 > Erasing : otopi-3.3.0-15.fc17.noarch 17/18 > Error in PREUN scriptlet in rpm package ovirt-engine-backend > /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet failed, > exit status 1 > Verifying : otopi-3.3.0-15.fc17.noarch 1/18 > Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 > Verifying : ovirt-log-collector-3.3.0-15.fc17.noarch 3/18 > Verifying : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 4/18 > Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch 5/18 > Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch 6/18 > Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch 7/18 > Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 8/18 > Verifying : ovirt-engine-restapi-3.3.0-14.fc17.noarch 9/18 > Verifying : ovirt-engine-userportal-3.3.0-14.fc17.noarch 10/18 > Verifying : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 11/18 > Verifying : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 14/18 > ovirt-engine-backend-3.3.0-15.fc17.noarch was supposed to be removed but is > not! > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 15/18 > Verifying : ovirt-engine-backend-3.3.0-14.fc17.noarch 16/18 > Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 > Verifying : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 18/18 > > Removed: > otopi.noarch 0:3.3.0-15.fc17 > otopi-java.noarch 0:3.3.0-15.fc17 > ovirt-engine.noarch 0:3.3.0-14.fc17 > ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > Failed: > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > Complete! > [root at ovirtfoo /]# rpm -qa | grep oto > protobuf-java-2.4.1-12.fc17.x86_64 > libgphoto2-2.4.14-1.fc17.x86_64 > [root at ovirtfoo /]# rpm -qa | grep ovirt > ovirt-engine-backend-3.3.0-15.fc17.noarch > [root at ovirtfoo /]# yum erase ovirt-engine-backend-3.3.0-15.fc17.noarch > Loaded plugins: langpacks, presto, refresh-packagekit, versionlock > Resolving Dependencies > --> Running transaction check > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be erased > --> Finished Dependency Resolution > > Dependencies Resolved > > ================================================================================ > Package Arch Version Repository Size > ================================================================================ > Removing: > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > Transaction Summary > ================================================================================ > Remove 1 Package > > Installed size: 20 M > Is this ok [y/N]: y > Downloading Packages: > Running Transaction Check > Running Transaction Test > Transaction Test Succeeded > Running Transaction > Error in PREUN scriptlet in rpm package > ovirt-engine-backend-3.3.0-15.fc17.noarch > /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet failed, > exit status 1 > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 1/1 > > Failed: > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > Complete! > > - DHC > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From deadhorseconsulting at gmail.com Wed Apr 10 20:59:15 2013 From: deadhorseconsulting at gmail.com (Dead Horse) Date: Wed, 10 Apr 2013 15:59:15 -0500 Subject: [Engine-devel] upgrade failing with latest master In-Reply-To: <499700726.1036974.1365625954171.JavaMail.root@redhat.com> References: <499700726.1036974.1365625954171.JavaMail.root@redhat.com> Message-ID: Correct, FC17 - DHC On Wed, Apr 10, 2013 at 3:32 PM, Alon Bar-Lev wrote: > Is this fedora 17 or 18? > > I guess it is fedora 17. > > ----- Original Message ----- > > From: "Dead Horse" > > To: engine-devel at ovirt.org > > Sent: Wednesday, April 10, 2013 11:23:10 PM > > Subject: [Engine-devel] upgrade failing with latest master > > > > logs attached > > > > First attempt: > > 2013-04-10 13:57:32::ERROR::common_utils::355::root:: YUM: FAIL: Error in > > PREUN scriptlet in rpm package ovirt-engine-backend-3.3.0-15.fc17.noarch > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: Script > sink: > > /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet > failed, > > exit status 1 > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: Done: > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > Second attempt: > > 2013-04-10 15:12:11::DEBUG::common_utils::347::root:: YUM: VERB: Building > > transaction > > 2013-04-10 15:12:12::ERROR::common_utils::355::root:: YUM: FAIL: > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires ovirt-engine = > > 3.3.0-14.fc17'] > > 2013-04-10 15:12:12::DEBUG::common_utils::347::root:: YUM: VERB: > Performing > > rollback > > 2013-04-10 15:12:12::DEBUG::common_utils::1410::root:: Locking rpms in > > yum-version-lock > > 2013-04-10 15:12:12::ERROR::engine-upgrade::1299::root:: Traceback (most > > recent call last): > > File "/bin/engine-upgrade", line 1292, in > > main(options) > > File "/bin/engine-upgrade", line 1142, in main > > runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) > > File "/bin/engine-upgrade", line 617, in runFunc > > func() > > File "/bin/engine-upgrade", line 310, in begin > > self.emptyTransaction = not self._miniyum.buildTransaction() > > File "/usr/share/ovirt-engine/scripts/miniyum.py", line 761, in > > buildTransaction > > raise yum.Errors.YumBaseError(msg) > > YumBaseError: [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires > > ovirt-engine = 3.3.0-14.fc17'] > > > > Realizing things were now hosed: > > [root at ovirtfoo /]# yum erase ovirt-* otopi-* > > Loaded plugins: langpacks, presto, refresh-packagekit, versionlock > > Resolving Dependencies > > --> Running transaction check > > ---> Package otopi.noarch 0:3.3.0-15.fc17 will be erased > > ---> Package otopi-java.noarch 0:3.3.0-15.fc17 will be erased > > ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 will be erased > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-14.fc17 will be erased > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be erased > > ---> Package ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 will be erased > > ---> Package ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 will be erased > > ---> Package ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 will be erased > > ---> Package ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 will be erased > > ---> Package ovirt-engine-setup.noarch 0:3.3.0-15.fc17 will be erased > > ---> Package ovirt-engine-tools.noarch 0:3.3.0-14.fc17 will be erased > > ---> Package ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 will be > erased > > ---> Package ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 will be > > erased > > ---> Package ovirt-host-deploy.noarch 0:3.3.0-15.fc17 will be erased > > ---> Package ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 will be erased > > ---> Package ovirt-image-uploader.noarch 0:3.3.0-15.fc17 will be erased > > ---> Package ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 will be erased > > ---> Package ovirt-log-collector.noarch 0:3.3.0-15.fc17 will be erased > > --> Finished Dependency Resolution > > > > Dependencies Resolved > > > > > ================================================================================ > > Package Arch Version Repository Size > > > ================================================================================ > > Removing: > > otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k > > otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k > > ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine 1.3 M > > ovirt-engine-backend noarch 3.3.0-14.fc17 @ovirt-engine 20 M > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > ovirt-engine-cli noarch 3.3.0.1-15.fc17 @ovirt-engine 557 k > > ovirt-engine-dbscripts noarch 3.3.0-14.fc17 @ovirt-engine 816 k > > ovirt-engine-restapi noarch 3.3.0-14.fc17 @ovirt-engine 1.0 M > > ovirt-engine-sdk noarch 3.3.0.1-15.fc17 @ovirt-engine 3.1 M > > ovirt-engine-setup noarch 3.3.0-15.fc17 @ovirt-engine 653 k > > ovirt-engine-tools noarch 3.3.0-14.fc17 @ovirt-engine 178 k > > ovirt-engine-userportal noarch 3.3.0-14.fc17 @ovirt-engine 23 M > > ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 @ovirt-engine 32 M > > ovirt-host-deploy noarch 3.3.0-15.fc17 @ovirt-engine 211 k > > ovirt-host-deploy-java noarch 3.3.0-15.fc17 @ovirt-engine 11 k > > ovirt-image-uploader noarch 3.3.0-15.fc17 @ovirt-engine 923 k > > ovirt-iso-uploader noarch 3.3.0-15.fc17 @ovirt-engine 98 k > > ovirt-log-collector noarch 3.3.0-15.fc17 @ovirt-engine 133 k > > > > Transaction Summary > > > ================================================================================ > > Remove 18 Packages > > > > Installed size: 104 M > > Is this ok [y/N]: y > > Downloading Packages: > > Running Transaction Check > > Running Transaction Test > > Transaction Test Succeeded > > Running Transaction > > Erasing : ovirt-engine-backend.noarch 1/18 > > Erasing : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 2/18 > > Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch 3/18 > > Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch 4/18 > > Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch 5/18 > > Erasing : ovirt-engine-userportal-3.3.0-14.fc17.noarch 6/18 > > Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 > > warning: /etc/ovirt-engine/engine.conf saved as > > /etc/ovirt-engine/engine.conf.rpmsave > > Erasing : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 8/18 > > Erasing : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 9/18 > > Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 > > Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch 11/18 > > Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > warning: /etc/ovirt-engine/imageuploader.conf saved as > > /etc/ovirt-engine/imageuploader.conf.rpmsave > > Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > warning: /etc/ovirt-engine/isouploader.conf saved as > > /etc/ovirt-engine/isouploader.conf.rpmsave > > Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch 14/18 > > warning: /etc/ovirt-engine/logcollector.conf saved as > > /etc/ovirt-engine/logcollector.conf.rpmsave > > Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 15/18 > > Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 16/18 > > Erasing : otopi-3.3.0-15.fc17.noarch 17/18 > > Error in PREUN scriptlet in rpm package ovirt-engine-backend > > /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet > failed, > > exit status 1 > > Verifying : otopi-3.3.0-15.fc17.noarch 1/18 > > Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 > > Verifying : ovirt-log-collector-3.3.0-15.fc17.noarch 3/18 > > Verifying : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 4/18 > > Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch 5/18 > > Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch 6/18 > > Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch 7/18 > > Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 8/18 > > Verifying : ovirt-engine-restapi-3.3.0-14.fc17.noarch 9/18 > > Verifying : ovirt-engine-userportal-3.3.0-14.fc17.noarch 10/18 > > Verifying : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 11/18 > > Verifying : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 14/18 > > ovirt-engine-backend-3.3.0-15.fc17.noarch was supposed to be removed but > is > > not! > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 15/18 > > Verifying : ovirt-engine-backend-3.3.0-14.fc17.noarch 16/18 > > Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 > > Verifying : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 18/18 > > > > Removed: > > otopi.noarch 0:3.3.0-15.fc17 > > otopi-java.noarch 0:3.3.0-15.fc17 > > ovirt-engine.noarch 0:3.3.0-14.fc17 > > ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > > ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > > ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > > ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > > ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > > ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > > ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > > ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > > ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > > ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > > ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > > ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > > ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > Failed: > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > Complete! > > [root at ovirtfoo /]# rpm -qa | grep oto > > protobuf-java-2.4.1-12.fc17.x86_64 > > libgphoto2-2.4.14-1.fc17.x86_64 > > [root at ovirtfoo /]# rpm -qa | grep ovirt > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > [root at ovirtfoo /]# yum erase ovirt-engine-backend-3.3.0-15.fc17.noarch > > Loaded plugins: langpacks, presto, refresh-packagekit, versionlock > > Resolving Dependencies > > --> Running transaction check > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be erased > > --> Finished Dependency Resolution > > > > Dependencies Resolved > > > > > ================================================================================ > > Package Arch Version Repository Size > > > ================================================================================ > > Removing: > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > > > Transaction Summary > > > ================================================================================ > > Remove 1 Package > > > > Installed size: 20 M > > Is this ok [y/N]: y > > Downloading Packages: > > Running Transaction Check > > Running Transaction Test > > Transaction Test Succeeded > > Running Transaction > > Error in PREUN scriptlet in rpm package > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet > failed, > > exit status 1 > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 1/1 > > > > Failed: > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > Complete! > > > > - DHC > > > > > > > > _______________________________________________ > > 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: From alonbl at redhat.com Wed Apr 10 21:02:43 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Wed, 10 Apr 2013 17:02:43 -0400 (EDT) Subject: [Engine-devel] upgrade failing with latest master In-Reply-To: References: <499700726.1036974.1365625954171.JavaMail.root@redhat.com> Message-ID: <269004897.1042115.1365627763231.JavaMail.root@redhat.com> OK... the systemd macros are missing in fedora 17... Put the following file and rebuild. I may need to add some workaround if many people still use fedora-17 for master. Regards, Alon /etc/rpm/macros.systemd-fc18 --- %systemd_post() \ if [ $1 -eq 1 ] ; then \ # Initial installation \ /usr/bin/systemctl preset %{?*} >/dev/null 2>&1 || : \ fi \ %{nil} %systemd_preun() \ if [ $1 -eq 0 ] ; then \ # Package removal, not upgrade \ /usr/bin/systemctl --no-reload disable %{?*} > /dev/null 2>&1 || : \ /usr/bin/systemctl stop %{?*} > /dev/null 2>&1 || : \ fi \ %{nil} %systemd_postun() \ /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ %{nil} %systemd_postun_with_restart() \ /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ if [ $1 -ge 1 ] ; then \ # Package upgrade, not uninstall \ /usr/bin/systemctl try-restart %{?*} >/dev/null 2>&1 || : \ fi \ %{nil} --- ----- Original Message ----- > From: "Dead Horse" > To: "Alon Bar-Lev" > Cc: engine-devel at ovirt.org > Sent: Wednesday, April 10, 2013 11:59:15 PM > Subject: Re: [Engine-devel] upgrade failing with latest master > > Correct, FC17 > - DHC > > > On Wed, Apr 10, 2013 at 3:32 PM, Alon Bar-Lev wrote: > > > Is this fedora 17 or 18? > > > > I guess it is fedora 17. > > > > ----- Original Message ----- > > > From: "Dead Horse" > > > To: engine-devel at ovirt.org > > > Sent: Wednesday, April 10, 2013 11:23:10 PM > > > Subject: [Engine-devel] upgrade failing with latest master > > > > > > logs attached > > > > > > First attempt: > > > 2013-04-10 13:57:32::ERROR::common_utils::355::root:: YUM: FAIL: Error in > > > PREUN scriptlet in rpm package ovirt-engine-backend-3.3.0-15.fc17.noarch > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: Script > > sink: > > > /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet > > failed, > > > exit status 1 > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: Done: > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > Second attempt: > > > 2013-04-10 15:12:11::DEBUG::common_utils::347::root:: YUM: VERB: Building > > > transaction > > > 2013-04-10 15:12:12::ERROR::common_utils::355::root:: YUM: FAIL: > > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires ovirt-engine = > > > 3.3.0-14.fc17'] > > > 2013-04-10 15:12:12::DEBUG::common_utils::347::root:: YUM: VERB: > > Performing > > > rollback > > > 2013-04-10 15:12:12::DEBUG::common_utils::1410::root:: Locking rpms in > > > yum-version-lock > > > 2013-04-10 15:12:12::ERROR::engine-upgrade::1299::root:: Traceback (most > > > recent call last): > > > File "/bin/engine-upgrade", line 1292, in > > > main(options) > > > File "/bin/engine-upgrade", line 1142, in main > > > runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) > > > File "/bin/engine-upgrade", line 617, in runFunc > > > func() > > > File "/bin/engine-upgrade", line 310, in begin > > > self.emptyTransaction = not self._miniyum.buildTransaction() > > > File "/usr/share/ovirt-engine/scripts/miniyum.py", line 761, in > > > buildTransaction > > > raise yum.Errors.YumBaseError(msg) > > > YumBaseError: [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires > > > ovirt-engine = 3.3.0-14.fc17'] > > > > > > Realizing things were now hosed: > > > [root at ovirtfoo /]# yum erase ovirt-* otopi-* > > > Loaded plugins: langpacks, presto, refresh-packagekit, versionlock > > > Resolving Dependencies > > > --> Running transaction check > > > ---> Package otopi.noarch 0:3.3.0-15.fc17 will be erased > > > ---> Package otopi-java.noarch 0:3.3.0-15.fc17 will be erased > > > ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 will be erased > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-14.fc17 will be erased > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be erased > > > ---> Package ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 will be erased > > > ---> Package ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 will be erased > > > ---> Package ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 will be erased > > > ---> Package ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 will be erased > > > ---> Package ovirt-engine-setup.noarch 0:3.3.0-15.fc17 will be erased > > > ---> Package ovirt-engine-tools.noarch 0:3.3.0-14.fc17 will be erased > > > ---> Package ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 will be > > erased > > > ---> Package ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 will be > > > erased > > > ---> Package ovirt-host-deploy.noarch 0:3.3.0-15.fc17 will be erased > > > ---> Package ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 will be erased > > > ---> Package ovirt-image-uploader.noarch 0:3.3.0-15.fc17 will be erased > > > ---> Package ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 will be erased > > > ---> Package ovirt-log-collector.noarch 0:3.3.0-15.fc17 will be erased > > > --> Finished Dependency Resolution > > > > > > Dependencies Resolved > > > > > > > > ================================================================================ > > > Package Arch Version Repository Size > > > > > ================================================================================ > > > Removing: > > > otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k > > > otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k > > > ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine 1.3 M > > > ovirt-engine-backend noarch 3.3.0-14.fc17 @ovirt-engine 20 M > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > > ovirt-engine-cli noarch 3.3.0.1-15.fc17 @ovirt-engine 557 k > > > ovirt-engine-dbscripts noarch 3.3.0-14.fc17 @ovirt-engine 816 k > > > ovirt-engine-restapi noarch 3.3.0-14.fc17 @ovirt-engine 1.0 M > > > ovirt-engine-sdk noarch 3.3.0.1-15.fc17 @ovirt-engine 3.1 M > > > ovirt-engine-setup noarch 3.3.0-15.fc17 @ovirt-engine 653 k > > > ovirt-engine-tools noarch 3.3.0-14.fc17 @ovirt-engine 178 k > > > ovirt-engine-userportal noarch 3.3.0-14.fc17 @ovirt-engine 23 M > > > ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 @ovirt-engine 32 M > > > ovirt-host-deploy noarch 3.3.0-15.fc17 @ovirt-engine 211 k > > > ovirt-host-deploy-java noarch 3.3.0-15.fc17 @ovirt-engine 11 k > > > ovirt-image-uploader noarch 3.3.0-15.fc17 @ovirt-engine 923 k > > > ovirt-iso-uploader noarch 3.3.0-15.fc17 @ovirt-engine 98 k > > > ovirt-log-collector noarch 3.3.0-15.fc17 @ovirt-engine 133 k > > > > > > Transaction Summary > > > > > ================================================================================ > > > Remove 18 Packages > > > > > > Installed size: 104 M > > > Is this ok [y/N]: y > > > Downloading Packages: > > > Running Transaction Check > > > Running Transaction Test > > > Transaction Test Succeeded > > > Running Transaction > > > Erasing : ovirt-engine-backend.noarch 1/18 > > > Erasing : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 2/18 > > > Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch 3/18 > > > Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch 4/18 > > > Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch 5/18 > > > Erasing : ovirt-engine-userportal-3.3.0-14.fc17.noarch 6/18 > > > Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 > > > warning: /etc/ovirt-engine/engine.conf saved as > > > /etc/ovirt-engine/engine.conf.rpmsave > > > Erasing : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 8/18 > > > Erasing : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 9/18 > > > Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 > > > Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch 11/18 > > > Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > warning: /etc/ovirt-engine/imageuploader.conf saved as > > > /etc/ovirt-engine/imageuploader.conf.rpmsave > > > Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > warning: /etc/ovirt-engine/isouploader.conf saved as > > > /etc/ovirt-engine/isouploader.conf.rpmsave > > > Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch 14/18 > > > warning: /etc/ovirt-engine/logcollector.conf saved as > > > /etc/ovirt-engine/logcollector.conf.rpmsave > > > Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 15/18 > > > Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 16/18 > > > Erasing : otopi-3.3.0-15.fc17.noarch 17/18 > > > Error in PREUN scriptlet in rpm package ovirt-engine-backend > > > /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet > > failed, > > > exit status 1 > > > Verifying : otopi-3.3.0-15.fc17.noarch 1/18 > > > Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 > > > Verifying : ovirt-log-collector-3.3.0-15.fc17.noarch 3/18 > > > Verifying : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 4/18 > > > Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch 5/18 > > > Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch 6/18 > > > Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch 7/18 > > > Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 8/18 > > > Verifying : ovirt-engine-restapi-3.3.0-14.fc17.noarch 9/18 > > > Verifying : ovirt-engine-userportal-3.3.0-14.fc17.noarch 10/18 > > > Verifying : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 11/18 > > > Verifying : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 14/18 > > > ovirt-engine-backend-3.3.0-15.fc17.noarch was supposed to be removed but > > is > > > not! > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 15/18 > > > Verifying : ovirt-engine-backend-3.3.0-14.fc17.noarch 16/18 > > > Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 > > > Verifying : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 18/18 > > > > > > Removed: > > > otopi.noarch 0:3.3.0-15.fc17 > > > otopi-java.noarch 0:3.3.0-15.fc17 > > > ovirt-engine.noarch 0:3.3.0-14.fc17 > > > ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > > > ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > > > ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > > > ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > > > ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > > > ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > > > ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > > > ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > > > ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > > ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > > > ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > > > ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > > > ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > > > ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > > > Failed: > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > Complete! > > > [root at ovirtfoo /]# rpm -qa | grep oto > > > protobuf-java-2.4.1-12.fc17.x86_64 > > > libgphoto2-2.4.14-1.fc17.x86_64 > > > [root at ovirtfoo /]# rpm -qa | grep ovirt > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > [root at ovirtfoo /]# yum erase ovirt-engine-backend-3.3.0-15.fc17.noarch > > > Loaded plugins: langpacks, presto, refresh-packagekit, versionlock > > > Resolving Dependencies > > > --> Running transaction check > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be erased > > > --> Finished Dependency Resolution > > > > > > Dependencies Resolved > > > > > > > > ================================================================================ > > > Package Arch Version Repository Size > > > > > ================================================================================ > > > Removing: > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > > > > > Transaction Summary > > > > > ================================================================================ > > > Remove 1 Package > > > > > > Installed size: 20 M > > > Is this ok [y/N]: y > > > Downloading Packages: > > > Running Transaction Check > > > Running Transaction Test > > > Transaction Test Succeeded > > > Running Transaction > > > Error in PREUN scriptlet in rpm package > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet > > failed, > > > exit status 1 > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 1/1 > > > > > > Failed: > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > Complete! > > > > > > - DHC > > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > From lhornyak at redhat.com Thu Apr 11 07:56:32 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Thu, 11 Apr 2013 03:56:32 -0400 (EDT) Subject: [Engine-devel] watchdog In-Reply-To: <5165BFA7.3080207@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> <5165BFA7.3080207@redhat.com> Message-ID: <1790221293.1779512.1365666992909.JavaMail.root@redhat.com> Hi, Isnt someone already working on removing the UI distinction between server and desktop? However the desktop/server distinction could be useful for scheduling information, I hope that will remain. ----- Original Message ----- > From: "Itamar Heim" > To: "Laszlo Hornyak" > Cc: "engine-devel" , "Andrew Cathrow" > Sent: Wednesday, April 10, 2013 9:38:15 PM > Subject: Re: [Engine-devel] watchdog > > On 04/10/2013 04:59 PM, Laszlo Hornyak wrote: > > Hi, > > > > A new version of the watchd?g feature is available in gerrit: > > > > http://gerrit.ovirt.org/13057 - db > > http://gerrit.ovirt.org/13058 - bll > > http://gerrit.ovirt.org/13059 - frontend > > http://gerrit.ovirt.org/13060 - rest > > > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > Since the last update the patchset has gone through major changes to meet > > the new architectureal and functional requirements. > > Also because of the rewrite this is again a preview version under testing > > with some missing functionality, therefore I re-introduced the [wip] flag > > on it. > > > > Thx, > > Laszlo > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > just a thought after looking at the feature page having different HA > dialog for server/desktop - I'd consider removing the distinction > between desktop and server in the GUI wrt HA (i.e., just both have same > set of options) > > (not blocking for this patch) > > From tjelinek at redhat.com Thu Apr 11 08:02:16 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Thu, 11 Apr 2013 04:02:16 -0400 (EDT) Subject: [Engine-devel] watchdog In-Reply-To: <1790221293.1779512.1365666992909.JavaMail.root@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> <5165BFA7.3080207@redhat.com> <1790221293.1779512.1365666992909.JavaMail.root@redhat.com> Message-ID: <299275108.2356406.1365667336012.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Laszlo Hornyak" > To: "Itamar Heim" > Cc: "engine-devel" > Sent: Thursday, April 11, 2013 9:56:32 AM > Subject: Re: [Engine-devel] watchdog > > Hi, > > Isnt someone already working on removing the UI distinction between server > and desktop? Indeed :) > > However the desktop/server distinction could be useful for scheduling > information, I hope that will remain. There will be a combo box: "optimized for server/desktop". That one will set up the dialog like you would open the new server/desktop today. But you will be able to change them - it will be just some sugar. But there is no reason why would we enforce the disabling the e.g. soundcard for server. By default we will, but you can enable it if you want. > > ----- Original Message ----- > > From: "Itamar Heim" > > To: "Laszlo Hornyak" > > Cc: "engine-devel" , "Andrew Cathrow" > > > > Sent: Wednesday, April 10, 2013 9:38:15 PM > > Subject: Re: [Engine-devel] watchdog > > > > On 04/10/2013 04:59 PM, Laszlo Hornyak wrote: > > > Hi, > > > > > > A new version of the watchd?g feature is available in gerrit: > > > > > > http://gerrit.ovirt.org/13057 - db > > > http://gerrit.ovirt.org/13058 - bll > > > http://gerrit.ovirt.org/13059 - frontend > > > http://gerrit.ovirt.org/13060 - rest > > > > > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > > > Since the last update the patchset has gone through major changes to meet > > > the new architectureal and functional requirements. > > > Also because of the rewrite this is again a preview version under testing > > > with some missing functionality, therefore I re-introduced the [wip] flag > > > on it. > > > > > > Thx, > > > Laszlo > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > just a thought after looking at the feature page having different HA > > dialog for server/desktop - I'd consider removing the distinction > > between desktop and server in the GUI wrt HA (i.e., just both have same > > set of options) > > > > (not blocking for this patch) > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From lhornyak at redhat.com Thu Apr 11 08:25:28 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Thu, 11 Apr 2013 04:25:28 -0400 (EDT) Subject: [Engine-devel] watchdog In-Reply-To: <299275108.2356406.1365667336012.JavaMail.root@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> <5165BFA7.3080207@redhat.com> <1790221293.1779512.1365666992909.JavaMail.root@redhat.com> <299275108.2356406.1365667336012.JavaMail.root@redhat.com> Message-ID: <759897534.1785751.1365668728185.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Tomas Jelinek" > To: "Laszlo Hornyak" > Cc: "engine-devel" > Sent: Thursday, April 11, 2013 10:02:16 AM > Subject: Re: [Engine-devel] watchdog > > > > ----- Original Message ----- > > From: "Laszlo Hornyak" > > To: "Itamar Heim" > > Cc: "engine-devel" > > Sent: Thursday, April 11, 2013 9:56:32 AM > > Subject: Re: [Engine-devel] watchdog > > > > Hi, > > > > Isnt someone already working on removing the UI distinction between server > > and desktop? > Indeed :) > > > > > However the desktop/server distinction could be useful for scheduling > > information, I hope that will remain. > There will be a combo box: "optimized for server/desktop". That one > will set up the dialog like you would open the new server/desktop today. > But you will be able to change them - it will be just some sugar. But there > is no reason > why would we enforce the disabling the e.g. soundcard for server. By default > we will, but > you can enable it if you want. Ok, so in engine we will still have the VmType in vmStatic? I think it would make sense to use it in scheduling / load balancing - if a VM is a desktop and no user is connected to the console, then the VM is not in use, therefore it is a good candidate for saving power (hibernate, migrate, shutdown, or any other bad things that can happen to a VM) - if a VM is a server, usually no user connected, but it may still be used through its network. Therefore it may not be a good candidate to migrate. > > > > > ----- Original Message ----- > > > From: "Itamar Heim" > > > To: "Laszlo Hornyak" > > > Cc: "engine-devel" , "Andrew Cathrow" > > > > > > Sent: Wednesday, April 10, 2013 9:38:15 PM > > > Subject: Re: [Engine-devel] watchdog > > > > > > On 04/10/2013 04:59 PM, Laszlo Hornyak wrote: > > > > Hi, > > > > > > > > A new version of the watchd?g feature is available in gerrit: > > > > > > > > http://gerrit.ovirt.org/13057 - db > > > > http://gerrit.ovirt.org/13058 - bll > > > > http://gerrit.ovirt.org/13059 - frontend > > > > http://gerrit.ovirt.org/13060 - rest > > > > > > > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > > > > > Since the last update the patchset has gone through major changes to > > > > meet > > > > the new architectureal and functional requirements. > > > > Also because of the rewrite this is again a preview version under > > > > testing > > > > with some missing functionality, therefore I re-introduced the [wip] > > > > flag > > > > on it. > > > > > > > > Thx, > > > > Laszlo > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > just a thought after looking at the feature page having different HA > > > dialog for server/desktop - I'd consider removing the distinction > > > between desktop and server in the GUI wrt HA (i.e., just both have same > > > set of options) > > > > > > (not blocking for this patch) > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From tjelinek at redhat.com Thu Apr 11 08:33:19 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Thu, 11 Apr 2013 04:33:19 -0400 (EDT) Subject: [Engine-devel] watchdog In-Reply-To: <759897534.1785751.1365668728185.JavaMail.root@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> <5165BFA7.3080207@redhat.com> <1790221293.1779512.1365666992909.JavaMail.root@redhat.com> <299275108.2356406.1365667336012.JavaMail.root@redhat.com> <759897534.1785751.1365668728185.JavaMail.root@redhat.com> Message-ID: <686366765.2372459.1365669199294.JavaMail.root@redhat.com> Good that you have come up with this! So we will make sure to keep this info. Thnx for coming up with it! ----- Original Message ----- > From: "Laszlo Hornyak" > To: "Tomas Jelinek" > Cc: "engine-devel" > Sent: Thursday, April 11, 2013 10:25:28 AM > Subject: Re: [Engine-devel] watchdog > > > > ----- Original Message ----- > > From: "Tomas Jelinek" > > To: "Laszlo Hornyak" > > Cc: "engine-devel" > > Sent: Thursday, April 11, 2013 10:02:16 AM > > Subject: Re: [Engine-devel] watchdog > > > > > > > > ----- Original Message ----- > > > From: "Laszlo Hornyak" > > > To: "Itamar Heim" > > > Cc: "engine-devel" > > > Sent: Thursday, April 11, 2013 9:56:32 AM > > > Subject: Re: [Engine-devel] watchdog > > > > > > Hi, > > > > > > Isnt someone already working on removing the UI distinction between > > > server > > > and desktop? > > Indeed :) > > > > > > > > However the desktop/server distinction could be useful for scheduling > > > information, I hope that will remain. > > There will be a combo box: "optimized for server/desktop". That one > > will set up the dialog like you would open the new server/desktop today. > > But you will be able to change them - it will be just some sugar. But there > > is no reason > > why would we enforce the disabling the e.g. soundcard for server. By > > default > > we will, but > > you can enable it if you want. > > Ok, so in engine we will still have the VmType in vmStatic? > > I think it would make sense to use it in scheduling / load balancing > - if a VM is a desktop and no user is connected to the console, then the VM > is not in use, therefore it is a good candidate for saving power (hibernate, > migrate, shutdown, or any other bad things that can happen to a VM) > - if a VM is a server, usually no user connected, but it may still be used > through its network. Therefore it may not be a good candidate to migrate. > > > > > > > > > ----- Original Message ----- > > > > From: "Itamar Heim" > > > > To: "Laszlo Hornyak" > > > > Cc: "engine-devel" , "Andrew Cathrow" > > > > > > > > Sent: Wednesday, April 10, 2013 9:38:15 PM > > > > Subject: Re: [Engine-devel] watchdog > > > > > > > > On 04/10/2013 04:59 PM, Laszlo Hornyak wrote: > > > > > Hi, > > > > > > > > > > A new version of the watchd?g feature is available in gerrit: > > > > > > > > > > http://gerrit.ovirt.org/13057 - db > > > > > http://gerrit.ovirt.org/13058 - bll > > > > > http://gerrit.ovirt.org/13059 - frontend > > > > > http://gerrit.ovirt.org/13060 - rest > > > > > > > > > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > > > > > > > Since the last update the patchset has gone through major changes to > > > > > meet > > > > > the new architectureal and functional requirements. > > > > > Also because of the rewrite this is again a preview version under > > > > > testing > > > > > with some missing functionality, therefore I re-introduced the [wip] > > > > > flag > > > > > on it. > > > > > > > > > > Thx, > > > > > Laszlo > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > just a thought after looking at the feature page having different HA > > > > dialog for server/desktop - I'd consider removing the distinction > > > > between desktop and server in the GUI wrt HA (i.e., just both have same > > > > set of options) > > > > > > > > (not blocking for this patch) > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > From yzaslavs at redhat.com Thu Apr 11 10:26:35 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 11 Apr 2013 06:26:35 -0400 (EDT) Subject: [Engine-devel] watchdog In-Reply-To: <686366765.2372459.1365669199294.JavaMail.root@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> <5165BFA7.3080207@redhat.com> <1790221293.1779512.1365666992909.JavaMail.root@redhat.com> <299275108.2356406.1365667336012.JavaMail.root@redhat.com> <759897534.1785751.1365668728185.JavaMail.root@redhat.com> <686366765.2372459.1365669199294.JavaMail.root@redhat.com> Message-ID: <391456942.2269630.1365675995321.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Tomas Jelinek" > To: "Laszlo Hornyak" > Cc: "engine-devel" > Sent: Thursday, April 11, 2013 11:33:19 AM > Subject: Re: [Engine-devel] watchdog > > Good that you have come up with this! So we will make sure to keep this info. > Thnx for coming up with it! > > ----- Original Message ----- > > From: "Laszlo Hornyak" > > To: "Tomas Jelinek" > > Cc: "engine-devel" > > Sent: Thursday, April 11, 2013 10:25:28 AM > > Subject: Re: [Engine-devel] watchdog > > > > > > > > ----- Original Message ----- > > > From: "Tomas Jelinek" > > > To: "Laszlo Hornyak" > > > Cc: "engine-devel" > > > Sent: Thursday, April 11, 2013 10:02:16 AM > > > Subject: Re: [Engine-devel] watchdog > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Laszlo Hornyak" > > > > To: "Itamar Heim" > > > > Cc: "engine-devel" > > > > Sent: Thursday, April 11, 2013 9:56:32 AM > > > > Subject: Re: [Engine-devel] watchdog > > > > > > > > Hi, > > > > > > > > Isnt someone already working on removing the UI distinction between > > > > server > > > > and desktop? > > > Indeed :) > > > > > > > > > > > However the desktop/server distinction could be useful for scheduling > > > > information, I hope that will remain. > > > There will be a combo box: "optimized for server/desktop". That one > > > will set up the dialog like you would open the new server/desktop today. > > > But you will be able to change them - it will be just some sugar. But > > > there > > > is no reason > > > why would we enforce the disabling the e.g. soundcard for server. By > > > default > > > we will, but > > > you can enable it if you want. > > > > Ok, so in engine we will still have the VmType in vmStatic? > > > > I think it would make sense to use it in scheduling / load balancing > > - if a VM is a desktop and no user is connected to the console, then the VM > > is not in use, therefore it is a good candidate for saving power > > (hibernate, > > migrate, shutdown, or any other bad things that can happen to a VM) > > - if a VM is a server, usually no user connected, but it may still be used > > through its network. Therefore it may not be a good candidate to migrate. is this indeed a valid assumption ("if VM is a server..." ) that a user will less connect to it? > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Itamar Heim" > > > > > To: "Laszlo Hornyak" > > > > > Cc: "engine-devel" , "Andrew Cathrow" > > > > > > > > > > Sent: Wednesday, April 10, 2013 9:38:15 PM > > > > > Subject: Re: [Engine-devel] watchdog > > > > > > > > > > On 04/10/2013 04:59 PM, Laszlo Hornyak wrote: > > > > > > Hi, > > > > > > > > > > > > A new version of the watchd?g feature is available in gerrit: > > > > > > > > > > > > http://gerrit.ovirt.org/13057 - db > > > > > > http://gerrit.ovirt.org/13058 - bll > > > > > > http://gerrit.ovirt.org/13059 - frontend > > > > > > http://gerrit.ovirt.org/13060 - rest > > > > > > > > > > > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > > > > > > > > > Since the last update the patchset has gone through major changes > > > > > > to > > > > > > meet > > > > > > the new architectureal and functional requirements. > > > > > > Also because of the rewrite this is again a preview version under > > > > > > testing > > > > > > with some missing functionality, therefore I re-introduced the > > > > > > [wip] > > > > > > flag > > > > > > on it. > > > > > > > > > > > > Thx, > > > > > > Laszlo > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > just a thought after looking at the feature page having different HA > > > > > dialog for server/desktop - I'd consider removing the distinction > > > > > between desktop and server in the GUI wrt HA (i.e., just both have > > > > > same > > > > > set of options) > > > > > > > > > > (not blocking for this patch) > > > > > > > > > > > > > > _______________________________________________ > > > > 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 Thu Apr 11 10:57:04 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Thu, 11 Apr 2013 06:57:04 -0400 (EDT) Subject: [Engine-devel] watchdog In-Reply-To: <391456942.2269630.1365675995321.JavaMail.root@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> <5165BFA7.3080207@redhat.com> <1790221293.1779512.1365666992909.JavaMail.root@redhat.com> <299275108.2356406.1365667336012.JavaMail.root@redhat.com> <759897534.1785751.1365668728185.JavaMail.root@redhat.com> <686366765.2372459.1365669199294.JavaMail.root@redhat.com> <391456942.2269630.1365675995321.JavaMail.root@redhat.com> Message-ID: <814758847.1807578.1365677824715.JavaMail.root@redhat.com> No what I meant is that if the VM is a server { not having a console connection to it does not mean that it is not used. } Therefore desktops on the same host with no console connection, they may be better candidates for migration. You can connect to servers. ----- Original Message ----- > From: "Yair Zaslavsky" > To: "Tomas Jelinek" > Cc: "Laszlo Hornyak" , "engine-devel" > Sent: Thursday, April 11, 2013 12:26:35 PM > Subject: Re: [Engine-devel] watchdog > > > > ----- Original Message ----- > > From: "Tomas Jelinek" > > To: "Laszlo Hornyak" > > Cc: "engine-devel" > > Sent: Thursday, April 11, 2013 11:33:19 AM > > Subject: Re: [Engine-devel] watchdog > > > > Good that you have come up with this! So we will make sure to keep this > > info. > > Thnx for coming up with it! > > > > ----- Original Message ----- > > > From: "Laszlo Hornyak" > > > To: "Tomas Jelinek" > > > Cc: "engine-devel" > > > Sent: Thursday, April 11, 2013 10:25:28 AM > > > Subject: Re: [Engine-devel] watchdog > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Tomas Jelinek" > > > > To: "Laszlo Hornyak" > > > > Cc: "engine-devel" > > > > Sent: Thursday, April 11, 2013 10:02:16 AM > > > > Subject: Re: [Engine-devel] watchdog > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Laszlo Hornyak" > > > > > To: "Itamar Heim" > > > > > Cc: "engine-devel" > > > > > Sent: Thursday, April 11, 2013 9:56:32 AM > > > > > Subject: Re: [Engine-devel] watchdog > > > > > > > > > > Hi, > > > > > > > > > > Isnt someone already working on removing the UI distinction between > > > > > server > > > > > and desktop? > > > > Indeed :) > > > > > > > > > > > > > > However the desktop/server distinction could be useful for scheduling > > > > > information, I hope that will remain. > > > > There will be a combo box: "optimized for server/desktop". That one > > > > will set up the dialog like you would open the new server/desktop > > > > today. > > > > But you will be able to change them - it will be just some sugar. But > > > > there > > > > is no reason > > > > why would we enforce the disabling the e.g. soundcard for server. By > > > > default > > > > we will, but > > > > you can enable it if you want. > > > > > > Ok, so in engine we will still have the VmType in vmStatic? > > > > > > I think it would make sense to use it in scheduling / load balancing > > > - if a VM is a desktop and no user is connected to the console, then the > > > VM > > > is not in use, therefore it is a good candidate for saving power > > > (hibernate, > > > migrate, shutdown, or any other bad things that can happen to a VM) > > > - if a VM is a server, usually no user connected, but it may still be > > > used > > > through its network. Therefore it may not be a good candidate to migrate. > > is this indeed a valid assumption ("if VM is a server..." ) that a user will > less connect to it? > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Itamar Heim" > > > > > > To: "Laszlo Hornyak" > > > > > > Cc: "engine-devel" , "Andrew Cathrow" > > > > > > > > > > > > Sent: Wednesday, April 10, 2013 9:38:15 PM > > > > > > Subject: Re: [Engine-devel] watchdog > > > > > > > > > > > > On 04/10/2013 04:59 PM, Laszlo Hornyak wrote: > > > > > > > Hi, > > > > > > > > > > > > > > A new version of the watchd?g feature is available in gerrit: > > > > > > > > > > > > > > http://gerrit.ovirt.org/13057 - db > > > > > > > http://gerrit.ovirt.org/13058 - bll > > > > > > > http://gerrit.ovirt.org/13059 - frontend > > > > > > > http://gerrit.ovirt.org/13060 - rest > > > > > > > > > > > > > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > > > > > > > > > > > Since the last update the patchset has gone through major changes > > > > > > > to > > > > > > > meet > > > > > > > the new architectureal and functional requirements. > > > > > > > Also because of the rewrite this is again a preview version under > > > > > > > testing > > > > > > > with some missing functionality, therefore I re-introduced the > > > > > > > [wip] > > > > > > > flag > > > > > > > on it. > > > > > > > > > > > > > > Thx, > > > > > > > Laszlo > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > just a thought after looking at the feature page having different > > > > > > HA > > > > > > dialog for server/desktop - I'd consider removing the distinction > > > > > > between desktop and server in the GUI wrt HA (i.e., just both have > > > > > > same > > > > > > set of options) > > > > > > > > > > > > (not blocking for this patch) > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 Thu Apr 11 11:11:23 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 11 Apr 2013 07:11:23 -0400 (EDT) Subject: [Engine-devel] watchdog In-Reply-To: <814758847.1807578.1365677824715.JavaMail.root@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> <5165BFA7.3080207@redhat.com> <1790221293.1779512.1365666992909.JavaMail.root@redhat.com> <299275108.2356406.1365667336012.JavaMail.root@redhat.com> <759897534.1785751.1365668728185.JavaMail.root@redhat.com> <686366765.2372459.1365669199294.JavaMail.root@redhat.com> <391456942.2269630.1365675995321.JavaMail.root@redhat.com> <814758847.1807578.1365677824715.JavaMail.root@redhat.com> Message-ID: <564225307.2292500.1365678683631.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Laszlo Hornyak" > To: "Yair Zaslavsky" > Cc: "Tomas Jelinek" , "engine-devel" > Sent: Thursday, April 11, 2013 1:57:04 PM > Subject: Re: [Engine-devel] watchdog > > No what I meant is that > if the VM is a server { > not having a console connection to it does not mean that it is not used. Used is a more general term than "someone is connected to" - for example, you may have a machine running some internal calculation which takes a considerable amount of time, and you may have a user that performs ssh to that machine (let's say once in an hour) and runs some utility that reports the status of the calculation. > } > > Therefore desktops on the same host with no console connection, they may be > better candidates for migration. You can connect to servers. > > ----- Original Message ----- > > From: "Yair Zaslavsky" > > To: "Tomas Jelinek" > > Cc: "Laszlo Hornyak" , "engine-devel" > > > > Sent: Thursday, April 11, 2013 12:26:35 PM > > Subject: Re: [Engine-devel] watchdog > > > > > > > > ----- Original Message ----- > > > From: "Tomas Jelinek" > > > To: "Laszlo Hornyak" > > > Cc: "engine-devel" > > > Sent: Thursday, April 11, 2013 11:33:19 AM > > > Subject: Re: [Engine-devel] watchdog > > > > > > Good that you have come up with this! So we will make sure to keep this > > > info. > > > Thnx for coming up with it! > > > > > > ----- Original Message ----- > > > > From: "Laszlo Hornyak" > > > > To: "Tomas Jelinek" > > > > Cc: "engine-devel" > > > > Sent: Thursday, April 11, 2013 10:25:28 AM > > > > Subject: Re: [Engine-devel] watchdog > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Tomas Jelinek" > > > > > To: "Laszlo Hornyak" > > > > > Cc: "engine-devel" > > > > > Sent: Thursday, April 11, 2013 10:02:16 AM > > > > > Subject: Re: [Engine-devel] watchdog > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Laszlo Hornyak" > > > > > > To: "Itamar Heim" > > > > > > Cc: "engine-devel" > > > > > > Sent: Thursday, April 11, 2013 9:56:32 AM > > > > > > Subject: Re: [Engine-devel] watchdog > > > > > > > > > > > > Hi, > > > > > > > > > > > > Isnt someone already working on removing the UI distinction between > > > > > > server > > > > > > and desktop? > > > > > Indeed :) > > > > > > > > > > > > > > > > > However the desktop/server distinction could be useful for > > > > > > scheduling > > > > > > information, I hope that will remain. > > > > > There will be a combo box: "optimized for server/desktop". That one > > > > > will set up the dialog like you would open the new server/desktop > > > > > today. > > > > > But you will be able to change them - it will be just some sugar. But > > > > > there > > > > > is no reason > > > > > why would we enforce the disabling the e.g. soundcard for server. By > > > > > default > > > > > we will, but > > > > > you can enable it if you want. > > > > > > > > Ok, so in engine we will still have the VmType in vmStatic? > > > > > > > > I think it would make sense to use it in scheduling / load balancing > > > > - if a VM is a desktop and no user is connected to the console, then > > > > the > > > > VM > > > > is not in use, therefore it is a good candidate for saving power > > > > (hibernate, > > > > migrate, shutdown, or any other bad things that can happen to a VM) > > > > - if a VM is a server, usually no user connected, but it may still be > > > > used > > > > through its network. Therefore it may not be a good candidate to > > > > migrate. > > > > is this indeed a valid assumption ("if VM is a server..." ) that a user > > will > > less connect to it? > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Itamar Heim" > > > > > > > To: "Laszlo Hornyak" > > > > > > > Cc: "engine-devel" , "Andrew Cathrow" > > > > > > > > > > > > > > Sent: Wednesday, April 10, 2013 9:38:15 PM > > > > > > > Subject: Re: [Engine-devel] watchdog > > > > > > > > > > > > > > On 04/10/2013 04:59 PM, Laszlo Hornyak wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > A new version of the watchd?g feature is available in gerrit: > > > > > > > > > > > > > > > > http://gerrit.ovirt.org/13057 - db > > > > > > > > http://gerrit.ovirt.org/13058 - bll > > > > > > > > http://gerrit.ovirt.org/13059 - frontend > > > > > > > > http://gerrit.ovirt.org/13060 - rest > > > > > > > > > > > > > > > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > > > > > > > > > > > > > Since the last update the patchset has gone through major > > > > > > > > changes > > > > > > > > to > > > > > > > > meet > > > > > > > > the new architectureal and functional requirements. > > > > > > > > Also because of the rewrite this is again a preview version > > > > > > > > under > > > > > > > > testing > > > > > > > > with some missing functionality, therefore I re-introduced the > > > > > > > > [wip] > > > > > > > > flag > > > > > > > > on it. > > > > > > > > > > > > > > > > Thx, > > > > > > > > Laszlo > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel at ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > just a thought after looking at the feature page having different > > > > > > > HA > > > > > > > dialog for server/desktop - I'd consider removing the distinction > > > > > > > between desktop and server in the GUI wrt HA (i.e., just both > > > > > > > have > > > > > > > same > > > > > > > set of options) > > > > > > > > > > > > > > (not blocking for this patch) > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 Thu Apr 11 11:10:04 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 11 Apr 2013 14:10:04 +0300 Subject: [Engine-devel] watchdog In-Reply-To: <814758847.1807578.1365677824715.JavaMail.root@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> <5165BFA7.3080207@redhat.com> <1790221293.1779512.1365666992909.JavaMail.root@redhat.com> <299275108.2356406.1365667336012.JavaMail.root@redhat.com> <759897534.1785751.1365668728185.JavaMail.root@redhat.com> <686366765.2372459.1365669199294.JavaMail.root@redhat.com> <391456942.2269630.1365675995321.JavaMail.root@redhat.com> <814758847.1807578.1365677824715.JavaMail.root@redhat.com> Message-ID: <51669A0C.5000009@redhat.com> On 04/11/2013 01:57 PM, Laszlo Hornyak wrote: > No what I meant is that > if the VM is a server { > not having a console connection to it does not mean that it is not used. > } > > Therefore desktops on the same host with no console connection, they may be better candidates for migration. You can connect to servers. I'd actually like to lose the distinction between server and desktop other than a set of optimizations. i.e., if there is an optimization you want to make based on console being connected, model that and ask for that specifically (maybe I use desktop differently than you think) > > ----- Original Message ----- >> From: "Yair Zaslavsky" >> To: "Tomas Jelinek" >> Cc: "Laszlo Hornyak" , "engine-devel" >> Sent: Thursday, April 11, 2013 12:26:35 PM >> Subject: Re: [Engine-devel] watchdog >> >> >> >> ----- Original Message ----- >>> From: "Tomas Jelinek" >>> To: "Laszlo Hornyak" >>> Cc: "engine-devel" >>> Sent: Thursday, April 11, 2013 11:33:19 AM >>> Subject: Re: [Engine-devel] watchdog >>> >>> Good that you have come up with this! So we will make sure to keep this >>> info. >>> Thnx for coming up with it! >>> >>> ----- Original Message ----- >>>> From: "Laszlo Hornyak" >>>> To: "Tomas Jelinek" >>>> Cc: "engine-devel" >>>> Sent: Thursday, April 11, 2013 10:25:28 AM >>>> Subject: Re: [Engine-devel] watchdog >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Tomas Jelinek" >>>>> To: "Laszlo Hornyak" >>>>> Cc: "engine-devel" >>>>> Sent: Thursday, April 11, 2013 10:02:16 AM >>>>> Subject: Re: [Engine-devel] watchdog >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Laszlo Hornyak" >>>>>> To: "Itamar Heim" >>>>>> Cc: "engine-devel" >>>>>> Sent: Thursday, April 11, 2013 9:56:32 AM >>>>>> Subject: Re: [Engine-devel] watchdog >>>>>> >>>>>> Hi, >>>>>> >>>>>> Isnt someone already working on removing the UI distinction between >>>>>> server >>>>>> and desktop? >>>>> Indeed :) >>>>> >>>>>> >>>>>> However the desktop/server distinction could be useful for scheduling >>>>>> information, I hope that will remain. >>>>> There will be a combo box: "optimized for server/desktop". That one >>>>> will set up the dialog like you would open the new server/desktop >>>>> today. >>>>> But you will be able to change them - it will be just some sugar. But >>>>> there >>>>> is no reason >>>>> why would we enforce the disabling the e.g. soundcard for server. By >>>>> default >>>>> we will, but >>>>> you can enable it if you want. >>>> >>>> Ok, so in engine we will still have the VmType in vmStatic? >>>> >>>> I think it would make sense to use it in scheduling / load balancing >>>> - if a VM is a desktop and no user is connected to the console, then the >>>> VM >>>> is not in use, therefore it is a good candidate for saving power >>>> (hibernate, >>>> migrate, shutdown, or any other bad things that can happen to a VM) >>>> - if a VM is a server, usually no user connected, but it may still be >>>> used >>>> through its network. Therefore it may not be a good candidate to migrate. >> >> is this indeed a valid assumption ("if VM is a server..." ) that a user will >> less connect to it? >> >> >>>> >>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Itamar Heim" >>>>>>> To: "Laszlo Hornyak" >>>>>>> Cc: "engine-devel" , "Andrew Cathrow" >>>>>>> >>>>>>> Sent: Wednesday, April 10, 2013 9:38:15 PM >>>>>>> Subject: Re: [Engine-devel] watchdog >>>>>>> >>>>>>> On 04/10/2013 04:59 PM, Laszlo Hornyak wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> A new version of the watchd?g feature is available in gerrit: >>>>>>>> >>>>>>>> http://gerrit.ovirt.org/13057 - db >>>>>>>> http://gerrit.ovirt.org/13058 - bll >>>>>>>> http://gerrit.ovirt.org/13059 - frontend >>>>>>>> http://gerrit.ovirt.org/13060 - rest >>>>>>>> >>>>>>>> http://www.ovirt.org/Features/Watchdog_engine_support >>>>>>>> >>>>>>>> Since the last update the patchset has gone through major changes >>>>>>>> to >>>>>>>> meet >>>>>>>> the new architectureal and functional requirements. >>>>>>>> Also because of the rewrite this is again a preview version under >>>>>>>> testing >>>>>>>> with some missing functionality, therefore I re-introduced the >>>>>>>> [wip] >>>>>>>> flag >>>>>>>> on it. >>>>>>>> >>>>>>>> Thx, >>>>>>>> Laszlo >>>>>>>> _______________________________________________ >>>>>>>> Engine-devel mailing list >>>>>>>> Engine-devel at ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>> >>>>>>> >>>>>>> just a thought after looking at the feature page having different >>>>>>> HA >>>>>>> dialog for server/desktop - I'd consider removing the distinction >>>>>>> between desktop and server in the GUI wrt HA (i.e., just both have >>>>>>> same >>>>>>> set of options) >>>>>>> >>>>>>> (not blocking for this patch) >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 danken at redhat.com Thu Apr 11 12:01:26 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Thu, 11 Apr 2013 15:01:26 +0300 Subject: [Engine-devel] [vdsm] Snapshots with RAM feature In-Reply-To: <20130410084312.GD32275@redhat.com> References: <319368954.768893.1365494496958.JavaMail.root@redhat.com> <720BEF86-8C5F-43AC-8EE2-6CCD05AD8107@redhat.com> <20130410084312.GD32275@redhat.com> Message-ID: <20130411120126.GF16563@redhat.com> On Wed, Apr 10, 2013 at 11:43:12AM +0300, Dan Kenigsberg wrote: > On Wed, Apr 10, 2013 at 02:12:20AM -0400, Michal Skrivanek wrote: > > > > > > On 9 Apr 2013, at 10:01, Arik Hadas wrote: > > > > > Hi All, > > > > > > The proposed feature will make it possible to run a VM which was reverted to live snapshot > > > or created from live snapshot with the same memory state as it was at the moment the live > > > snapshot was taken. > > > > > > http://www.ovirt.org/Features/RAM_Snapshots > > > > > > All feedback is welcome! > > Nice! > > (I prefer to inline the document when discussing it) > > > VDSM changes > > > > Default parameter will be added to vmSnapshot verb that maps string to string. > > The map will include two keys for now: > > 'mode' that can be mapped to 'disks_only' or 'disks_memory' to > > indicate if memory state should be saved. > > 'memVol' that will be mapped to a string that represent the two > > volums that will be used to save the memory state and the > > VM configuration. The default map will include the > > mapping of 'mode':'disks_only' only. > > > > If the 'mode' value in the map decribed above is > > 'disks_memory' the first volume in 'memVol' will be > > passed to libvirt in order to dump the memory to > > it, and the second volume in 'memVol' will be used > > to save the VM configuration (the same way it is > > done for hibernate operation). > > This definition of 'memVol' would not allow saving the state to another > storage domain, or a direct lun or whatever. > > I suggest that you have two independet arguments, say memVol and > vmConfVol. Both may have the standard pool-domain-image-volume quartet, > or a lun specification, or a local path. On a second thought - why should we even store vmConf on vmConfVol? Why not keep it in Engine's db? Sure, we do this for hibernation. But it creates a lot of inconsistency pains. Engine sends one vmconf to vdsm, but vdsm ignores it and starts the VM with an old vmconf that was stored besides the hibernation volume. On top of this, it wastes some GiB of disk space for each snapshot. I think it is time to have Engine keep a snapshot of its vm config whenever it takes a snapshot - live or offline. Dan. From lhornyak at redhat.com Thu Apr 11 12:54:16 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Thu, 11 Apr 2013 08:54:16 -0400 (EDT) Subject: [Engine-devel] watchdog In-Reply-To: <51669A0C.5000009@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> <1790221293.1779512.1365666992909.JavaMail.root@redhat.com> <299275108.2356406.1365667336012.JavaMail.root@redhat.com> <759897534.1785751.1365668728185.JavaMail.root@redhat.com> <686366765.2372459.1365669199294.JavaMail.root@redhat.com> <391456942.2269630.1365675995321.JavaMail.root@redhat.com> <814758847.1807578.1365677824715.JavaMail.root@redhat.com> <51669A0C.5000009@redhat.com> Message-ID: <194993207.1843451.1365684856859.JavaMail.root@redhat.com> Hi, It is not really an optimization based only on console connection. In my opinion this should be a decision factor when determining which VM to migrate from an overloaded host. If it is a desktop and no console connection, then it is better candidate than a desktop with console connection or a server with or without console connection. Basically this logic would just want to minimize the pain caused by the short lag when a VM is live migrated. Can I assume that a Desktop is only used when a console is connected? ----- Original Message ----- > From: "Itamar Heim" > To: "Laszlo Hornyak" > Cc: "Yair Zaslavsky" , "engine-devel" > Sent: Thursday, April 11, 2013 1:10:04 PM > Subject: Re: [Engine-devel] watchdog > > On 04/11/2013 01:57 PM, Laszlo Hornyak wrote: > > No what I meant is that > > if the VM is a server { > > not having a console connection to it does not mean that it is not used. > > } > > > > Therefore desktops on the same host with no console connection, they may be > > better candidates for migration. You can connect to servers. > > I'd actually like to lose the distinction between server and desktop > other than a set of optimizations. > i.e., if there is an optimization you want to make based on console > being connected, model that and ask for that specifically (maybe I use > desktop differently than you think) > > > > > ----- Original Message ----- > >> From: "Yair Zaslavsky" > >> To: "Tomas Jelinek" > >> Cc: "Laszlo Hornyak" , "engine-devel" > >> > >> Sent: Thursday, April 11, 2013 12:26:35 PM > >> Subject: Re: [Engine-devel] watchdog > >> > >> > >> > >> ----- Original Message ----- > >>> From: "Tomas Jelinek" > >>> To: "Laszlo Hornyak" > >>> Cc: "engine-devel" > >>> Sent: Thursday, April 11, 2013 11:33:19 AM > >>> Subject: Re: [Engine-devel] watchdog > >>> > >>> Good that you have come up with this! So we will make sure to keep this > >>> info. > >>> Thnx for coming up with it! > >>> > >>> ----- Original Message ----- > >>>> From: "Laszlo Hornyak" > >>>> To: "Tomas Jelinek" > >>>> Cc: "engine-devel" > >>>> Sent: Thursday, April 11, 2013 10:25:28 AM > >>>> Subject: Re: [Engine-devel] watchdog > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Tomas Jelinek" > >>>>> To: "Laszlo Hornyak" > >>>>> Cc: "engine-devel" > >>>>> Sent: Thursday, April 11, 2013 10:02:16 AM > >>>>> Subject: Re: [Engine-devel] watchdog > >>>>> > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Laszlo Hornyak" > >>>>>> To: "Itamar Heim" > >>>>>> Cc: "engine-devel" > >>>>>> Sent: Thursday, April 11, 2013 9:56:32 AM > >>>>>> Subject: Re: [Engine-devel] watchdog > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Isnt someone already working on removing the UI distinction between > >>>>>> server > >>>>>> and desktop? > >>>>> Indeed :) > >>>>> > >>>>>> > >>>>>> However the desktop/server distinction could be useful for scheduling > >>>>>> information, I hope that will remain. > >>>>> There will be a combo box: "optimized for server/desktop". That one > >>>>> will set up the dialog like you would open the new server/desktop > >>>>> today. > >>>>> But you will be able to change them - it will be just some sugar. But > >>>>> there > >>>>> is no reason > >>>>> why would we enforce the disabling the e.g. soundcard for server. By > >>>>> default > >>>>> we will, but > >>>>> you can enable it if you want. > >>>> > >>>> Ok, so in engine we will still have the VmType in vmStatic? > >>>> > >>>> I think it would make sense to use it in scheduling / load balancing > >>>> - if a VM is a desktop and no user is connected to the console, then the > >>>> VM > >>>> is not in use, therefore it is a good candidate for saving power > >>>> (hibernate, > >>>> migrate, shutdown, or any other bad things that can happen to a VM) > >>>> - if a VM is a server, usually no user connected, but it may still be > >>>> used > >>>> through its network. Therefore it may not be a good candidate to > >>>> migrate. > >> > >> is this indeed a valid assumption ("if VM is a server..." ) that a user > >> will > >> less connect to it? > >> > >> > >>>> > >>>>> > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Itamar Heim" > >>>>>>> To: "Laszlo Hornyak" > >>>>>>> Cc: "engine-devel" , "Andrew Cathrow" > >>>>>>> > >>>>>>> Sent: Wednesday, April 10, 2013 9:38:15 PM > >>>>>>> Subject: Re: [Engine-devel] watchdog > >>>>>>> > >>>>>>> On 04/10/2013 04:59 PM, Laszlo Hornyak wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> A new version of the watchd?g feature is available in gerrit: > >>>>>>>> > >>>>>>>> http://gerrit.ovirt.org/13057 - db > >>>>>>>> http://gerrit.ovirt.org/13058 - bll > >>>>>>>> http://gerrit.ovirt.org/13059 - frontend > >>>>>>>> http://gerrit.ovirt.org/13060 - rest > >>>>>>>> > >>>>>>>> http://www.ovirt.org/Features/Watchdog_engine_support > >>>>>>>> > >>>>>>>> Since the last update the patchset has gone through major changes > >>>>>>>> to > >>>>>>>> meet > >>>>>>>> the new architectureal and functional requirements. > >>>>>>>> Also because of the rewrite this is again a preview version under > >>>>>>>> testing > >>>>>>>> with some missing functionality, therefore I re-introduced the > >>>>>>>> [wip] > >>>>>>>> flag > >>>>>>>> on it. > >>>>>>>> > >>>>>>>> Thx, > >>>>>>>> Laszlo > >>>>>>>> _______________________________________________ > >>>>>>>> Engine-devel mailing list > >>>>>>>> Engine-devel at ovirt.org > >>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>>>>>> > >>>>>>> > >>>>>>> just a thought after looking at the feature page having different > >>>>>>> HA > >>>>>>> dialog for server/desktop - I'd consider removing the distinction > >>>>>>> between desktop and server in the GUI wrt HA (i.e., just both have > >>>>>>> same > >>>>>>> set of options) > >>>>>>> > >>>>>>> (not blocking for this patch) > >>>>>>> > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 danken at redhat.com Thu Apr 11 13:09:02 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Thu, 11 Apr 2013 16:09:02 +0300 Subject: [Engine-devel] [vdsm] ovirt-host-deploy and multible bridges In-Reply-To: <5165287A.1010003@redhat.com> References: <5163E932.8040300@redhat.com> <5163EC95.50901@redhat.com> <20130409123535.GK26069@redhat.com> <516412AC.7060907@redhat.com> <51641E79.5030506@redhat.com> <20130409185555.GD11630@redhat.com> <5164FD46.7010107@redhat.com> <51652787.8020205@redhat.com> <5165287A.1010003@redhat.com> Message-ID: <20130411130902.GK16563@redhat.com> On Wed, Apr 10, 2013 at 02:23:14PM +0530, Sahina Bose wrote: > > On 04/10/2013 02:19 PM, Balamurugan Arumugam wrote: > >On 04/10/2013 11:18 AM, Sahina Bose wrote: > >> > >>On 04/10/2013 12:25 AM, Dan Kenigsberg wrote: > >>>On Tue, Apr 09, 2013 at 07:28:17PM +0530, Balamurugan Arumugam wrote: > >>>>On 04/09/2013 06:37 PM, Sahina Bose wrote: > >>>>>Decoding "correct address" - glusterHostsList should return any > >>>>>ipAddress that engine knows as being associated with host. > >>>>>It could be either ipAddress used while adding host > >>>>>(stored as hostname > >>>>>in vds_static) or any of the ipAddresses populated in vds_interface > >>>>>table (addr column) . > >>>>>I do not have enough knowledge about this bit of code to say what > >>>>>entries are made in vds_interface table. I know there's an entry for > >>>>>ovirtmgmt here but not sure if this gets added as part of > >>>>>addHost flow > >>>>>or not. > >>>>> > >>>>I guess, vds_interface table is populated by ips given by vdsm > >>>>through getVdsCaps. > >>>> > >>>>Current glusterHostsList provides one of ipaddress of the local host > >>>>(other than 127.*.*.*). If virbr0 is enabled, it picks up > >>>>192.168.122.1 ip address of the bridge and sends to the engine, but > >>>>this entry is missing in the table. > >>>> > >>>>The requirement is that we need a ip of the local host which is also > >>>>stored in the database. > >>>> > >>>>The database has entries of ips of a host those are from physical > >>>>nics and/or bridges who has slaves to nics. > >>>It's not something I've tested, or want to encourage, but currently, > >>>outside of gluster, Vdsm may run behind a fancy NAT as a > >>>virtual server. > >>>I.e., its local undress may be utterly different from the address used > >>>by Engine. > >>> > >>>I'd like to keep having this flexibility, and not to assume otherwise. > >>> > >>>Why does glusterHostsList need to return the ip of the management > >>>network? The client that issued this verb has to know that IP in the > >>>first place. > >>> > >>>I notice that the idiom "_getLocalIpAddress() or _getGlusterHostName()" > >>>is used all too often in vdsm/gluster/cli.py. And what about these ^^^ ? Is there any reason to keep these guesses elsewhere in the code? From mskrivan at redhat.com Thu Apr 11 15:29:53 2013 From: mskrivan at redhat.com (Michal Skrivanek) Date: Thu, 11 Apr 2013 11:29:53 -0400 (EDT) Subject: [Engine-devel] watchdog In-Reply-To: <391456942.2269630.1365675995321.JavaMail.root@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> <5165BFA7.3080207@redhat.com> <1790221293.1779512.1365666992909.JavaMail.root@redhat.com> <299275108.2356406.1365667336012.JavaMail.root@redhat.com> <759897534.1785751.1365668728185.JavaMail.root@redhat.com> <686366765.2372459.1365669199294.JavaMail.root@redhat.com> <391456942.2269630.1365675995321.JavaMail.root@redhat.com> Message-ID: <63D55D17-F63F-42DE-A4D5-93C98A6F2797@redhat.com> On 11 Apr 2013, at 12:26, Yair Zaslavsky wrote: > > > ----- Original Message ----- >> From: "Tomas Jelinek" >> To: "Laszlo Hornyak" >> Cc: "engine-devel" >> Sent: Thursday, April 11, 2013 11:33:19 AM >> Subject: Re: [Engine-devel] watchdog >> >> Good that you have come up with this! So we will make sure to keep this info. >> Thnx for coming up with it! >> >> ----- Original Message ----- >>> From: "Laszlo Hornyak" >>> To: "Tomas Jelinek" >>> Cc: "engine-devel" >>> Sent: Thursday, April 11, 2013 10:25:28 AM >>> Subject: Re: [Engine-devel] watchdog >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Tomas Jelinek" >>>> To: "Laszlo Hornyak" >>>> Cc: "engine-devel" >>>> Sent: Thursday, April 11, 2013 10:02:16 AM >>>> Subject: Re: [Engine-devel] watchdog >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Laszlo Hornyak" >>>>> To: "Itamar Heim" >>>>> Cc: "engine-devel" >>>>> Sent: Thursday, April 11, 2013 9:56:32 AM >>>>> Subject: Re: [Engine-devel] watchdog >>>>> >>>>> Hi, >>>>> >>>>> Isnt someone already working on removing the UI distinction between >>>>> server >>>>> and desktop? >>>> Indeed :) >>>> >>>>> >>>>> However the desktop/server distinction could be useful for scheduling >>>>> information, I hope that will remain. >>>> There will be a combo box: "optimized for server/desktop". That one >>>> will set up the dialog like you would open the new server/desktop today. >>>> But you will be able to change them - it will be just some sugar. But >>>> there >>>> is no reason >>>> why would we enforce the disabling the e.g. soundcard for server. By >>>> default >>>> we will, but >>>> you can enable it if you want. >>> >>> Ok, so in engine we will still have the VmType in vmStatic? >>> >>> I think it would make sense to use it in scheduling / load balancing >>> - if a VM is a desktop and no user is connected to the console, then the VM >>> is not in use, therefore it is a good candidate for saving power >>> (hibernate, >>> migrate, shutdown, or any other bad things that can happen to a VM) >>> - if a VM is a server, usually no user connected, but it may still be used >>> through its network. Therefore it may not be a good candidate to migrate. > > is this indeed a valid assumption ("if VM is a server..." ) that a user will less connect to it? IMHO if we want some new behavior/policy there should be a new corresponding property, not desktop/server. That can be quite misleading and I would rather see it go away. Other than use it as a set of default values > > >>> >>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Itamar Heim" >>>>>> To: "Laszlo Hornyak" >>>>>> Cc: "engine-devel" , "Andrew Cathrow" >>>>>> >>>>>> Sent: Wednesday, April 10, 2013 9:38:15 PM >>>>>> Subject: Re: [Engine-devel] watchdog >>>>>> >>>>>> On 04/10/2013 04:59 PM, Laszlo Hornyak wrote: >>>>>>> Hi, >>>>>>> >>>>>>> A new version of the watchd?g feature is available in gerrit: >>>>>>> >>>>>>> http://gerrit.ovirt.org/13057 - db >>>>>>> http://gerrit.ovirt.org/13058 - bll >>>>>>> http://gerrit.ovirt.org/13059 - frontend >>>>>>> http://gerrit.ovirt.org/13060 - rest >>>>>>> >>>>>>> http://www.ovirt.org/Features/Watchdog_engine_support >>>>>>> >>>>>>> Since the last update the patchset has gone through major changes >>>>>>> to >>>>>>> meet >>>>>>> the new architectureal and functional requirements. >>>>>>> Also because of the rewrite this is again a preview version under >>>>>>> testing >>>>>>> with some missing functionality, therefore I re-introduced the >>>>>>> [wip] >>>>>>> flag >>>>>>> on it. >>>>>>> >>>>>>> Thx, >>>>>>> Laszlo >>>>>>> _______________________________________________ >>>>>>> Engine-devel mailing list >>>>>>> Engine-devel at ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>> >>>>>> just a thought after looking at the feature page having different HA >>>>>> dialog for server/desktop - I'd consider removing the distinction >>>>>> between desktop and server in the GUI wrt HA (i.e., just both have >>>>>> same >>>>>> set of options) >>>>>> >>>>>> (not blocking for this patch) >>>>> _______________________________________________ >>>>> 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 deadhorseconsulting at gmail.com Thu Apr 11 21:28:01 2013 From: deadhorseconsulting at gmail.com (Dead Horse) Date: Thu, 11 Apr 2013 16:28:01 -0500 Subject: [Engine-devel] upgrade failing with latest master In-Reply-To: <269004897.1042115.1365627763231.JavaMail.root@redhat.com> References: <499700726.1036974.1365625954171.JavaMail.root@redhat.com> <269004897.1042115.1365627763231.JavaMail.root@redhat.com> Message-ID: Rebuilt the engine on my FC17 build VM with the macro file above in "/etc/rpm/" Upon attempting upgrade on my FC17 upgrade test VM: I still get a failure to start the engine 013-04-11 16:06:37::ERROR::engine-upgrade::1328::root:: Traceback (most recent call last): File "/bin/engine-upgrade", line 1321, in main(options) File "/bin/engine-upgrade", line 1293, in main runFunc([startEngine], MSG_INFO_START_ENGINE % engineService) File "/bin/engine-upgrade", line 617, in runFunc func() File "/bin/engine-upgrade", line 584, in startEngine output, rc = utils.execCmd(cmdList=cmd, failOnError=True, msg=MSG_ERR_FAILED_START_ENGINE_SERVICE) File "/usr/share/ovirt-engine/scripts/common_utils.py", line 499, in execCmd raise Exception(msg) Exception: Error: Can't start ovirt-engine Curiously is there a documented process somewhere for backing up data from an FC17 ovirt install and doing a fresh install on a FC18 box then restoring the FC17 database + ovirt config data? Guessing it goes something like this: (someone please confirm) Back up the following directories and files: /etc/ovirt-engine /etc/pki/ovirt-engine /etc/pki/ovirt-engine-backups /var/lib/ovirt-engine/backups /var/lib/ovirt-engine/deployments /root/.rnd Dump a backup of the engine database Install ovirt-engine on FC18 system run engine-setup (answer questions same as prior install from FC17) upon completion of engine-setup stop the engine service restore all the above files and directories Drop the engine databse Restore the backed up engine database FC17 --> FC18 upgrade = icky esp. with ovirt involved as part of the upgrade Thus it seems the easiest way to solve this is to bite the bullet and move to FC18 providing the backup/restore works. - DHC On Wed, Apr 10, 2013 at 4:02 PM, Alon Bar-Lev wrote: > > OK... the systemd macros are missing in fedora 17... > > Put the following file and rebuild. > I may need to add some workaround if many people still use fedora-17 for > master. > > Regards, > Alon > > /etc/rpm/macros.systemd-fc18 > --- > %systemd_post() \ > if [ $1 -eq 1 ] ; then \ > # Initial installation \ > /usr/bin/systemctl preset %{?*} >/dev/null 2>&1 || : \ > fi \ > %{nil} > > %systemd_preun() \ > if [ $1 -eq 0 ] ; then \ > # Package removal, not upgrade \ > /usr/bin/systemctl --no-reload disable %{?*} > /dev/null 2>&1 || : > \ > /usr/bin/systemctl stop %{?*} > /dev/null 2>&1 || : \ > fi \ > %{nil} > > %systemd_postun() \ > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > %{nil} > > %systemd_postun_with_restart() \ > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > if [ $1 -ge 1 ] ; then \ > # Package upgrade, not uninstall \ > /usr/bin/systemctl try-restart %{?*} >/dev/null 2>&1 || : \ > fi \ > %{nil} > --- > > ----- Original Message ----- > > From: "Dead Horse" > > To: "Alon Bar-Lev" > > Cc: engine-devel at ovirt.org > > Sent: Wednesday, April 10, 2013 11:59:15 PM > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > Correct, FC17 > > - DHC > > > > > > On Wed, Apr 10, 2013 at 3:32 PM, Alon Bar-Lev wrote: > > > > > Is this fedora 17 or 18? > > > > > > I guess it is fedora 17. > > > > > > ----- Original Message ----- > > > > From: "Dead Horse" > > > > To: engine-devel at ovirt.org > > > > Sent: Wednesday, April 10, 2013 11:23:10 PM > > > > Subject: [Engine-devel] upgrade failing with latest master > > > > > > > > logs attached > > > > > > > > First attempt: > > > > 2013-04-10 13:57:32::ERROR::common_utils::355::root:: YUM: FAIL: > Error in > > > > PREUN scriptlet in rpm package > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: > Script > > > sink: > > > > /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet > > > failed, > > > > exit status 1 > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: > Done: > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > Second attempt: > > > > 2013-04-10 15:12:11::DEBUG::common_utils::347::root:: YUM: VERB: > Building > > > > transaction > > > > 2013-04-10 15:12:12::ERROR::common_utils::355::root:: YUM: FAIL: > > > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires ovirt-engine = > > > > 3.3.0-14.fc17'] > > > > 2013-04-10 15:12:12::DEBUG::common_utils::347::root:: YUM: VERB: > > > Performing > > > > rollback > > > > 2013-04-10 15:12:12::DEBUG::common_utils::1410::root:: Locking rpms > in > > > > yum-version-lock > > > > 2013-04-10 15:12:12::ERROR::engine-upgrade::1299::root:: Traceback > (most > > > > recent call last): > > > > File "/bin/engine-upgrade", line 1292, in > > > > main(options) > > > > File "/bin/engine-upgrade", line 1142, in main > > > > runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > func() > > > > File "/bin/engine-upgrade", line 310, in begin > > > > self.emptyTransaction = not self._miniyum.buildTransaction() > > > > File "/usr/share/ovirt-engine/scripts/miniyum.py", line 761, in > > > > buildTransaction > > > > raise yum.Errors.YumBaseError(msg) > > > > YumBaseError: [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires > > > > ovirt-engine = 3.3.0-14.fc17'] > > > > > > > > Realizing things were now hosed: > > > > [root at ovirtfoo /]# yum erase ovirt-* otopi-* > > > > Loaded plugins: langpacks, presto, refresh-packagekit, versionlock > > > > Resolving Dependencies > > > > --> Running transaction check > > > > ---> Package otopi.noarch 0:3.3.0-15.fc17 will be erased > > > > ---> Package otopi-java.noarch 0:3.3.0-15.fc17 will be erased > > > > ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 will be erased > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-14.fc17 will be > erased > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be > erased > > > > ---> Package ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 will be erased > > > > ---> Package ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 will be > erased > > > > ---> Package ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 will be > erased > > > > ---> Package ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 will be erased > > > > ---> Package ovirt-engine-setup.noarch 0:3.3.0-15.fc17 will be erased > > > > ---> Package ovirt-engine-tools.noarch 0:3.3.0-14.fc17 will be erased > > > > ---> Package ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 will be > > > erased > > > > ---> Package ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > will be > > > > erased > > > > ---> Package ovirt-host-deploy.noarch 0:3.3.0-15.fc17 will be erased > > > > ---> Package ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 will be > erased > > > > ---> Package ovirt-image-uploader.noarch 0:3.3.0-15.fc17 will be > erased > > > > ---> Package ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 will be erased > > > > ---> Package ovirt-log-collector.noarch 0:3.3.0-15.fc17 will be > erased > > > > --> Finished Dependency Resolution > > > > > > > > Dependencies Resolved > > > > > > > > > > > > ================================================================================ > > > > Package Arch Version Repository Size > > > > > > > > ================================================================================ > > > > Removing: > > > > otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k > > > > otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k > > > > ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine 1.3 M > > > > ovirt-engine-backend noarch 3.3.0-14.fc17 @ovirt-engine 20 M > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > > > ovirt-engine-cli noarch 3.3.0.1-15.fc17 @ovirt-engine 557 k > > > > ovirt-engine-dbscripts noarch 3.3.0-14.fc17 @ovirt-engine 816 k > > > > ovirt-engine-restapi noarch 3.3.0-14.fc17 @ovirt-engine 1.0 M > > > > ovirt-engine-sdk noarch 3.3.0.1-15.fc17 @ovirt-engine 3.1 M > > > > ovirt-engine-setup noarch 3.3.0-15.fc17 @ovirt-engine 653 k > > > > ovirt-engine-tools noarch 3.3.0-14.fc17 @ovirt-engine 178 k > > > > ovirt-engine-userportal noarch 3.3.0-14.fc17 @ovirt-engine 23 M > > > > ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 @ovirt-engine 32 M > > > > ovirt-host-deploy noarch 3.3.0-15.fc17 @ovirt-engine 211 k > > > > ovirt-host-deploy-java noarch 3.3.0-15.fc17 @ovirt-engine 11 k > > > > ovirt-image-uploader noarch 3.3.0-15.fc17 @ovirt-engine 923 k > > > > ovirt-iso-uploader noarch 3.3.0-15.fc17 @ovirt-engine 98 k > > > > ovirt-log-collector noarch 3.3.0-15.fc17 @ovirt-engine 133 k > > > > > > > > Transaction Summary > > > > > > > > ================================================================================ > > > > Remove 18 Packages > > > > > > > > Installed size: 104 M > > > > Is this ok [y/N]: y > > > > Downloading Packages: > > > > Running Transaction Check > > > > Running Transaction Test > > > > Transaction Test Succeeded > > > > Running Transaction > > > > Erasing : ovirt-engine-backend.noarch 1/18 > > > > Erasing : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 2/18 > > > > Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch 3/18 > > > > Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch 4/18 > > > > Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch 5/18 > > > > Erasing : ovirt-engine-userportal-3.3.0-14.fc17.noarch 6/18 > > > > Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 > > > > warning: /etc/ovirt-engine/engine.conf saved as > > > > /etc/ovirt-engine/engine.conf.rpmsave > > > > Erasing : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 8/18 > > > > Erasing : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 9/18 > > > > Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 > > > > Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch 11/18 > > > > Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > > warning: /etc/ovirt-engine/imageuploader.conf saved as > > > > /etc/ovirt-engine/imageuploader.conf.rpmsave > > > > Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > warning: /etc/ovirt-engine/isouploader.conf saved as > > > > /etc/ovirt-engine/isouploader.conf.rpmsave > > > > Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch 14/18 > > > > warning: /etc/ovirt-engine/logcollector.conf saved as > > > > /etc/ovirt-engine/logcollector.conf.rpmsave > > > > Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 15/18 > > > > Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 16/18 > > > > Erasing : otopi-3.3.0-15.fc17.noarch 17/18 > > > > Error in PREUN scriptlet in rpm package ovirt-engine-backend > > > > /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet > > > failed, > > > > exit status 1 > > > > Verifying : otopi-3.3.0-15.fc17.noarch 1/18 > > > > Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 > > > > Verifying : ovirt-log-collector-3.3.0-15.fc17.noarch 3/18 > > > > Verifying : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 4/18 > > > > Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch 5/18 > > > > Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch 6/18 > > > > Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch 7/18 > > > > Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 8/18 > > > > Verifying : ovirt-engine-restapi-3.3.0-14.fc17.noarch 9/18 > > > > Verifying : ovirt-engine-userportal-3.3.0-14.fc17.noarch 10/18 > > > > Verifying : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 11/18 > > > > Verifying : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > > Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 14/18 > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch was supposed to be removed > but > > > is > > > > not! > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 15/18 > > > > Verifying : ovirt-engine-backend-3.3.0-14.fc17.noarch 16/18 > > > > Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 > > > > Verifying : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 18/18 > > > > > > > > Removed: > > > > otopi.noarch 0:3.3.0-15.fc17 > > > > otopi-java.noarch 0:3.3.0-15.fc17 > > > > ovirt-engine.noarch 0:3.3.0-14.fc17 > > > > ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > > > > ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > > > > ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > > > > ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > > > > ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > > > > ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > > > > ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > > > > ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > > > > ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > > > ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > > > > ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > > > > ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > > > > ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > > > > ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > > > > > Failed: > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > Complete! > > > > [root at ovirtfoo /]# rpm -qa | grep oto > > > > protobuf-java-2.4.1-12.fc17.x86_64 > > > > libgphoto2-2.4.14-1.fc17.x86_64 > > > > [root at ovirtfoo /]# rpm -qa | grep ovirt > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > [root at ovirtfoo /]# yum erase > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > Loaded plugins: langpacks, presto, refresh-packagekit, versionlock > > > > Resolving Dependencies > > > > --> Running transaction check > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be > erased > > > > --> Finished Dependency Resolution > > > > > > > > Dependencies Resolved > > > > > > > > > > > > ================================================================================ > > > > Package Arch Version Repository Size > > > > > > > > ================================================================================ > > > > Removing: > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > > > > > > > Transaction Summary > > > > > > > > ================================================================================ > > > > Remove 1 Package > > > > > > > > Installed size: 20 M > > > > Is this ok [y/N]: y > > > > Downloading Packages: > > > > Running Transaction Check > > > > Running Transaction Test > > > > Transaction Test Succeeded > > > > Running Transaction > > > > Error in PREUN scriptlet in rpm package > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet > > > failed, > > > > exit status 1 > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 1/1 > > > > > > > > Failed: > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > Complete! > > > > > > > > - DHC > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: ovirt-engine-upgrade_2013_04_11_15_56_32.log Type: application/octet-stream Size: 53978 bytes Desc: not available URL: From alonbl at redhat.com Thu Apr 11 21:33:27 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 11 Apr 2013 17:33:27 -0400 (EDT) Subject: [Engine-devel] upgrade failing with latest master In-Reply-To: References: <499700726.1036974.1365625954171.JavaMail.root@redhat.com> <269004897.1042115.1365627763231.JavaMail.root@redhat.com> Message-ID: <383901841.1348447.1365716007616.JavaMail.root@redhat.com> Please see what systemd has to say: # systemctl status ovirt-engine.service And no, I never tried to backup/restore... sorry... ----- Original Message ----- > From: "Dead Horse" > To: "Alon Bar-Lev" > Cc: engine-devel at ovirt.org > Sent: Friday, April 12, 2013 12:28:01 AM > Subject: Re: [Engine-devel] upgrade failing with latest master > > Rebuilt the engine on my FC17 build VM with the macro file above in > "/etc/rpm/" > Upon attempting upgrade on my FC17 upgrade test VM: > I still get a failure to start the engine > > 013-04-11 16:06:37::ERROR::engine-upgrade::1328::root:: Traceback (most > recent call last): > File "/bin/engine-upgrade", line 1321, in > main(options) > File "/bin/engine-upgrade", line 1293, in main > runFunc([startEngine], MSG_INFO_START_ENGINE % engineService) > File "/bin/engine-upgrade", line 617, in runFunc > func() > File "/bin/engine-upgrade", line 584, in startEngine > output, rc = utils.execCmd(cmdList=cmd, failOnError=True, > msg=MSG_ERR_FAILED_START_ENGINE_SERVICE) > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 499, in > execCmd > raise Exception(msg) > Exception: Error: Can't start ovirt-engine > > Curiously is there a documented process somewhere for backing up data from > an FC17 ovirt install and doing a fresh install on a FC18 box then > restoring the FC17 database + ovirt config data? > > Guessing it goes something like this: (someone please confirm) > > Back up the following directories and files: > /etc/ovirt-engine > /etc/pki/ovirt-engine > /etc/pki/ovirt-engine-backups > /var/lib/ovirt-engine/backups > /var/lib/ovirt-engine/deployments > /root/.rnd > > Dump a backup of the engine database > > Install ovirt-engine on FC18 system > run engine-setup (answer questions same as prior install from FC17) > upon completion of engine-setup stop the engine service > restore all the above files and directories > > Drop the engine databse > Restore the backed up engine database > > FC17 --> FC18 upgrade = icky esp. with ovirt involved as part of the upgrade > > Thus it seems the easiest way to solve this is to bite the bullet and move > to FC18 providing the backup/restore works. > > - DHC > > > On Wed, Apr 10, 2013 at 4:02 PM, Alon Bar-Lev wrote: > > > > > OK... the systemd macros are missing in fedora 17... > > > > Put the following file and rebuild. > > I may need to add some workaround if many people still use fedora-17 for > > master. > > > > Regards, > > Alon > > > > /etc/rpm/macros.systemd-fc18 > > --- > > %systemd_post() \ > > if [ $1 -eq 1 ] ; then \ > > # Initial installation \ > > /usr/bin/systemctl preset %{?*} >/dev/null 2>&1 || : \ > > fi \ > > %{nil} > > > > %systemd_preun() \ > > if [ $1 -eq 0 ] ; then \ > > # Package removal, not upgrade \ > > /usr/bin/systemctl --no-reload disable %{?*} > /dev/null 2>&1 || : > > \ > > /usr/bin/systemctl stop %{?*} > /dev/null 2>&1 || : \ > > fi \ > > %{nil} > > > > %systemd_postun() \ > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > %{nil} > > > > %systemd_postun_with_restart() \ > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > if [ $1 -ge 1 ] ; then \ > > # Package upgrade, not uninstall \ > > /usr/bin/systemctl try-restart %{?*} >/dev/null 2>&1 || : \ > > fi \ > > %{nil} > > --- > > > > ----- Original Message ----- > > > From: "Dead Horse" > > > To: "Alon Bar-Lev" > > > Cc: engine-devel at ovirt.org > > > Sent: Wednesday, April 10, 2013 11:59:15 PM > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > Correct, FC17 > > > - DHC > > > > > > > > > On Wed, Apr 10, 2013 at 3:32 PM, Alon Bar-Lev wrote: > > > > > > > Is this fedora 17 or 18? > > > > > > > > I guess it is fedora 17. > > > > > > > > ----- Original Message ----- > > > > > From: "Dead Horse" > > > > > To: engine-devel at ovirt.org > > > > > Sent: Wednesday, April 10, 2013 11:23:10 PM > > > > > Subject: [Engine-devel] upgrade failing with latest master > > > > > > > > > > logs attached > > > > > > > > > > First attempt: > > > > > 2013-04-10 13:57:32::ERROR::common_utils::355::root:: YUM: FAIL: > > Error in > > > > > PREUN scriptlet in rpm package > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: > > Script > > > > sink: > > > > > /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet > > > > failed, > > > > > exit status 1 > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: > > Done: > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > Second attempt: > > > > > 2013-04-10 15:12:11::DEBUG::common_utils::347::root:: YUM: VERB: > > Building > > > > > transaction > > > > > 2013-04-10 15:12:12::ERROR::common_utils::355::root:: YUM: FAIL: > > > > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires ovirt-engine = > > > > > 3.3.0-14.fc17'] > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::347::root:: YUM: VERB: > > > > Performing > > > > > rollback > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::1410::root:: Locking rpms > > in > > > > > yum-version-lock > > > > > 2013-04-10 15:12:12::ERROR::engine-upgrade::1299::root:: Traceback > > (most > > > > > recent call last): > > > > > File "/bin/engine-upgrade", line 1292, in > > > > > main(options) > > > > > File "/bin/engine-upgrade", line 1142, in main > > > > > runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > func() > > > > > File "/bin/engine-upgrade", line 310, in begin > > > > > self.emptyTransaction = not self._miniyum.buildTransaction() > > > > > File "/usr/share/ovirt-engine/scripts/miniyum.py", line 761, in > > > > > buildTransaction > > > > > raise yum.Errors.YumBaseError(msg) > > > > > YumBaseError: [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires > > > > > ovirt-engine = 3.3.0-14.fc17'] > > > > > > > > > > Realizing things were now hosed: > > > > > [root at ovirtfoo /]# yum erase ovirt-* otopi-* > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, versionlock > > > > > Resolving Dependencies > > > > > --> Running transaction check > > > > > ---> Package otopi.noarch 0:3.3.0-15.fc17 will be erased > > > > > ---> Package otopi-java.noarch 0:3.3.0-15.fc17 will be erased > > > > > ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 will be erased > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-14.fc17 will be > > erased > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be > > erased > > > > > ---> Package ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 will be erased > > > > > ---> Package ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 will be > > erased > > > > > ---> Package ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 will be > > erased > > > > > ---> Package ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 will be erased > > > > > ---> Package ovirt-engine-setup.noarch 0:3.3.0-15.fc17 will be erased > > > > > ---> Package ovirt-engine-tools.noarch 0:3.3.0-14.fc17 will be erased > > > > > ---> Package ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 will be > > > > erased > > > > > ---> Package ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > will be > > > > > erased > > > > > ---> Package ovirt-host-deploy.noarch 0:3.3.0-15.fc17 will be erased > > > > > ---> Package ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 will be > > erased > > > > > ---> Package ovirt-image-uploader.noarch 0:3.3.0-15.fc17 will be > > erased > > > > > ---> Package ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 will be erased > > > > > ---> Package ovirt-log-collector.noarch 0:3.3.0-15.fc17 will be > > erased > > > > > --> Finished Dependency Resolution > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > ================================================================================ > > > > > Package Arch Version Repository Size > > > > > > > > > > > ================================================================================ > > > > > Removing: > > > > > otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k > > > > > otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k > > > > > ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine 1.3 M > > > > > ovirt-engine-backend noarch 3.3.0-14.fc17 @ovirt-engine 20 M > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > > > > ovirt-engine-cli noarch 3.3.0.1-15.fc17 @ovirt-engine 557 k > > > > > ovirt-engine-dbscripts noarch 3.3.0-14.fc17 @ovirt-engine 816 k > > > > > ovirt-engine-restapi noarch 3.3.0-14.fc17 @ovirt-engine 1.0 M > > > > > ovirt-engine-sdk noarch 3.3.0.1-15.fc17 @ovirt-engine 3.1 M > > > > > ovirt-engine-setup noarch 3.3.0-15.fc17 @ovirt-engine 653 k > > > > > ovirt-engine-tools noarch 3.3.0-14.fc17 @ovirt-engine 178 k > > > > > ovirt-engine-userportal noarch 3.3.0-14.fc17 @ovirt-engine 23 M > > > > > ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 @ovirt-engine 32 M > > > > > ovirt-host-deploy noarch 3.3.0-15.fc17 @ovirt-engine 211 k > > > > > ovirt-host-deploy-java noarch 3.3.0-15.fc17 @ovirt-engine 11 k > > > > > ovirt-image-uploader noarch 3.3.0-15.fc17 @ovirt-engine 923 k > > > > > ovirt-iso-uploader noarch 3.3.0-15.fc17 @ovirt-engine 98 k > > > > > ovirt-log-collector noarch 3.3.0-15.fc17 @ovirt-engine 133 k > > > > > > > > > > Transaction Summary > > > > > > > > > > > ================================================================================ > > > > > Remove 18 Packages > > > > > > > > > > Installed size: 104 M > > > > > Is this ok [y/N]: y > > > > > Downloading Packages: > > > > > Running Transaction Check > > > > > Running Transaction Test > > > > > Transaction Test Succeeded > > > > > Running Transaction > > > > > Erasing : ovirt-engine-backend.noarch 1/18 > > > > > Erasing : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 2/18 > > > > > Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch 3/18 > > > > > Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch 4/18 > > > > > Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch 5/18 > > > > > Erasing : ovirt-engine-userportal-3.3.0-14.fc17.noarch 6/18 > > > > > Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 > > > > > warning: /etc/ovirt-engine/engine.conf saved as > > > > > /etc/ovirt-engine/engine.conf.rpmsave > > > > > Erasing : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 8/18 > > > > > Erasing : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 9/18 > > > > > Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 > > > > > Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch 11/18 > > > > > Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > > > warning: /etc/ovirt-engine/imageuploader.conf saved as > > > > > /etc/ovirt-engine/imageuploader.conf.rpmsave > > > > > Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > > warning: /etc/ovirt-engine/isouploader.conf saved as > > > > > /etc/ovirt-engine/isouploader.conf.rpmsave > > > > > Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch 14/18 > > > > > warning: /etc/ovirt-engine/logcollector.conf saved as > > > > > /etc/ovirt-engine/logcollector.conf.rpmsave > > > > > Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 15/18 > > > > > Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 16/18 > > > > > Erasing : otopi-3.3.0-15.fc17.noarch 17/18 > > > > > Error in PREUN scriptlet in rpm package ovirt-engine-backend > > > > > /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet > > > > failed, > > > > > exit status 1 > > > > > Verifying : otopi-3.3.0-15.fc17.noarch 1/18 > > > > > Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 > > > > > Verifying : ovirt-log-collector-3.3.0-15.fc17.noarch 3/18 > > > > > Verifying : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 4/18 > > > > > Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch 5/18 > > > > > Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch 6/18 > > > > > Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch 7/18 > > > > > Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 8/18 > > > > > Verifying : ovirt-engine-restapi-3.3.0-14.fc17.noarch 9/18 > > > > > Verifying : ovirt-engine-userportal-3.3.0-14.fc17.noarch 10/18 > > > > > Verifying : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 11/18 > > > > > Verifying : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > > > Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > > Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 14/18 > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch was supposed to be removed > > but > > > > is > > > > > not! > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 15/18 > > > > > Verifying : ovirt-engine-backend-3.3.0-14.fc17.noarch 16/18 > > > > > Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 > > > > > Verifying : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 18/18 > > > > > > > > > > Removed: > > > > > otopi.noarch 0:3.3.0-15.fc17 > > > > > otopi-java.noarch 0:3.3.0-15.fc17 > > > > > ovirt-engine.noarch 0:3.3.0-14.fc17 > > > > > ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > > > > > ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > > > > > ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > > > > > ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > > > > > ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > > > > > ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > > > > > ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > > > > > ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > > > > > ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > > > > ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > > > > > ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > > > > > ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > > > > > ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > > > > > ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > > > > > > > Failed: > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > Complete! > > > > > [root at ovirtfoo /]# rpm -qa | grep oto > > > > > protobuf-java-2.4.1-12.fc17.x86_64 > > > > > libgphoto2-2.4.14-1.fc17.x86_64 > > > > > [root at ovirtfoo /]# rpm -qa | grep ovirt > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > [root at ovirtfoo /]# yum erase > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, versionlock > > > > > Resolving Dependencies > > > > > --> Running transaction check > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be > > erased > > > > > --> Finished Dependency Resolution > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > ================================================================================ > > > > > Package Arch Version Repository Size > > > > > > > > > > > ================================================================================ > > > > > Removing: > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > > > > > > > > > Transaction Summary > > > > > > > > > > > ================================================================================ > > > > > Remove 1 Package > > > > > > > > > > Installed size: 20 M > > > > > Is this ok [y/N]: y > > > > > Downloading Packages: > > > > > Running Transaction Check > > > > > Running Transaction Test > > > > > Transaction Test Succeeded > > > > > Running Transaction > > > > > Error in PREUN scriptlet in rpm package > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) scriptlet > > > > failed, > > > > > exit status 1 > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 1/1 > > > > > > > > > > Failed: > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > Complete! > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > From lhornyak at redhat.com Fri Apr 12 12:07:48 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Fri, 12 Apr 2013 08:07:48 -0400 (EDT) Subject: [Engine-devel] watchdog In-Reply-To: <63D55D17-F63F-42DE-A4D5-93C98A6F2797@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> <5165BFA7.3080207@redhat.com> <1790221293.1779512.1365666992909.JavaMail.root@redhat.com> <299275108.2356406.1365667336012.JavaMail.root@redhat.com> <759897534.1785751.1365668728185.JavaMail.root@redhat.com> <686366765.2372459.1365669199294.JavaMail.root@redhat.com> <391456942.2269630.1365675995321.JavaMail.root@redhat.com> <63D55D17-F63F-42DE-A4D5-93C98A6F2797@redhat.com> Message-ID: <1374532417.2349757.1365768468698.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michal Skrivanek" > To: "Yair Zaslavsky" > Cc: "engine-devel" > Sent: Thursday, April 11, 2013 5:29:53 PM > Subject: Re: [Engine-devel] watchdog > > > > On 11 Apr 2013, at 12:26, Yair Zaslavsky wrote: > > > > > > > ----- Original Message ----- > >> From: "Tomas Jelinek" > >> To: "Laszlo Hornyak" > >> Cc: "engine-devel" > >> Sent: Thursday, April 11, 2013 11:33:19 AM > >> Subject: Re: [Engine-devel] watchdog > >> > >> Good that you have come up with this! So we will make sure to keep this > >> info. > >> Thnx for coming up with it! > >> > >> ----- Original Message ----- > >>> From: "Laszlo Hornyak" > >>> To: "Tomas Jelinek" > >>> Cc: "engine-devel" > >>> Sent: Thursday, April 11, 2013 10:25:28 AM > >>> Subject: Re: [Engine-devel] watchdog > >>> > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Tomas Jelinek" > >>>> To: "Laszlo Hornyak" > >>>> Cc: "engine-devel" > >>>> Sent: Thursday, April 11, 2013 10:02:16 AM > >>>> Subject: Re: [Engine-devel] watchdog > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Laszlo Hornyak" > >>>>> To: "Itamar Heim" > >>>>> Cc: "engine-devel" > >>>>> Sent: Thursday, April 11, 2013 9:56:32 AM > >>>>> Subject: Re: [Engine-devel] watchdog > >>>>> > >>>>> Hi, > >>>>> > >>>>> Isnt someone already working on removing the UI distinction between > >>>>> server > >>>>> and desktop? > >>>> Indeed :) > >>>> > >>>>> > >>>>> However the desktop/server distinction could be useful for scheduling > >>>>> information, I hope that will remain. > >>>> There will be a combo box: "optimized for server/desktop". That one > >>>> will set up the dialog like you would open the new server/desktop today. > >>>> But you will be able to change them - it will be just some sugar. But > >>>> there > >>>> is no reason > >>>> why would we enforce the disabling the e.g. soundcard for server. By > >>>> default > >>>> we will, but > >>>> you can enable it if you want. > >>> > >>> Ok, so in engine we will still have the VmType in vmStatic? > >>> > >>> I think it would make sense to use it in scheduling / load balancing > >>> - if a VM is a desktop and no user is connected to the console, then the > >>> VM > >>> is not in use, therefore it is a good candidate for saving power > >>> (hibernate, > >>> migrate, shutdown, or any other bad things that can happen to a VM) > >>> - if a VM is a server, usually no user connected, but it may still be > >>> used > >>> through its network. Therefore it may not be a good candidate to migrate. > > > > is this indeed a valid assumption ("if VM is a server..." ) that a user > > will less connect to it? > IMHO if we want some new behavior/policy there should be a new corresponding > property, not desktop/server. That can be quite misleading and I would > rather see it go away. Other than use it as a set of default values Sure, let's call it something else, but this is a typical behavior expected from the desktop/server property. So what we are going to do is that remove the property and throw away all the related data, while when (if ever) we get the new property (behaveAsDesktop, notUsedWhenNotConnected, whatever we call it) the users of the system will set this property for the VM's that used to be desktops. We could save that work for the users. Also, it may appear to be an edge-case, but for a good scheduling in my opinion this is important. > > > > > > >>> > >>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Itamar Heim" > >>>>>> To: "Laszlo Hornyak" > >>>>>> Cc: "engine-devel" , "Andrew Cathrow" > >>>>>> > >>>>>> Sent: Wednesday, April 10, 2013 9:38:15 PM > >>>>>> Subject: Re: [Engine-devel] watchdog > >>>>>> > >>>>>> On 04/10/2013 04:59 PM, Laszlo Hornyak wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> A new version of the watchd?g feature is available in gerrit: > >>>>>>> > >>>>>>> http://gerrit.ovirt.org/13057 - db > >>>>>>> http://gerrit.ovirt.org/13058 - bll > >>>>>>> http://gerrit.ovirt.org/13059 - frontend > >>>>>>> http://gerrit.ovirt.org/13060 - rest > >>>>>>> > >>>>>>> http://www.ovirt.org/Features/Watchdog_engine_support > >>>>>>> > >>>>>>> Since the last update the patchset has gone through major changes > >>>>>>> to > >>>>>>> meet > >>>>>>> the new architectureal and functional requirements. > >>>>>>> Also because of the rewrite this is again a preview version under > >>>>>>> testing > >>>>>>> with some missing functionality, therefore I re-introduced the > >>>>>>> [wip] > >>>>>>> flag > >>>>>>> on it. > >>>>>>> > >>>>>>> Thx, > >>>>>>> Laszlo > >>>>>>> _______________________________________________ > >>>>>>> Engine-devel mailing list > >>>>>>> Engine-devel at ovirt.org > >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>>>> > >>>>>> just a thought after looking at the feature page having different HA > >>>>>> dialog for server/desktop - I'd consider removing the distinction > >>>>>> between desktop and server in the GUI wrt HA (i.e., just both have > >>>>>> same > >>>>>> set of options) > >>>>>> > >>>>>> (not blocking for this patch) > >>>>> _______________________________________________ > >>>>> 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 djasa at redhat.com Fri Apr 12 12:45:31 2013 From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=) Date: Fri, 12 Apr 2013 14:45:31 +0200 Subject: [Engine-devel] watchdog In-Reply-To: <1374532417.2349757.1365768468698.JavaMail.root@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> <5165BFA7.3080207@redhat.com> <1790221293.1779512.1365666992909.JavaMail.root@redhat.com> <299275108.2356406.1365667336012.JavaMail.root@redhat.com> <759897534.1785751.1365668728185.JavaMail.root@redhat.com> <686366765.2372459.1365669199294.JavaMail.root@redhat.com> <391456942.2269630.1365675995321.JavaMail.root@redhat.com> <63D55D17-F63F-42DE-A4D5-93C98A6F2797@redhat.com> <1374532417.2349757.1365768468698.JavaMail.root@redhat.com> Message-ID: <1365770731.22484.37.camel@cihla.usersys.redhat.com> Laszlo Hornyak p??e v P? 12. 04. 2013 v 08:07 -0400: > > ----- Original Message ----- > > From: "Michal Skrivanek" > > To: "Yair Zaslavsky" > > Cc: "engine-devel" > > Sent: Thursday, April 11, 2013 5:29:53 PM > > Subject: Re: [Engine-devel] watchdog > > > > > > > > On 11 Apr 2013, at 12:26, Yair Zaslavsky wrote: > > > > > > > > > > > ----- Original Message ----- > > >> From: "Tomas Jelinek" > > >> To: "Laszlo Hornyak" > > >> Cc: "engine-devel" > > >> Sent: Thursday, April 11, 2013 11:33:19 AM > > >> Subject: Re: [Engine-devel] watchdog > > >> > > >> Good that you have come up with this! So we will make sure to keep this > > >> info. > > >> Thnx for coming up with it! > > >> > > >> ----- Original Message ----- > > >>> From: "Laszlo Hornyak" > > >>> To: "Tomas Jelinek" > > >>> Cc: "engine-devel" > > >>> Sent: Thursday, April 11, 2013 10:25:28 AM > > >>> Subject: Re: [Engine-devel] watchdog > > >>> > > >>> > > >>> > > >>> ----- Original Message ----- > > >>>> From: "Tomas Jelinek" > > >>>> To: "Laszlo Hornyak" > > >>>> Cc: "engine-devel" > > >>>> Sent: Thursday, April 11, 2013 10:02:16 AM > > >>>> Subject: Re: [Engine-devel] watchdog > > >>>> > > >>>> > > >>>> > > >>>> ----- Original Message ----- > > >>>>> From: "Laszlo Hornyak" > > >>>>> To: "Itamar Heim" > > >>>>> Cc: "engine-devel" > > >>>>> Sent: Thursday, April 11, 2013 9:56:32 AM > > >>>>> Subject: Re: [Engine-devel] watchdog > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> Isnt someone already working on removing the UI distinction between > > >>>>> server > > >>>>> and desktop? > > >>>> Indeed :) > > >>>> > > >>>>> > > >>>>> However the desktop/server distinction could be useful for scheduling > > >>>>> information, I hope that will remain. > > >>>> There will be a combo box: "optimized for server/desktop". That one > > >>>> will set up the dialog like you would open the new server/desktop today. > > >>>> But you will be able to change them - it will be just some sugar. But > > >>>> there > > >>>> is no reason > > >>>> why would we enforce the disabling the e.g. soundcard for server. By > > >>>> default > > >>>> we will, but > > >>>> you can enable it if you want. > > >>> > > >>> Ok, so in engine we will still have the VmType in vmStatic? > > >>> > > >>> I think it would make sense to use it in scheduling / load balancing > > >>> - if a VM is a desktop and no user is connected to the console, then the > > >>> VM > > >>> is not in use, therefore it is a good candidate for saving power > > >>> (hibernate, > > >>> migrate, shutdown, or any other bad things that can happen to a VM) > > >>> - if a VM is a server, usually no user connected, but it may still be > > >>> used > > >>> through its network. Therefore it may not be a good candidate to migrate. > > > > > > is this indeed a valid assumption ("if VM is a server..." ) that a user > > > will less connect to it? > > IMHO if we want some new behavior/policy there should be a new corresponding > > property, not desktop/server. That can be quite misleading and I would > > rather see it go away. Other than use it as a set of default values > > Sure, let's call it something else, but this is a typical behavior expected from the desktop/server property. Well there could be property with different default values for desktop and servers, couldn't it? ;) Think about memory overcommit or default disk allocation for example. David > So what we are going to do is that remove the property and throw away all the related data, while when (if ever) we get the new property (behaveAsDesktop, notUsedWhenNotConnected, whatever we call it) the users of the system will set this property for the VM's that used to be desktops. We could save that work for the users. > > Also, it may appear to be an edge-case, but for a good scheduling in my opinion this is important. > > > > > > > > > > > >>> > > >>>> > > >>>>> > > >>>>> ----- Original Message ----- > > >>>>>> From: "Itamar Heim" > > >>>>>> To: "Laszlo Hornyak" > > >>>>>> Cc: "engine-devel" , "Andrew Cathrow" > > >>>>>> > > >>>>>> Sent: Wednesday, April 10, 2013 9:38:15 PM > > >>>>>> Subject: Re: [Engine-devel] watchdog > > >>>>>> > > >>>>>> On 04/10/2013 04:59 PM, Laszlo Hornyak wrote: > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>> A new version of the watchd?g feature is available in gerrit: > > >>>>>>> > > >>>>>>> http://gerrit.ovirt.org/13057 - db > > >>>>>>> http://gerrit.ovirt.org/13058 - bll > > >>>>>>> http://gerrit.ovirt.org/13059 - frontend > > >>>>>>> http://gerrit.ovirt.org/13060 - rest > > >>>>>>> > > >>>>>>> http://www.ovirt.org/Features/Watchdog_engine_support > > >>>>>>> > > >>>>>>> Since the last update the patchset has gone through major changes > > >>>>>>> to > > >>>>>>> meet > > >>>>>>> the new architectureal and functional requirements. > > >>>>>>> Also because of the rewrite this is again a preview version under > > >>>>>>> testing > > >>>>>>> with some missing functionality, therefore I re-introduced the > > >>>>>>> [wip] > > >>>>>>> flag > > >>>>>>> on it. > > >>>>>>> > > >>>>>>> Thx, > > >>>>>>> Laszlo > > >>>>>>> _______________________________________________ > > >>>>>>> Engine-devel mailing list > > >>>>>>> Engine-devel at ovirt.org > > >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >>>>>> > > >>>>>> just a thought after looking at the feature page having different HA > > >>>>>> dialog for server/desktop - I'd consider removing the distinction > > >>>>>> between desktop and server in the GUI wrt HA (i.e., just both have > > >>>>>> same > > >>>>>> set of options) > > >>>>>> > > >>>>>> (not blocking for this patch) > > >>>>> _______________________________________________ > > >>>>> 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 > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- David Ja?a, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3790 bytes Desc: not available URL: From vszocs at redhat.com Fri Apr 12 18:13:43 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 12 Apr 2013 14:13:43 -0400 (EDT) Subject: [Engine-devel] New feature in UI Plugins available: Cross-window communication support In-Reply-To: <1244825909.3180976.1365787710464.JavaMail.root@redhat.com> Message-ID: <286974793.3194253.1365790423092.JavaMail.root@redhat.com> Hello everyone, we just introduced support for cross-window (cross-origin, a.k.a. cross-domain) communication that can be utilized by UI plugins. Custom content contributed by the UI plugin (e.g. via tab or dialog) can send arbitrary messages back to given plugin(s) via WebAdmin (parent) window. The implementation is based on HTML5 window.postMessage API that triggers 'message' events on the target window. WebAdmin takes care of intercepting such messages, performing source origin check per each plugin, and passing message data to plugin(s) as appropriate. With this feature, custom content can directly and transparently control/notify given UI plugin(s). Aside from content --> plugin message passing, the message data received by the plugin also contains reference to source window, i.e. custom content that sent the message. This can be used to establish two-way communication between custom content window and plugin code. For example, custom HTML content contributed by the plugin uses JavaScript to send the message: // 'parent' refers to WebAdmin window. // Most browsers support sending String messages, e.g. 'Foo Bar'. // Modern browsers support sending Object messages, e.g. {'foo':'bar'}. // The second argument is target origin that should match WebAdmin (Engine) origin. // You can also use '*' (any origin) as per HTML5 spec, however this is not a good practice. parent.postMessage('Foo Bar', 'http://engine-host:1234'); Sample UI plugin that receives the message: var api = parent.pluginApi('showcase'); // New bootstrap sequence function: provide custom API options object. // This is completely optional, there are always sensible fallback values. api.options({ // Specify allowed source origin(s) from which messages will be accepted. // Can be either string (single origin) or string array (multiple origins). // Can be '*' (any origin) as per HTML5 spec, however this is not a good practice. // Default value is empty array (reject all messages). allowedMessageOrigins: ['http://content-host:80','http://content-host:443'] }); api.register({ UiInit: function() { // Assume the dialog content takes care of sending the message. api.showDialog(...); }, // New event handler function: process message event. // Called *only* after passing source origin check, based on 'allowedMessageOrigins'. MessageReceived: function(data, sourceWindow) { // Parse and interpret data // Optionally, interact with sourceWindow (content that sent the message) } }); api.ready(); Attached you can find a sample UI plugin that demonstrates this new feature via custom dialog. Regards, Vojtech -------------- next part -------------- A non-text attachment was scrubbed... Name: sample-cross-window-messaging-plugin.tar.gz Type: application/x-compressed-tar Size: 881 bytes Desc: not available URL: From deadhorseconsulting at gmail.com Fri Apr 12 18:20:51 2013 From: deadhorseconsulting at gmail.com (Dead Horse) Date: Fri, 12 Apr 2013 13:20:51 -0500 Subject: [Engine-devel] upgrade failing with latest master In-Reply-To: <383901841.1348447.1365716007616.JavaMail.root@redhat.com> References: <499700726.1036974.1365625954171.JavaMail.root@redhat.com> <269004897.1042115.1365627763231.JavaMail.root@redhat.com> <383901841.1348447.1365716007616.JavaMail.root@redhat.com> Message-ID: Prior to engine-upgrade: ovirt-engine.service - oVirt Engine Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; enabled) Active: active (running) since Fri, 12 Apr 2013 13:11:16 -0500; 1min 10s ago Main PID: 9023 (java) CGroup: name=systemd:/system/ovirt-engine.service ? 9023 engine-service -server -XX:+TieredCompilation -Xms... Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Started engine ... Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Starting engine... Stopping ovirt-engine service prior to engine-upgrade: ovirt-engine.service - oVirt Engine Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; enabled) Active: failed (Result: exit-code) since Fri, 12 Apr 2013 13:12:51 -0500; 3s ago Process: 9141 ExecStop=/usr/bin/engine-service stop (code=exited, status=0/SUCCESS) Main PID: 9023 (code=exited, status=143) CGroup: name=systemd:/system/ovirt-engine.service Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Started engine ... Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Starting engine... Apr 12 13:12:50 ovirtfoo.ctt.med.ge.com engine-service[9141]: Waiting up to 1... Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: Stopped engine ... Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: Stopping engine... After running engine-upgrade: ovirt-engine.service - oVirt Engine Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; enabled) Active: failed (Result: exit-code) since Fri, 12 Apr 2013 13:18:22 -0500; 41s ago Main PID: 9168 (code=exited, status=143) CGroup: name=systemd:/system/ovirt-engine.service Apr 12 13:18:22 ovirtfoo.ctt.med.ge.com systemd[11198]: Failed at step EXEC spawning /usr/bin/engine-service: No such file or directory After attemptining systemctl start ovirt-engine.service after engine-upgrade: ovirt-engine.service - oVirt Engine Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; enabled) Active: active (running) since Fri, 12 Apr 2013 13:19:43 -0500; 1s ago Process: 11228 ExecStart=/usr/bin/engine-service start (code=exited, status=0/SUCCESS) Main PID: 11229 (java) CGroup: name=systemd:/system/ovirt-engine.service ? 11229 engine-service -server -XX:+TieredCompilation -Xms1g -Xmx1g -XX:PermSize=256m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=tr... Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: Started engine process 11229. Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: Starting engine-service: [ OK ] - DHC On Thu, Apr 11, 2013 at 4:33 PM, Alon Bar-Lev wrote: > Please see what systemd has to say: > > # systemctl status ovirt-engine.service > > > And no, I never tried to backup/restore... sorry... > > ----- Original Message ----- > > From: "Dead Horse" > > To: "Alon Bar-Lev" > > Cc: engine-devel at ovirt.org > > Sent: Friday, April 12, 2013 12:28:01 AM > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > Rebuilt the engine on my FC17 build VM with the macro file above in > > "/etc/rpm/" > > Upon attempting upgrade on my FC17 upgrade test VM: > > I still get a failure to start the engine > > > > 013-04-11 16:06:37::ERROR::engine-upgrade::1328::root:: Traceback (most > > recent call last): > > File "/bin/engine-upgrade", line 1321, in > > main(options) > > File "/bin/engine-upgrade", line 1293, in main > > runFunc([startEngine], MSG_INFO_START_ENGINE % engineService) > > File "/bin/engine-upgrade", line 617, in runFunc > > func() > > File "/bin/engine-upgrade", line 584, in startEngine > > output, rc = utils.execCmd(cmdList=cmd, failOnError=True, > > msg=MSG_ERR_FAILED_START_ENGINE_SERVICE) > > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 499, in > > execCmd > > raise Exception(msg) > > Exception: Error: Can't start ovirt-engine > > > > Curiously is there a documented process somewhere for backing up data > from > > an FC17 ovirt install and doing a fresh install on a FC18 box then > > restoring the FC17 database + ovirt config data? > > > > Guessing it goes something like this: (someone please confirm) > > > > Back up the following directories and files: > > /etc/ovirt-engine > > /etc/pki/ovirt-engine > > /etc/pki/ovirt-engine-backups > > /var/lib/ovirt-engine/backups > > /var/lib/ovirt-engine/deployments > > /root/.rnd > > > > Dump a backup of the engine database > > > > Install ovirt-engine on FC18 system > > run engine-setup (answer questions same as prior install from FC17) > > upon completion of engine-setup stop the engine service > > restore all the above files and directories > > > > Drop the engine databse > > Restore the backed up engine database > > > > FC17 --> FC18 upgrade = icky esp. with ovirt involved as part of the > upgrade > > > > Thus it seems the easiest way to solve this is to bite the bullet and > move > > to FC18 providing the backup/restore works. > > > > - DHC > > > > > > On Wed, Apr 10, 2013 at 4:02 PM, Alon Bar-Lev wrote: > > > > > > > > OK... the systemd macros are missing in fedora 17... > > > > > > Put the following file and rebuild. > > > I may need to add some workaround if many people still use fedora-17 > for > > > master. > > > > > > Regards, > > > Alon > > > > > > /etc/rpm/macros.systemd-fc18 > > > --- > > > %systemd_post() \ > > > if [ $1 -eq 1 ] ; then \ > > > # Initial installation \ > > > /usr/bin/systemctl preset %{?*} >/dev/null 2>&1 || : \ > > > fi \ > > > %{nil} > > > > > > %systemd_preun() \ > > > if [ $1 -eq 0 ] ; then \ > > > # Package removal, not upgrade \ > > > /usr/bin/systemctl --no-reload disable %{?*} > /dev/null 2>&1 > || : > > > \ > > > /usr/bin/systemctl stop %{?*} > /dev/null 2>&1 || : \ > > > fi \ > > > %{nil} > > > > > > %systemd_postun() \ > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > %{nil} > > > > > > %systemd_postun_with_restart() \ > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > if [ $1 -ge 1 ] ; then \ > > > # Package upgrade, not uninstall \ > > > /usr/bin/systemctl try-restart %{?*} >/dev/null 2>&1 || : \ > > > fi \ > > > %{nil} > > > --- > > > > > > ----- Original Message ----- > > > > From: "Dead Horse" > > > > To: "Alon Bar-Lev" > > > > Cc: engine-devel at ovirt.org > > > > Sent: Wednesday, April 10, 2013 11:59:15 PM > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > Correct, FC17 > > > > - DHC > > > > > > > > > > > > On Wed, Apr 10, 2013 at 3:32 PM, Alon Bar-Lev > wrote: > > > > > > > > > Is this fedora 17 or 18? > > > > > > > > > > I guess it is fedora 17. > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Dead Horse" > > > > > > To: engine-devel at ovirt.org > > > > > > Sent: Wednesday, April 10, 2013 11:23:10 PM > > > > > > Subject: [Engine-devel] upgrade failing with latest master > > > > > > > > > > > > logs attached > > > > > > > > > > > > First attempt: > > > > > > 2013-04-10 13:57:32::ERROR::common_utils::355::root:: YUM: FAIL: > > > Error in > > > > > > PREUN scriptlet in rpm package > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: > > > Script > > > > > sink: > > > > > > /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control > > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > scriptlet > > > > > failed, > > > > > > exit status 1 > > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: > > > Done: > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > Second attempt: > > > > > > 2013-04-10 15:12:11::DEBUG::common_utils::347::root:: YUM: VERB: > > > Building > > > > > > transaction > > > > > > 2013-04-10 15:12:12::ERROR::common_utils::355::root:: YUM: FAIL: > > > > > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires > ovirt-engine = > > > > > > 3.3.0-14.fc17'] > > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::347::root:: YUM: VERB: > > > > > Performing > > > > > > rollback > > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::1410::root:: Locking > rpms > > > in > > > > > > yum-version-lock > > > > > > 2013-04-10 15:12:12::ERROR::engine-upgrade::1299::root:: > Traceback > > > (most > > > > > > recent call last): > > > > > > File "/bin/engine-upgrade", line 1292, in > > > > > > main(options) > > > > > > File "/bin/engine-upgrade", line 1142, in main > > > > > > runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) > > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > > func() > > > > > > File "/bin/engine-upgrade", line 310, in begin > > > > > > self.emptyTransaction = not self._miniyum.buildTransaction() > > > > > > File "/usr/share/ovirt-engine/scripts/miniyum.py", line 761, in > > > > > > buildTransaction > > > > > > raise yum.Errors.YumBaseError(msg) > > > > > > YumBaseError: [u'ovirt-engine-backend-3.3.0-14.fc17.noarch > requires > > > > > > ovirt-engine = 3.3.0-14.fc17'] > > > > > > > > > > > > Realizing things were now hosed: > > > > > > [root at ovirtfoo /]# yum erase ovirt-* otopi-* > > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, > versionlock > > > > > > Resolving Dependencies > > > > > > --> Running transaction check > > > > > > ---> Package otopi.noarch 0:3.3.0-15.fc17 will be erased > > > > > > ---> Package otopi-java.noarch 0:3.3.0-15.fc17 will be erased > > > > > > ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 will be erased > > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-14.fc17 will be > > > erased > > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be > > > erased > > > > > > ---> Package ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 will be > erased > > > > > > ---> Package ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 will > be > > > erased > > > > > > ---> Package ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 will be > > > erased > > > > > > ---> Package ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 will be > erased > > > > > > ---> Package ovirt-engine-setup.noarch 0:3.3.0-15.fc17 will be > erased > > > > > > ---> Package ovirt-engine-tools.noarch 0:3.3.0-14.fc17 will be > erased > > > > > > ---> Package ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 will > be > > > > > erased > > > > > > ---> Package ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > > will be > > > > > > erased > > > > > > ---> Package ovirt-host-deploy.noarch 0:3.3.0-15.fc17 will be > erased > > > > > > ---> Package ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 will > be > > > erased > > > > > > ---> Package ovirt-image-uploader.noarch 0:3.3.0-15.fc17 will be > > > erased > > > > > > ---> Package ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 will be > erased > > > > > > ---> Package ovirt-log-collector.noarch 0:3.3.0-15.fc17 will be > > > erased > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > ================================================================================ > > > > > > Removing: > > > > > > otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k > > > > > > otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k > > > > > > ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine 1.3 M > > > > > > ovirt-engine-backend noarch 3.3.0-14.fc17 @ovirt-engine 20 M > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > > > > > ovirt-engine-cli noarch 3.3.0.1-15.fc17 @ovirt-engine 557 k > > > > > > ovirt-engine-dbscripts noarch 3.3.0-14.fc17 @ovirt-engine 816 k > > > > > > ovirt-engine-restapi noarch 3.3.0-14.fc17 @ovirt-engine 1.0 M > > > > > > ovirt-engine-sdk noarch 3.3.0.1-15.fc17 @ovirt-engine 3.1 M > > > > > > ovirt-engine-setup noarch 3.3.0-15.fc17 @ovirt-engine 653 k > > > > > > ovirt-engine-tools noarch 3.3.0-14.fc17 @ovirt-engine 178 k > > > > > > ovirt-engine-userportal noarch 3.3.0-14.fc17 @ovirt-engine 23 M > > > > > > ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 @ovirt-engine > 32 M > > > > > > ovirt-host-deploy noarch 3.3.0-15.fc17 @ovirt-engine 211 k > > > > > > ovirt-host-deploy-java noarch 3.3.0-15.fc17 @ovirt-engine 11 k > > > > > > ovirt-image-uploader noarch 3.3.0-15.fc17 @ovirt-engine 923 k > > > > > > ovirt-iso-uploader noarch 3.3.0-15.fc17 @ovirt-engine 98 k > > > > > > ovirt-log-collector noarch 3.3.0-15.fc17 @ovirt-engine 133 k > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > ================================================================================ > > > > > > Remove 18 Packages > > > > > > > > > > > > Installed size: 104 M > > > > > > Is this ok [y/N]: y > > > > > > Downloading Packages: > > > > > > Running Transaction Check > > > > > > Running Transaction Test > > > > > > Transaction Test Succeeded > > > > > > Running Transaction > > > > > > Erasing : ovirt-engine-backend.noarch 1/18 > > > > > > Erasing : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 2/18 > > > > > > Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch 3/18 > > > > > > Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch 4/18 > > > > > > Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch 5/18 > > > > > > Erasing : ovirt-engine-userportal-3.3.0-14.fc17.noarch 6/18 > > > > > > Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 > > > > > > warning: /etc/ovirt-engine/engine.conf saved as > > > > > > /etc/ovirt-engine/engine.conf.rpmsave > > > > > > Erasing : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 8/18 > > > > > > Erasing : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 9/18 > > > > > > Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 > > > > > > Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch 11/18 > > > > > > Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > > > > warning: /etc/ovirt-engine/imageuploader.conf saved as > > > > > > /etc/ovirt-engine/imageuploader.conf.rpmsave > > > > > > Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > > > warning: /etc/ovirt-engine/isouploader.conf saved as > > > > > > /etc/ovirt-engine/isouploader.conf.rpmsave > > > > > > Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch 14/18 > > > > > > warning: /etc/ovirt-engine/logcollector.conf saved as > > > > > > /etc/ovirt-engine/logcollector.conf.rpmsave > > > > > > Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 15/18 > > > > > > Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 16/18 > > > > > > Erasing : otopi-3.3.0-15.fc17.noarch 17/18 > > > > > > Error in PREUN scriptlet in rpm package ovirt-engine-backend > > > > > > /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control > > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > scriptlet > > > > > failed, > > > > > > exit status 1 > > > > > > Verifying : otopi-3.3.0-15.fc17.noarch 1/18 > > > > > > Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 > > > > > > Verifying : ovirt-log-collector-3.3.0-15.fc17.noarch 3/18 > > > > > > Verifying : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > 4/18 > > > > > > Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch 5/18 > > > > > > Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch 6/18 > > > > > > Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch 7/18 > > > > > > Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 8/18 > > > > > > Verifying : ovirt-engine-restapi-3.3.0-14.fc17.noarch 9/18 > > > > > > Verifying : ovirt-engine-userportal-3.3.0-14.fc17.noarch 10/18 > > > > > > Verifying : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 11/18 > > > > > > Verifying : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > > > > Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > > > Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 14/18 > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch was supposed to be > removed > > > but > > > > > is > > > > > > not! > > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 15/18 > > > > > > Verifying : ovirt-engine-backend-3.3.0-14.fc17.noarch 16/18 > > > > > > Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 > > > > > > Verifying : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 18/18 > > > > > > > > > > > > Removed: > > > > > > otopi.noarch 0:3.3.0-15.fc17 > > > > > > otopi-java.noarch 0:3.3.0-15.fc17 > > > > > > ovirt-engine.noarch 0:3.3.0-14.fc17 > > > > > > ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > > > > > > ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > > > > > > ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > > > > > > ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > > > > > > ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > > > > > > ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > > > > > > ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > > > > > > ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > > > > > > ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > > > > > ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > > > > > > ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > > > > > > ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > > > > > > ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > > > > > > ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > Failed: > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > Complete! > > > > > > [root at ovirtfoo /]# rpm -qa | grep oto > > > > > > protobuf-java-2.4.1-12.fc17.x86_64 > > > > > > libgphoto2-2.4.14-1.fc17.x86_64 > > > > > > [root at ovirtfoo /]# rpm -qa | grep ovirt > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > [root at ovirtfoo /]# yum erase > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, > versionlock > > > > > > Resolving Dependencies > > > > > > --> Running transaction check > > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be > > > erased > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > ================================================================================ > > > > > > Removing: > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > ================================================================================ > > > > > > Remove 1 Package > > > > > > > > > > > > Installed size: 20 M > > > > > > Is this ok [y/N]: y > > > > > > Downloading Packages: > > > > > > Running Transaction Check > > > > > > Running Transaction Test > > > > > > Transaction Test Succeeded > > > > > > Running Transaction > > > > > > Error in PREUN scriptlet in rpm package > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control > > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > scriptlet > > > > > failed, > > > > > > exit status 1 > > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 1/1 > > > > > > > > > > > > Failed: > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > Complete! > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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: From alonbl at redhat.com Sat Apr 13 19:17:43 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sat, 13 Apr 2013 15:17:43 -0400 (EDT) Subject: [Engine-devel] upgrade failing with latest master In-Reply-To: References: <499700726.1036974.1365625954171.JavaMail.root@redhat.com> <269004897.1042115.1365627763231.JavaMail.root@redhat.com> <383901841.1348447.1365716007616.JavaMail.root@redhat.com> Message-ID: <1273669048.47013.1365880663823.JavaMail.root@redhat.com> Which version do you use? Have you built it your-self? Have you settled all .rpmnew you have in /etc? ----- Original Message ----- > From: "Dead Horse" > To: "Alon Bar-Lev" > Cc: engine-devel at ovirt.org > Sent: Friday, April 12, 2013 9:20:51 PM > Subject: Re: [Engine-devel] upgrade failing with latest master > > Prior to engine-upgrade: > ovirt-engine.service - oVirt Engine > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; enabled) > Active: active (running) since Fri, 12 Apr 2013 13:11:16 -0500; 1min > 10s ago > Main PID: 9023 (java) > CGroup: name=systemd:/system/ovirt-engine.service > ? 9023 engine-service -server -XX:+TieredCompilation -Xms... > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Started > engine ... > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Starting > engine... > > Stopping ovirt-engine service prior to engine-upgrade: > ovirt-engine.service - oVirt Engine > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; enabled) > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 13:12:51 > -0500; 3s ago > Process: 9141 ExecStop=/usr/bin/engine-service stop (code=exited, > status=0/SUCCESS) > Main PID: 9023 (code=exited, status=143) > CGroup: name=systemd:/system/ovirt-engine.service > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Started > engine ... > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Starting > engine... > Apr 12 13:12:50 ovirtfoo.ctt.med.ge.com engine-service[9141]: Waiting up to > 1... > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: Stopped > engine ... > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: Stopping > engine... > > After running engine-upgrade: > ovirt-engine.service - oVirt Engine > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; enabled) > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 13:18:22 > -0500; 41s ago > Main PID: 9168 (code=exited, status=143) > CGroup: name=systemd:/system/ovirt-engine.service > > Apr 12 13:18:22 ovirtfoo.ctt.med.ge.com systemd[11198]: Failed at step EXEC > spawning /usr/bin/engine-service: No such file or directory > > After attemptining systemctl start ovirt-engine.service after > engine-upgrade: > ovirt-engine.service - oVirt Engine > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; enabled) > Active: active (running) since Fri, 12 Apr 2013 13:19:43 -0500; 1s ago > Process: 11228 ExecStart=/usr/bin/engine-service start (code=exited, > status=0/SUCCESS) > Main PID: 11229 (java) > CGroup: name=systemd:/system/ovirt-engine.service > ? 11229 engine-service -server -XX:+TieredCompilation -Xms1g > -Xmx1g -XX:PermSize=256m -XX:MaxPermSize=256m > -Djava.net.preferIPv4Stack=tr... > > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: Started > engine process 11229. > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: Starting > engine-service: [ OK ] > > > - DHC > > > > > On Thu, Apr 11, 2013 at 4:33 PM, Alon Bar-Lev wrote: > > > Please see what systemd has to say: > > > > # systemctl status ovirt-engine.service > > > > > > And no, I never tried to backup/restore... sorry... > > > > ----- Original Message ----- > > > From: "Dead Horse" > > > To: "Alon Bar-Lev" > > > Cc: engine-devel at ovirt.org > > > Sent: Friday, April 12, 2013 12:28:01 AM > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > Rebuilt the engine on my FC17 build VM with the macro file above in > > > "/etc/rpm/" > > > Upon attempting upgrade on my FC17 upgrade test VM: > > > I still get a failure to start the engine > > > > > > 013-04-11 16:06:37::ERROR::engine-upgrade::1328::root:: Traceback (most > > > recent call last): > > > File "/bin/engine-upgrade", line 1321, in > > > main(options) > > > File "/bin/engine-upgrade", line 1293, in main > > > runFunc([startEngine], MSG_INFO_START_ENGINE % engineService) > > > File "/bin/engine-upgrade", line 617, in runFunc > > > func() > > > File "/bin/engine-upgrade", line 584, in startEngine > > > output, rc = utils.execCmd(cmdList=cmd, failOnError=True, > > > msg=MSG_ERR_FAILED_START_ENGINE_SERVICE) > > > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 499, in > > > execCmd > > > raise Exception(msg) > > > Exception: Error: Can't start ovirt-engine > > > > > > Curiously is there a documented process somewhere for backing up data > > from > > > an FC17 ovirt install and doing a fresh install on a FC18 box then > > > restoring the FC17 database + ovirt config data? > > > > > > Guessing it goes something like this: (someone please confirm) > > > > > > Back up the following directories and files: > > > /etc/ovirt-engine > > > /etc/pki/ovirt-engine > > > /etc/pki/ovirt-engine-backups > > > /var/lib/ovirt-engine/backups > > > /var/lib/ovirt-engine/deployments > > > /root/.rnd > > > > > > Dump a backup of the engine database > > > > > > Install ovirt-engine on FC18 system > > > run engine-setup (answer questions same as prior install from FC17) > > > upon completion of engine-setup stop the engine service > > > restore all the above files and directories > > > > > > Drop the engine databse > > > Restore the backed up engine database > > > > > > FC17 --> FC18 upgrade = icky esp. with ovirt involved as part of the > > upgrade > > > > > > Thus it seems the easiest way to solve this is to bite the bullet and > > move > > > to FC18 providing the backup/restore works. > > > > > > - DHC > > > > > > > > > On Wed, Apr 10, 2013 at 4:02 PM, Alon Bar-Lev wrote: > > > > > > > > > > > OK... the systemd macros are missing in fedora 17... > > > > > > > > Put the following file and rebuild. > > > > I may need to add some workaround if many people still use fedora-17 > > for > > > > master. > > > > > > > > Regards, > > > > Alon > > > > > > > > /etc/rpm/macros.systemd-fc18 > > > > --- > > > > %systemd_post() \ > > > > if [ $1 -eq 1 ] ; then \ > > > > # Initial installation \ > > > > /usr/bin/systemctl preset %{?*} >/dev/null 2>&1 || : \ > > > > fi \ > > > > %{nil} > > > > > > > > %systemd_preun() \ > > > > if [ $1 -eq 0 ] ; then \ > > > > # Package removal, not upgrade \ > > > > /usr/bin/systemctl --no-reload disable %{?*} > /dev/null 2>&1 > > || : > > > > \ > > > > /usr/bin/systemctl stop %{?*} > /dev/null 2>&1 || : \ > > > > fi \ > > > > %{nil} > > > > > > > > %systemd_postun() \ > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > %{nil} > > > > > > > > %systemd_postun_with_restart() \ > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > if [ $1 -ge 1 ] ; then \ > > > > # Package upgrade, not uninstall \ > > > > /usr/bin/systemctl try-restart %{?*} >/dev/null 2>&1 || : \ > > > > fi \ > > > > %{nil} > > > > --- > > > > > > > > ----- Original Message ----- > > > > > From: "Dead Horse" > > > > > To: "Alon Bar-Lev" > > > > > Cc: engine-devel at ovirt.org > > > > > Sent: Wednesday, April 10, 2013 11:59:15 PM > > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > > > Correct, FC17 > > > > > - DHC > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 3:32 PM, Alon Bar-Lev > > wrote: > > > > > > > > > > > Is this fedora 17 or 18? > > > > > > > > > > > > I guess it is fedora 17. > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Dead Horse" > > > > > > > To: engine-devel at ovirt.org > > > > > > > Sent: Wednesday, April 10, 2013 11:23:10 PM > > > > > > > Subject: [Engine-devel] upgrade failing with latest master > > > > > > > > > > > > > > logs attached > > > > > > > > > > > > > > First attempt: > > > > > > > 2013-04-10 13:57:32::ERROR::common_utils::355::root:: YUM: FAIL: > > > > Error in > > > > > > > PREUN scriptlet in rpm package > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: > > > > Script > > > > > > sink: > > > > > > > /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control > > > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > scriptlet > > > > > > failed, > > > > > > > exit status 1 > > > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: VERB: > > > > Done: > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > > Second attempt: > > > > > > > 2013-04-10 15:12:11::DEBUG::common_utils::347::root:: YUM: VERB: > > > > Building > > > > > > > transaction > > > > > > > 2013-04-10 15:12:12::ERROR::common_utils::355::root:: YUM: FAIL: > > > > > > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires > > ovirt-engine = > > > > > > > 3.3.0-14.fc17'] > > > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::347::root:: YUM: VERB: > > > > > > Performing > > > > > > > rollback > > > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::1410::root:: Locking > > rpms > > > > in > > > > > > > yum-version-lock > > > > > > > 2013-04-10 15:12:12::ERROR::engine-upgrade::1299::root:: > > Traceback > > > > (most > > > > > > > recent call last): > > > > > > > File "/bin/engine-upgrade", line 1292, in > > > > > > > main(options) > > > > > > > File "/bin/engine-upgrade", line 1142, in main > > > > > > > runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) > > > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > > > func() > > > > > > > File "/bin/engine-upgrade", line 310, in begin > > > > > > > self.emptyTransaction = not self._miniyum.buildTransaction() > > > > > > > File "/usr/share/ovirt-engine/scripts/miniyum.py", line 761, in > > > > > > > buildTransaction > > > > > > > raise yum.Errors.YumBaseError(msg) > > > > > > > YumBaseError: [u'ovirt-engine-backend-3.3.0-14.fc17.noarch > > requires > > > > > > > ovirt-engine = 3.3.0-14.fc17'] > > > > > > > > > > > > > > Realizing things were now hosed: > > > > > > > [root at ovirtfoo /]# yum erase ovirt-* otopi-* > > > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, > > versionlock > > > > > > > Resolving Dependencies > > > > > > > --> Running transaction check > > > > > > > ---> Package otopi.noarch 0:3.3.0-15.fc17 will be erased > > > > > > > ---> Package otopi-java.noarch 0:3.3.0-15.fc17 will be erased > > > > > > > ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 will be erased > > > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-14.fc17 will be > > > > erased > > > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be > > > > erased > > > > > > > ---> Package ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 will be > > erased > > > > > > > ---> Package ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 will > > be > > > > erased > > > > > > > ---> Package ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 will be > > > > erased > > > > > > > ---> Package ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 will be > > erased > > > > > > > ---> Package ovirt-engine-setup.noarch 0:3.3.0-15.fc17 will be > > erased > > > > > > > ---> Package ovirt-engine-tools.noarch 0:3.3.0-14.fc17 will be > > erased > > > > > > > ---> Package ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 will > > be > > > > > > erased > > > > > > > ---> Package ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > > > will be > > > > > > > erased > > > > > > > ---> Package ovirt-host-deploy.noarch 0:3.3.0-15.fc17 will be > > erased > > > > > > > ---> Package ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 will > > be > > > > erased > > > > > > > ---> Package ovirt-image-uploader.noarch 0:3.3.0-15.fc17 will be > > > > erased > > > > > > > ---> Package ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 will be > > erased > > > > > > > ---> Package ovirt-log-collector.noarch 0:3.3.0-15.fc17 will be > > > > erased > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > Removing: > > > > > > > otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k > > > > > > > otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k > > > > > > > ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine 1.3 M > > > > > > > ovirt-engine-backend noarch 3.3.0-14.fc17 @ovirt-engine 20 M > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > > > > > > ovirt-engine-cli noarch 3.3.0.1-15.fc17 @ovirt-engine 557 k > > > > > > > ovirt-engine-dbscripts noarch 3.3.0-14.fc17 @ovirt-engine 816 k > > > > > > > ovirt-engine-restapi noarch 3.3.0-14.fc17 @ovirt-engine 1.0 M > > > > > > > ovirt-engine-sdk noarch 3.3.0.1-15.fc17 @ovirt-engine 3.1 M > > > > > > > ovirt-engine-setup noarch 3.3.0-15.fc17 @ovirt-engine 653 k > > > > > > > ovirt-engine-tools noarch 3.3.0-14.fc17 @ovirt-engine 178 k > > > > > > > ovirt-engine-userportal noarch 3.3.0-14.fc17 @ovirt-engine 23 M > > > > > > > ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 @ovirt-engine > > 32 M > > > > > > > ovirt-host-deploy noarch 3.3.0-15.fc17 @ovirt-engine 211 k > > > > > > > ovirt-host-deploy-java noarch 3.3.0-15.fc17 @ovirt-engine 11 k > > > > > > > ovirt-image-uploader noarch 3.3.0-15.fc17 @ovirt-engine 923 k > > > > > > > ovirt-iso-uploader noarch 3.3.0-15.fc17 @ovirt-engine 98 k > > > > > > > ovirt-log-collector noarch 3.3.0-15.fc17 @ovirt-engine 133 k > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > Remove 18 Packages > > > > > > > > > > > > > > Installed size: 104 M > > > > > > > Is this ok [y/N]: y > > > > > > > Downloading Packages: > > > > > > > Running Transaction Check > > > > > > > Running Transaction Test > > > > > > > Transaction Test Succeeded > > > > > > > Running Transaction > > > > > > > Erasing : ovirt-engine-backend.noarch 1/18 > > > > > > > Erasing : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 2/18 > > > > > > > Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch 3/18 > > > > > > > Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch 4/18 > > > > > > > Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch 5/18 > > > > > > > Erasing : ovirt-engine-userportal-3.3.0-14.fc17.noarch 6/18 > > > > > > > Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 > > > > > > > warning: /etc/ovirt-engine/engine.conf saved as > > > > > > > /etc/ovirt-engine/engine.conf.rpmsave > > > > > > > Erasing : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch 8/18 > > > > > > > Erasing : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 9/18 > > > > > > > Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 > > > > > > > Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch 11/18 > > > > > > > Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > > > > > warning: /etc/ovirt-engine/imageuploader.conf saved as > > > > > > > /etc/ovirt-engine/imageuploader.conf.rpmsave > > > > > > > Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > > > > warning: /etc/ovirt-engine/isouploader.conf saved as > > > > > > > /etc/ovirt-engine/isouploader.conf.rpmsave > > > > > > > Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch 14/18 > > > > > > > warning: /etc/ovirt-engine/logcollector.conf saved as > > > > > > > /etc/ovirt-engine/logcollector.conf.rpmsave > > > > > > > Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 15/18 > > > > > > > Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 16/18 > > > > > > > Erasing : otopi-3.3.0-15.fc17.noarch 17/18 > > > > > > > Error in PREUN scriptlet in rpm package ovirt-engine-backend > > > > > > > /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control > > > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > scriptlet > > > > > > failed, > > > > > > > exit status 1 > > > > > > > Verifying : otopi-3.3.0-15.fc17.noarch 1/18 > > > > > > > Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 > > > > > > > Verifying : ovirt-log-collector-3.3.0-15.fc17.noarch 3/18 > > > > > > > Verifying : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > > 4/18 > > > > > > > Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch 5/18 > > > > > > > Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch 6/18 > > > > > > > Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch 7/18 > > > > > > > Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 8/18 > > > > > > > Verifying : ovirt-engine-restapi-3.3.0-14.fc17.noarch 9/18 > > > > > > > Verifying : ovirt-engine-userportal-3.3.0-14.fc17.noarch 10/18 > > > > > > > Verifying : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 11/18 > > > > > > > Verifying : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > > > > > Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > > > > Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 14/18 > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch was supposed to be > > removed > > > > but > > > > > > is > > > > > > > not! > > > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 15/18 > > > > > > > Verifying : ovirt-engine-backend-3.3.0-14.fc17.noarch 16/18 > > > > > > > Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 > > > > > > > Verifying : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 18/18 > > > > > > > > > > > > > > Removed: > > > > > > > otopi.noarch 0:3.3.0-15.fc17 > > > > > > > otopi-java.noarch 0:3.3.0-15.fc17 > > > > > > > ovirt-engine.noarch 0:3.3.0-14.fc17 > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > > > > > > > ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > > > > > > > ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > > > > > > > ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > > > > > > > ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > > > > > > > ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > > > > > > > ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > > > > > > > ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > > > > > > > ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > > > > > > ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > > > > > > > ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > > > > > > > ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > Failed: > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > Complete! > > > > > > > [root at ovirtfoo /]# rpm -qa | grep oto > > > > > > > protobuf-java-2.4.1-12.fc17.x86_64 > > > > > > > libgphoto2-2.4.14-1.fc17.x86_64 > > > > > > > [root at ovirtfoo /]# rpm -qa | grep ovirt > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > [root at ovirtfoo /]# yum erase > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, > > versionlock > > > > > > > Resolving Dependencies > > > > > > > --> Running transaction check > > > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 will be > > > > erased > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > Removing: > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > Remove 1 Package > > > > > > > > > > > > > > Installed size: 20 M > > > > > > > Is this ok [y/N]: y > > > > > > > Downloading Packages: > > > > > > > Running Transaction Check > > > > > > > Running Transaction Test > > > > > > > Transaction Test Succeeded > > > > > > > Running Transaction > > > > > > > Error in PREUN scriptlet in rpm package > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control > > > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > scriptlet > > > > > > failed, > > > > > > > exit status 1 > > > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 1/1 > > > > > > > > > > > > > > Failed: > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > Complete! > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > From iheim at redhat.com Sun Apr 14 14:04:55 2013 From: iheim at redhat.com (Itamar Heim) Date: Sun, 14 Apr 2013 17:04:55 +0300 Subject: [Engine-devel] watchdog In-Reply-To: <194993207.1843451.1365684856859.JavaMail.root@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> <1790221293.1779512.1365666992909.JavaMail.root@redhat.com> <299275108.2356406.1365667336012.JavaMail.root@redhat.com> <759897534.1785751.1365668728185.JavaMail.root@redhat.com> <686366765.2372459.1365669199294.JavaMail.root@redhat.com> <391456942.2269630.1365675995321.JavaMail.root@redhat.com> <814758847.1807578.1365677824715.JavaMail.root@redhat.com> <51669A0C.5000009@redhat.com> <194993207.1843451.1365684856859.JavaMail.root@redhat.com> Message-ID: <516AB787.3070805@redhat.com> On 04/11/2013 03:54 PM, Laszlo Hornyak wrote: > Hi, > > It is not really an optimization based only on console connection. In my opinion this should be a decision factor when determining which VM to migrate from an overloaded host. If it is a desktop and no console connection, then it is better candidate than a desktop with console connection or a server with or without console connection. Basically this logic would just want to minimize the pain caused by the short lag when a VM is live migrated. > > Can I assume that a Desktop is only used when a console is connected? connected by spice? by vnc to host or to guest? by rdp? by remote debugging to it from a remote machine, by someone developing on it with ssh, etc... i agree the general use case you are describing make sense, but i rather we model scheduling decisions directly if/where possible From dfediuck at redhat.com Sun Apr 14 14:39:56 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Sun, 14 Apr 2013 10:39:56 -0400 (EDT) Subject: [Engine-devel] oVirt history; now in starwars! In-Reply-To: <454011345.213773.1365950222353.JavaMail.root@redhat.com> Message-ID: <841637458.213980.1365950396009.JavaMail.root@redhat.com> Here's a better way to see the project history: Engine http://starlogs.net/#oVirt/ovirt-engine VDSM http://starlogs.net/#oVirt/vdsm From dfediuck at redhat.com Sun Apr 14 14:59:56 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Sun, 14 Apr 2013 10:59:56 -0400 (EDT) Subject: [Engine-devel] watchdog In-Reply-To: <516AB787.3070805@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> <759897534.1785751.1365668728185.JavaMail.root@redhat.com> <686366765.2372459.1365669199294.JavaMail.root@redhat.com> <391456942.2269630.1365675995321.JavaMail.root@redhat.com> <814758847.1807578.1365677824715.JavaMail.root@redhat.com> <51669A0C.5000009@redhat.com> <194993207.1843451.1365684856859.JavaMail.root@redhat.com> <516AB787.3070805@redhat.com> Message-ID: <1760229958.215686.1365951596702.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Laszlo Hornyak" > Cc: "engine-devel" ovirt.org> > Sent: Sunday, April 14, 2013 5:04:55 PM > Subject: Re: [Engine-devel] watchdog > > On 04/11/2013 03:54 PM, Laszlo Hornyak wrote: > > Hi, > > > > It is not really an optimization based only on console connection. In my > > opinion this should be a decision factor when determining which VM to > > migrate from an overloaded host. If it is a desktop and no console > > connection, then it is better candidate than a desktop with console > > connection or a server with or without console connection. Basically this > > logic would just want to minimize the pain caused by the short lag when a > > VM is live migrated. > > > > Can I assume that a Desktop is only used when a console is connected? > > connected by spice? by vnc to host or to guest? by rdp? by remote > debugging to it from a remote machine, by someone developing on it with > ssh, etc... > > i agree the general use case you are describing make sense, but i rather > we model scheduling decisions directly if/where possible Some parts of this thread are looking for perfection and on the way creating additional tasks and reviewing cycles that are only remotely related to the watchdog device; Yes, we should try and reduce the existing differentiation between desktop and a server. No, this feature is not about closing that gap. Watchdog device is about handling guest crash. I strongly suggest that merging desktop and server dialogues will be done as a different feature. The watchdog feature will take one step in the 'right' direction- adding the (currently missing) HA tab into the desktop dialog based on current design. Doron From iheim at redhat.com Sun Apr 14 15:05:19 2013 From: iheim at redhat.com (Itamar Heim) Date: Sun, 14 Apr 2013 18:05:19 +0300 Subject: [Engine-devel] watchdog In-Reply-To: <1760229958.215686.1365951596702.JavaMail.root@redhat.com> References: <1288181418.1501459.1365602382786.JavaMail.root@redhat.com> <759897534.1785751.1365668728185.JavaMail.root@redhat.com> <686366765.2372459.1365669199294.JavaMail.root@redhat.com> <391456942.2269630.1365675995321.JavaMail.root@redhat.com> <814758847.1807578.1365677824715.JavaMail.root@redhat.com> <51669A0C.5000009@redhat.com> <194993207.1843451.1365684856859.JavaMail.root@redhat.com> <516AB787.3070805@redhat.com> <1760229958.215686.1365951596702.JavaMail.root@redhat.com> Message-ID: <516AC5AF.6020909@redhat.com> On 04/14/2013 05:59 PM, Doron Fediuck wrote: > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Laszlo Hornyak" >> Cc: "engine-devel" ovirt.org> >> Sent: Sunday, April 14, 2013 5:04:55 PM >> Subject: Re: [Engine-devel] watchdog >> >> On 04/11/2013 03:54 PM, Laszlo Hornyak wrote: >>> Hi, >>> >>> It is not really an optimization based only on console connection. In my >>> opinion this should be a decision factor when determining which VM to >>> migrate from an overloaded host. If it is a desktop and no console >>> connection, then it is better candidate than a desktop with console >>> connection or a server with or without console connection. Basically this >>> logic would just want to minimize the pain caused by the short lag when a >>> VM is live migrated. >>> >>> Can I assume that a Desktop is only used when a console is connected? >> >> connected by spice? by vnc to host or to guest? by rdp? by remote >> debugging to it from a remote machine, by someone developing on it with >> ssh, etc... >> >> i agree the general use case you are describing make sense, but i rather >> we model scheduling decisions directly if/where possible > > Some parts of this thread are looking for perfection and on the way > creating additional tasks and reviewing cycles that are only remotely > related to the watchdog device; > > Yes, we should try and reduce the existing differentiation between > desktop and a server. > > No, this feature is not about closing that gap. Watchdog device is > about handling guest crash. > > I strongly suggest that merging desktop and server dialogues will be > done as a different feature. The watchdog feature will take one step in > the 'right' direction- adding the (currently missing) HA tab into the > desktop dialog based on current design. > 1. it is a different task. 2. i'm suggesting you can drop the code doing that distinction for the watchdog in this patch. > Doron > From wei.d.chen at intel.com Mon Apr 15 05:54:18 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Mon, 15 Apr 2013 05:54:18 +0000 Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: <996306366.2192571.1365595398217.JavaMail.root@redhat.com> References: <2086624134.2126667.1365585146256.JavaMail.root@redhat.com> <1413514785.890062.1365593037724.JavaMail.root@redhat.com> <996306366.2192571.1365595398217.JavaMail.root@redhat.com> Message-ID: Hi Doron and Ofri, Thanks for your reply, here is some other question. ii. When adding a host into the trusted cluster, the host will be attested via OAT service, only trusted hosted can be added. Would you also kindly tell me if there is any mandatory logic check when adding a host into a cluster, so we can also put attestation logic with these mandatory check together? Some example or code location is better. Thanks a lot. Best Regards, Dave Chen -----Original Message----- From: Doron Fediuck [mailto:dfediuck at redhat.com] Sent: Wednesday, April 10, 2013 8:03 PM To: Ofri Masad Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan Subject: Re: minutes for sync up on Open Attestation integration with oVirt in 4/9 ----- Original Message ----- > From: "Ofri Masad" > To: "Gang Wei" > Cc: "Wei D Chen" , "Buddy Cao" > , "Lijuan Zhang" , "Doron > Fediuck" > Sent: Wednesday, April 10, 2013 2:23:57 PM > Subject: Re: minutes for sync up on Open Attestation integration with > oVirt in 4/9 > > Hi, > > answers inside the mail body. > > ----- Original Message ----- > > From: "Doron Fediuck" > > To: "Wei D Chen" > > Cc: "Gang Wei" , "Buddy Cao" > > , "Lijuan Zhang" , > > "Ofri Masad" > > Sent: Wednesday, April 10, 2013 12:12:26 PM > > Subject: Re: minutes for sync up on Open Attestation integration > > with oVirt in 4/9 > > > > Hi Dave, > > Adding Ofri to answer your questions. > > > > ----- Original Message ----- > > > From: "Wei D Chen" > > > To: "Gang Wei" , "Doron Fediuck" > > > , > > > "Buddy Cao" , "Lijuan Zhang" > > > > > > Sent: Wednesday, April 10, 2013 6:31:05 AM > > > Subject: RE: minutes for sync up on Open Attestation integration > > > with oVirt in 4/9 > > > > > > Hi Doron, > > > > > > > > > iii. Then periodic trust check will be added into background process > > > for > > > all existing hosts, once becoming non-trusted, mark it as > > > non-operational. > > > > > > - [Dave] Would you give me some details about the ?background > > > process? mentioned in our sync up meeting? What?s the process and > > > where is related code? > > > > > The use Quartz Job to scheduled background processes. > An example can be found in: > ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > 222) > > This code calls a method that is located in: > ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engin > e/core/bll/quota/QuotaManager.java > (Line: 1000) > the @OnTimerMethodAnnotation annotation and the unique job name > connects the two in runtime. > > The job can query the attestation server for all the host and then set > untrusted hosts to Non-Operational. > the best way would be to call SetNonOperationalVdsCommand with a new > NonOperationalReason. > This command tries to migrate all VMs from the host and then set it > non operational. > (We need to think about non-migrational VMs - should we close those > VMs or keep the host running) > One more thing you may want to consider; If we get a positive response for a host which is currently non-operational, issue an activate command to try and make it operational again. Alternatively, you may decide not to handle it, assuming untrusted hosts can only be activated manually (see below Ofri's response on activating a host). > > > > > > iv. If admin fixed the non-operational node and try to switch it to > > > operational mode again, a trust check will happen to gate the switching. > > > > > > - [Dave] If there is a button provided from UI for checking the > > > logic? or we need add an extra-button for attestation check only? > > > > > In the UI we already have the "Activate" option. What still needs to > be added is the check with the attestation provider to make sure that > if the cluster is defined 'Trusted'. If so, only trusted host will > succeed in the activate command (and, of course, a proper Audit Log > error in case the host failed to activate due to trust issue. > > the correct place to add this check would be in: > ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/org/ovirt > /engine/core/vdsbroker/VdsManager.java:activate() > this is where the re-activation process begins. > > > > > > > Thanks very much. > > > > > > > > > > > > Best Regards, > > > Dave Chen From ovedo at redhat.com Mon Apr 15 06:20:40 2013 From: ovedo at redhat.com (Oved Ourfalli) Date: Mon, 15 Apr 2013 02:20:40 -0400 (EDT) Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: References: <2086624134.2126667.1365585146256.JavaMail.root@redhat.com> <1413514785.890062.1365593037724.JavaMail.root@redhat.com> <996306366.2192571.1365595398217.JavaMail.root@redhat.com> Message-ID: <189243164.4209095.1366006840007.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Wei D Chen" > To: "Doron Fediuck" , "Ofri Masad" > Cc: engine-devel at ovirt.org > Sent: Monday, April 15, 2013 8:54:18 AM > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 > > Hi Doron and Ofri, > > Thanks for your reply, here is some other question. > > ii. When adding a host into the trusted cluster, the host will be attested > via OAT service, only trusted hosted can be added. > > Would you also kindly tell me if there is any mandatory logic check when > adding a host into a cluster, so we can also put attestation logic with > these mandatory check together? Some example or code location is better. > Thanks a lot. > I think there are two approaches, depending on the use case. #1: If the host trusted property is static, then you can narrow the tests to two locations: * AddVdsCommand - (Vds = Host) - This command is triggered when a new host is added to the system. You can use the canDoAction method (which we have on all commands, and it determines whether an action can be run or not), and there, if cluster requires trusted hosts only, you can test whether this host is trusted or not. * ChangeVdsClusterCommand - this command is used when you change the cluster of a host. So, if the target cluster requires tursted hosts, you can do a similar test in its canDoAction method. #2: If the host trusted property can change, then I'd suggest using the NonOperational property of a host. We have a class called VdsUpdateRunTimeInfo that does periodic tests of hosts, deciding what's their status, according to specific flags. The code there is quite complex, and would require refactoring at some point, but in the meantime you can use the MonitoringStrategy interface that is being used there, and implement a new monitoring strategy for Open Attestation. There, in the processHardwareCapabilities, you can test that the host is trusted. When creating the strategy, using the MonitoringStrategyFactory, you'll need to create the appropriate strategy. Currently we support either virt strategy or gluster strategy or both. In your case you would need virt+attestation / gluster+attestation / virt+gluster+attestation, according to the services deployed on the cluster. Does that make sense? Doron and Ofri, what did you have in mind for this feature? Regards, Oved > > Best Regards, > Dave Chen > > > -----Original Message----- > From: Doron Fediuck [mailto:dfediuck at redhat.com] > Sent: Wednesday, April 10, 2013 8:03 PM > To: Ofri Masad > Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan > Subject: Re: minutes for sync up on Open Attestation integration with oVirt > in 4/9 > > > > ----- Original Message ----- > > From: "Ofri Masad" > > To: "Gang Wei" > > Cc: "Wei D Chen" , "Buddy Cao" > > , "Lijuan Zhang" , "Doron > > Fediuck" > > Sent: Wednesday, April 10, 2013 2:23:57 PM > > Subject: Re: minutes for sync up on Open Attestation integration with > > oVirt in 4/9 > > > > Hi, > > > > answers inside the mail body. > > > > ----- Original Message ----- > > > From: "Doron Fediuck" > > > To: "Wei D Chen" > > > Cc: "Gang Wei" , "Buddy Cao" > > > , "Lijuan Zhang" , > > > "Ofri Masad" > > > Sent: Wednesday, April 10, 2013 12:12:26 PM > > > Subject: Re: minutes for sync up on Open Attestation integration > > > with oVirt in 4/9 > > > > > > Hi Dave, > > > Adding Ofri to answer your questions. > > > > > > ----- Original Message ----- > > > > From: "Wei D Chen" > > > > To: "Gang Wei" , "Doron Fediuck" > > > > , > > > > "Buddy Cao" , "Lijuan Zhang" > > > > > > > > Sent: Wednesday, April 10, 2013 6:31:05 AM > > > > Subject: RE: minutes for sync up on Open Attestation integration > > > > with oVirt in 4/9 > > > > > > > > Hi Doron, > > > > > > > > > > > > iii. Then periodic trust check will be added into background process > > > > for > > > > all existing hosts, once becoming non-trusted, mark it as > > > > non-operational. > > > > > > > > - [Dave] Would you give me some details about the ?background > > > > process? mentioned in our sync up meeting? What?s the process and > > > > where is related code? > > > > > > > > The use Quartz Job to scheduled background processes. > > An example can be found in: > > ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > > 222) > > > > This code calls a method that is located in: > > ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engin > > e/core/bll/quota/QuotaManager.java > > (Line: 1000) > > the @OnTimerMethodAnnotation annotation and the unique job name > > connects the two in runtime. > > > > The job can query the attestation server for all the host and then set > > untrusted hosts to Non-Operational. > > the best way would be to call SetNonOperationalVdsCommand with a new > > NonOperationalReason. > > This command tries to migrate all VMs from the host and then set it > > non operational. > > (We need to think about non-migrational VMs - should we close those > > VMs or keep the host running) > > > > One more thing you may want to consider; If we get a positive response for a > host which is currently non-operational, issue an activate command to try > and make it operational again. > Alternatively, you may decide not to handle it, assuming untrusted hosts can > only be activated manually (see below Ofri's response on activating a host). > > > > > > > > > iv. If admin fixed the non-operational node and try to switch it to > > > > operational mode again, a trust check will happen to gate the > > > > switching. > > > > > > > > - [Dave] If there is a button provided from UI for checking > > > > the > > > > logic? or we need add an extra-button for attestation check only? > > > > > > > > In the UI we already have the "Activate" option. What still needs to > > be added is the check with the attestation provider to make sure that > > if the cluster is defined 'Trusted'. If so, only trusted host will > > succeed in the activate command (and, of course, a proper Audit Log > > error in case the host failed to activate due to trust issue. > > > > the correct place to add this check would be in: > > ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/org/ovirt > > /engine/core/vdsbroker/VdsManager.java:activate() > > this is where the re-activation process begins. > > > > > > > > > > Thanks very much. > > > > > > > > > > > > > > > > Best Regards, > > > > Dave Chen > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From iheim at redhat.com Mon Apr 15 06:49:12 2013 From: iheim at redhat.com (Itamar Heim) Date: Mon, 15 Apr 2013 09:49:12 +0300 Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: <189243164.4209095.1366006840007.JavaMail.root@redhat.com> References: <2086624134.2126667.1365585146256.JavaMail.root@redhat.com> <1413514785.890062.1365593037724.JavaMail.root@redhat.com> <996306366.2192571.1365595398217.JavaMail.root@redhat.com> <189243164.4209095.1366006840007.JavaMail.root@redhat.com> Message-ID: <516BA2E8.7090207@redhat.com> On 04/15/2013 09:20 AM, Oved Ourfalli wrote: > > > ----- Original Message ----- >> From: "Wei D Chen" >> To: "Doron Fediuck" , "Ofri Masad" >> Cc: engine-devel at ovirt.org >> Sent: Monday, April 15, 2013 8:54:18 AM >> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 >> >> Hi Doron and Ofri, >> >> Thanks for your reply, here is some other question. >> >> ii. When adding a host into the trusted cluster, the host will be attested >> via OAT service, only trusted hosted can be added. >> >> Would you also kindly tell me if there is any mandatory logic check when >> adding a host into a cluster, so we can also put attestation logic with >> these mandatory check together? Some example or code location is better. >> Thanks a lot. >> > > I think there are two approaches, depending on the use case. > #1: > If the host trusted property is static, then you can narrow the tests to two locations: > * AddVdsCommand - (Vds = Host) - This command is triggered when a new host is added to the system. You can use the canDoAction method (which we have on all commands, and it determines whether an action can be run or not), and there, if cluster requires trusted hosts only, you can test whether this host is trusted or not. > * ChangeVdsClusterCommand - this command is used when you change the cluster of a host. So, if the target cluster requires tursted hosts, you can do a similar test in its canDoAction method. > > #2: > If the host trusted property can change, then I'd suggest using the NonOperational property of a host. > We have a class called VdsUpdateRunTimeInfo that does periodic tests of hosts, deciding what's their status, according to specific flags. > The code there is quite complex, and would require refactoring at some point, but in the meantime you can use the MonitoringStrategy interface that is being used there, and implement a new monitoring strategy for Open Attestation. > > There, in the processHardwareCapabilities, you can test that the host is trusted. > > When creating the strategy, using the MonitoringStrategyFactory, you'll need to create the appropriate strategy. > Currently we support either virt strategy or gluster strategy or both. In your case you would need virt+attestation / gluster+attestation / virt+gluster+attestation, according to the services deployed on the cluster. I'd go with the 2nd approach. i.e., not block the host from being added, only from being used, based on monitoring / non-op status > > > Does that make sense? > Doron and Ofri, what did you have in mind for this feature? > > Regards, > Oved > >> >> Best Regards, >> Dave Chen >> >> >> -----Original Message----- >> From: Doron Fediuck [mailto:dfediuck at redhat.com] >> Sent: Wednesday, April 10, 2013 8:03 PM >> To: Ofri Masad >> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan >> Subject: Re: minutes for sync up on Open Attestation integration with oVirt >> in 4/9 >> >> >> >> ----- Original Message ----- >>> From: "Ofri Masad" >>> To: "Gang Wei" >>> Cc: "Wei D Chen" , "Buddy Cao" >>> , "Lijuan Zhang" , "Doron >>> Fediuck" >>> Sent: Wednesday, April 10, 2013 2:23:57 PM >>> Subject: Re: minutes for sync up on Open Attestation integration with >>> oVirt in 4/9 >>> >>> Hi, >>> >>> answers inside the mail body. >>> >>> ----- Original Message ----- >>>> From: "Doron Fediuck" >>>> To: "Wei D Chen" >>>> Cc: "Gang Wei" , "Buddy Cao" >>>> , "Lijuan Zhang" , >>>> "Ofri Masad" >>>> Sent: Wednesday, April 10, 2013 12:12:26 PM >>>> Subject: Re: minutes for sync up on Open Attestation integration >>>> with oVirt in 4/9 >>>> >>>> Hi Dave, >>>> Adding Ofri to answer your questions. >>>> >>>> ----- Original Message ----- >>>>> From: "Wei D Chen" >>>>> To: "Gang Wei" , "Doron Fediuck" >>>>> , >>>>> "Buddy Cao" , "Lijuan Zhang" >>>>> >>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM >>>>> Subject: RE: minutes for sync up on Open Attestation integration >>>>> with oVirt in 4/9 >>>>> >>>>> Hi Doron, >>>>> >>>>> >>>>> iii. Then periodic trust check will be added into background process >>>>> for >>>>> all existing hosts, once becoming non-trusted, mark it as >>>>> non-operational. >>>>> >>>>> - [Dave] Would you give me some details about the ?background >>>>> process? mentioned in our sync up meeting? What?s the process and >>>>> where is related code? >>>>> >>> >>> The use Quartz Job to scheduled background processes. >>> An example can be found in: >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: >>> 222) >>> >>> This code calls a method that is located in: >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engin >>> e/core/bll/quota/QuotaManager.java >>> (Line: 1000) >>> the @OnTimerMethodAnnotation annotation and the unique job name >>> connects the two in runtime. >>> >>> The job can query the attestation server for all the host and then set >>> untrusted hosts to Non-Operational. >>> the best way would be to call SetNonOperationalVdsCommand with a new >>> NonOperationalReason. >>> This command tries to migrate all VMs from the host and then set it >>> non operational. >>> (We need to think about non-migrational VMs - should we close those >>> VMs or keep the host running) >>> >> >> One more thing you may want to consider; If we get a positive response for a >> host which is currently non-operational, issue an activate command to try >> and make it operational again. >> Alternatively, you may decide not to handle it, assuming untrusted hosts can >> only be activated manually (see below Ofri's response on activating a host). >> >>>>> >>>>> iv. If admin fixed the non-operational node and try to switch it to >>>>> operational mode again, a trust check will happen to gate the >>>>> switching. >>>>> >>>>> - [Dave] If there is a button provided from UI for checking >>>>> the >>>>> logic? or we need add an extra-button for attestation check only? >>>>> >>> >>> In the UI we already have the "Activate" option. What still needs to >>> be added is the check with the attestation provider to make sure that >>> if the cluster is defined 'Trusted'. If so, only trusted host will >>> succeed in the activate command (and, of course, a proper Audit Log >>> error in case the host failed to activate due to trust issue. >>> >>> the correct place to add this check would be in: >>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/org/ovirt >>> /engine/core/vdsbroker/VdsManager.java:activate() >>> this is where the re-activation process begins. >>> >>>>> >>>>> Thanks very much. >>>>> >>>>> >>>>> >>>>> Best Regards, >>>>> Dave Chen >> _______________________________________________ >> 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 dfediuck at redhat.com Mon Apr 15 07:05:57 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Mon, 15 Apr 2013 03:05:57 -0400 (EDT) Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: <516BA2E8.7090207@redhat.com> References: <2086624134.2126667.1365585146256.JavaMail.root@redhat.com> <1413514785.890062.1365593037724.JavaMail.root@redhat.com> <996306366.2192571.1365595398217.JavaMail.root@redhat.com> <189243164.4209095.1366006840007.JavaMail.root@redhat.com> <516BA2E8.7090207@redhat.com> Message-ID: <448237996.384685.1366009557875.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Oved Ourfalli" > Cc: engine-devel at ovirt.org > Sent: Monday, April 15, 2013 9:49:12 AM > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 > > On 04/15/2013 09:20 AM, Oved Ourfalli wrote: > > > > > > ----- Original Message ----- > >> From: "Wei D Chen" > >> To: "Doron Fediuck" , "Ofri Masad" > >> > >> Cc: engine-devel at ovirt.org > >> Sent: Monday, April 15, 2013 8:54:18 AM > >> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > >> integration with oVirt in 4/9 > >> > >> Hi Doron and Ofri, > >> > >> Thanks for your reply, here is some other question. > >> > >> ii. When adding a host into the trusted cluster, the host will be > >> attested > >> via OAT service, only trusted hosted can be added. > >> > >> Would you also kindly tell me if there is any mandatory logic check when > >> adding a host into a cluster, so we can also put attestation logic with > >> these mandatory check together? Some example or code location is better. > >> Thanks a lot. > >> > > > > I think there are two approaches, depending on the use case. > > #1: > > If the host trusted property is static, then you can narrow the tests to > > two locations: > > * AddVdsCommand - (Vds = Host) - This command is triggered when a new host > > is added to the system. You can use the canDoAction method (which we have > > on all commands, and it determines whether an action can be run or not), > > and there, if cluster requires trusted hosts only, you can test whether > > this host is trusted or not. > > * ChangeVdsClusterCommand - this command is used when you change the > > cluster of a host. So, if the target cluster requires tursted hosts, you > > can do a similar test in its canDoAction method. > > > > #2: > > If the host trusted property can change, then I'd suggest using the > > NonOperational property of a host. > > We have a class called VdsUpdateRunTimeInfo that does periodic tests of > > hosts, deciding what's their status, according to specific flags. > > The code there is quite complex, and would require refactoring at some > > point, but in the meantime you can use the MonitoringStrategy interface > > that is being used there, and implement a new monitoring strategy for Open > > Attestation. > > > > There, in the processHardwareCapabilities, you can test that the host is > > trusted. > > > > When creating the strategy, using the MonitoringStrategyFactory, you'll > > need to create the appropriate strategy. > > Currently we support either virt strategy or gluster strategy or both. In > > your case you would need virt+attestation / gluster+attestation / > > virt+gluster+attestation, according to the services deployed on the > > cluster. > > I'd go with the 2nd approach. i.e., not block the host from being added, > only from being used, based on monitoring / non-op status > +1. It means that the admin can add the host, but the host will not be operational until we get a positive indication from the attestation service. > > > > > > > Does that make sense? > > Doron and Ofri, what did you have in mind for this feature? > > > > Regards, > > Oved > > > >> > >> Best Regards, > >> Dave Chen > >> > >> > >> -----Original Message----- > >> From: Doron Fediuck [mailto:dfediuck at redhat.com] > >> Sent: Wednesday, April 10, 2013 8:03 PM > >> To: Ofri Masad > >> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan > >> Subject: Re: minutes for sync up on Open Attestation integration with > >> oVirt > >> in 4/9 > >> > >> > >> > >> ----- Original Message ----- > >>> From: "Ofri Masad" > >>> To: "Gang Wei" > >>> Cc: "Wei D Chen" , "Buddy Cao" > >>> , "Lijuan Zhang" , "Doron > >>> Fediuck" > >>> Sent: Wednesday, April 10, 2013 2:23:57 PM > >>> Subject: Re: minutes for sync up on Open Attestation integration with > >>> oVirt in 4/9 > >>> > >>> Hi, > >>> > >>> answers inside the mail body. > >>> > >>> ----- Original Message ----- > >>>> From: "Doron Fediuck" > >>>> To: "Wei D Chen" > >>>> Cc: "Gang Wei" , "Buddy Cao" > >>>> , "Lijuan Zhang" , > >>>> "Ofri Masad" > >>>> Sent: Wednesday, April 10, 2013 12:12:26 PM > >>>> Subject: Re: minutes for sync up on Open Attestation integration > >>>> with oVirt in 4/9 > >>>> > >>>> Hi Dave, > >>>> Adding Ofri to answer your questions. > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Wei D Chen" > >>>>> To: "Gang Wei" , "Doron Fediuck" > >>>>> , > >>>>> "Buddy Cao" , "Lijuan Zhang" > >>>>> > >>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM > >>>>> Subject: RE: minutes for sync up on Open Attestation integration > >>>>> with oVirt in 4/9 > >>>>> > >>>>> Hi Doron, > >>>>> > >>>>> > >>>>> iii. Then periodic trust check will be added into background process > >>>>> for > >>>>> all existing hosts, once becoming non-trusted, mark it as > >>>>> non-operational. > >>>>> > >>>>> - [Dave] Would you give me some details about the ?background > >>>>> process? mentioned in our sync up meeting? What?s the process and > >>>>> where is related code? > >>>>> > >>> > >>> The use Quartz Job to scheduled background processes. > >>> An example can be found in: > >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > >>> 222) > >>> > >>> This code calls a method that is located in: > >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engin > >>> e/core/bll/quota/QuotaManager.java > >>> (Line: 1000) > >>> the @OnTimerMethodAnnotation annotation and the unique job name > >>> connects the two in runtime. > >>> > >>> The job can query the attestation server for all the host and then set > >>> untrusted hosts to Non-Operational. > >>> the best way would be to call SetNonOperationalVdsCommand with a new > >>> NonOperationalReason. > >>> This command tries to migrate all VMs from the host and then set it > >>> non operational. > >>> (We need to think about non-migrational VMs - should we close those > >>> VMs or keep the host running) > >>> > >> > >> One more thing you may want to consider; If we get a positive response for > >> a > >> host which is currently non-operational, issue an activate command to try > >> and make it operational again. > >> Alternatively, you may decide not to handle it, assuming untrusted hosts > >> can > >> only be activated manually (see below Ofri's response on activating a > >> host). > >> > >>>>> > >>>>> iv. If admin fixed the non-operational node and try to switch it to > >>>>> operational mode again, a trust check will happen to gate the > >>>>> switching. > >>>>> > >>>>> - [Dave] If there is a button provided from UI for checking > >>>>> the > >>>>> logic? or we need add an extra-button for attestation check only? > >>>>> > >>> > >>> In the UI we already have the "Activate" option. What still needs to > >>> be added is the check with the attestation provider to make sure that > >>> if the cluster is defined 'Trusted'. If so, only trusted host will > >>> succeed in the activate command (and, of course, a proper Audit Log > >>> error in case the host failed to activate due to trust issue. > >>> > >>> the correct place to add this check would be in: > >>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/org/ovirt > >>> /engine/core/vdsbroker/VdsManager.java:activate() > >>> this is where the re-activation process begins. > >>> > >>>>> > >>>>> Thanks very much. > >>>>> > >>>>> > >>>>> > >>>>> Best Regards, > >>>>> Dave Chen > >> _______________________________________________ > >> 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 ofrenkel at redhat.com Mon Apr 15 11:00:42 2013 From: ofrenkel at redhat.com (Omer Frenkel) Date: Mon, 15 Apr 2013 07:00:42 -0400 (EDT) Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: <448237996.384685.1366009557875.JavaMail.root@redhat.com> References: <2086624134.2126667.1365585146256.JavaMail.root@redhat.com> <1413514785.890062.1365593037724.JavaMail.root@redhat.com> <996306366.2192571.1365595398217.JavaMail.root@redhat.com> <189243164.4209095.1366006840007.JavaMail.root@redhat.com> <516BA2E8.7090207@redhat.com> <448237996.384685.1366009557875.JavaMail.root@redhat.com> Message-ID: <1045509486.480916.1366023642593.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Doron Fediuck" > To: "Itamar Heim" > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > Sent: Monday, April 15, 2013 10:05:57 AM > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 > > > > ----- Original Message ----- > > From: "Itamar Heim" > > To: "Oved Ourfalli" > > Cc: engine-devel at ovirt.org > > Sent: Monday, April 15, 2013 9:49:12 AM > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > integration with oVirt in 4/9 > > > > On 04/15/2013 09:20 AM, Oved Ourfalli wrote: > > > > > > > > > ----- Original Message ----- > > >> From: "Wei D Chen" > > >> To: "Doron Fediuck" , "Ofri Masad" > > >> > > >> Cc: engine-devel at ovirt.org > > >> Sent: Monday, April 15, 2013 8:54:18 AM > > >> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > >> integration with oVirt in 4/9 > > >> > > >> Hi Doron and Ofri, > > >> > > >> Thanks for your reply, here is some other question. > > >> > > >> ii. When adding a host into the trusted cluster, the host will be > > >> attested > > >> via OAT service, only trusted hosted can be added. > > >> > > >> Would you also kindly tell me if there is any mandatory logic check when > > >> adding a host into a cluster, so we can also put attestation logic with > > >> these mandatory check together? Some example or code location is better. > > >> Thanks a lot. > > >> > > > > > > I think there are two approaches, depending on the use case. > > > #1: > > > If the host trusted property is static, then you can narrow the tests to > > > two locations: > > > * AddVdsCommand - (Vds = Host) - This command is triggered when a new > > > host > > > is added to the system. You can use the canDoAction method (which we have > > > on all commands, and it determines whether an action can be run or not), > > > and there, if cluster requires trusted hosts only, you can test whether > > > this host is trusted or not. > > > * ChangeVdsClusterCommand - this command is used when you change the > > > cluster of a host. So, if the target cluster requires tursted hosts, you > > > can do a similar test in its canDoAction method. > > > > > > #2: > > > If the host trusted property can change, then I'd suggest using the > > > NonOperational property of a host. > > > We have a class called VdsUpdateRunTimeInfo that does periodic tests of > > > hosts, deciding what's their status, according to specific flags. > > > The code there is quite complex, and would require refactoring at some > > > point, but in the meantime you can use the MonitoringStrategy interface > > > that is being used there, and implement a new monitoring strategy for > > > Open > > > Attestation. > > > > > > There, in the processHardwareCapabilities, you can test that the host is > > > trusted. > > > > > > When creating the strategy, using the MonitoringStrategyFactory, you'll > > > need to create the appropriate strategy. > > > Currently we support either virt strategy or gluster strategy or both. In > > > your case you would need virt+attestation / gluster+attestation / > > > virt+gluster+attestation, according to the services deployed on the > > > cluster. > > > > I'd go with the 2nd approach. i.e., not block the host from being added, > > only from being used, based on monitoring / non-op status > > > +1. > It means that the admin can add the host, but the host will not > be operational until we get a positive indication from the attestation > service. > +1 if we want to test attestation only once, every time before host moves to up. the right place for it, imo, is InitVdsOnUpCommand if its periodic also after host is up, then it should be somewhere in the monitoring code > > > > > > > > > > > Does that make sense? > > > Doron and Ofri, what did you have in mind for this feature? > > > > > > Regards, > > > Oved > > > > > >> > > >> Best Regards, > > >> Dave Chen > > >> > > >> > > >> -----Original Message----- > > >> From: Doron Fediuck [mailto:dfediuck at redhat.com] > > >> Sent: Wednesday, April 10, 2013 8:03 PM > > >> To: Ofri Masad > > >> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan > > >> Subject: Re: minutes for sync up on Open Attestation integration with > > >> oVirt > > >> in 4/9 > > >> > > >> > > >> > > >> ----- Original Message ----- > > >>> From: "Ofri Masad" > > >>> To: "Gang Wei" > > >>> Cc: "Wei D Chen" , "Buddy Cao" > > >>> , "Lijuan Zhang" , "Doron > > >>> Fediuck" > > >>> Sent: Wednesday, April 10, 2013 2:23:57 PM > > >>> Subject: Re: minutes for sync up on Open Attestation integration with > > >>> oVirt in 4/9 > > >>> > > >>> Hi, > > >>> > > >>> answers inside the mail body. > > >>> > > >>> ----- Original Message ----- > > >>>> From: "Doron Fediuck" > > >>>> To: "Wei D Chen" > > >>>> Cc: "Gang Wei" , "Buddy Cao" > > >>>> , "Lijuan Zhang" , > > >>>> "Ofri Masad" > > >>>> Sent: Wednesday, April 10, 2013 12:12:26 PM > > >>>> Subject: Re: minutes for sync up on Open Attestation integration > > >>>> with oVirt in 4/9 > > >>>> > > >>>> Hi Dave, > > >>>> Adding Ofri to answer your questions. > > >>>> > > >>>> ----- Original Message ----- > > >>>>> From: "Wei D Chen" > > >>>>> To: "Gang Wei" , "Doron Fediuck" > > >>>>> , > > >>>>> "Buddy Cao" , "Lijuan Zhang" > > >>>>> > > >>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM > > >>>>> Subject: RE: minutes for sync up on Open Attestation integration > > >>>>> with oVirt in 4/9 > > >>>>> > > >>>>> Hi Doron, > > >>>>> > > >>>>> > > >>>>> iii. Then periodic trust check will be added into background > > >>>>> process > > >>>>> for > > >>>>> all existing hosts, once becoming non-trusted, mark it as > > >>>>> non-operational. > > >>>>> > > >>>>> - [Dave] Would you give me some details about the > > >>>>> ?background > > >>>>> process? mentioned in our sync up meeting? What?s the process and > > >>>>> where is related code? > > >>>>> > > >>> > > >>> The use Quartz Job to scheduled background processes. > > >>> An example can be found in: > > >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > > >>> 222) > > >>> > > >>> This code calls a method that is located in: > > >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engin > > >>> e/core/bll/quota/QuotaManager.java > > >>> (Line: 1000) > > >>> the @OnTimerMethodAnnotation annotation and the unique job name > > >>> connects the two in runtime. > > >>> > > >>> The job can query the attestation server for all the host and then set > > >>> untrusted hosts to Non-Operational. > > >>> the best way would be to call SetNonOperationalVdsCommand with a new > > >>> NonOperationalReason. > > >>> This command tries to migrate all VMs from the host and then set it > > >>> non operational. > > >>> (We need to think about non-migrational VMs - should we close those > > >>> VMs or keep the host running) > > >>> > > >> > > >> One more thing you may want to consider; If we get a positive response > > >> for > > >> a > > >> host which is currently non-operational, issue an activate command to > > >> try > > >> and make it operational again. > > >> Alternatively, you may decide not to handle it, assuming untrusted hosts > > >> can > > >> only be activated manually (see below Ofri's response on activating a > > >> host). > > >> > > >>>>> > > >>>>> iv. If admin fixed the non-operational node and try to switch it > > >>>>> to > > >>>>> operational mode again, a trust check will happen to gate the > > >>>>> switching. > > >>>>> > > >>>>> - [Dave] If there is a button provided from UI for checking > > >>>>> the > > >>>>> logic? or we need add an extra-button for attestation check only? > > >>>>> > > >>> > > >>> In the UI we already have the "Activate" option. What still needs to > > >>> be added is the check with the attestation provider to make sure that > > >>> if the cluster is defined 'Trusted'. If so, only trusted host will > > >>> succeed in the activate command (and, of course, a proper Audit Log > > >>> error in case the host failed to activate due to trust issue. > > >>> > > >>> the correct place to add this check would be in: > > >>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/org/ovirt > > >>> /engine/core/vdsbroker/VdsManager.java:activate() > > >>> this is where the re-activation process begins. > > >>> > > >>>>> > > >>>>> Thanks very much. > > >>>>> > > >>>>> > > >>>>> > > >>>>> Best Regards, > > >>>>> Dave Chen > > >> _______________________________________________ > > >> 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 vszocs at redhat.com Mon Apr 15 11:04:24 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 15 Apr 2013 07:04:24 -0400 (EDT) Subject: [Engine-devel] Proposal to make REST API more webapp-friendly In-Reply-To: <74332443.725701.1366019120835.JavaMail.root@redhat.com> Message-ID: <2140658645.762187.1366023864071.JavaMail.root@redhat.com> Hi guys, having worked with Engine REST API from web application (JavaScript) perspective, there are things that could be improved to make REST API more webapp-friendly. First of all, webapps are *not* traditional HTTP clients, i.e. they have *not* full control over HTTP processing. There are some standard conventions and behaviors built into web browsers that any REST API implementation should be aware of. -- (1) Don't force clients to use cookies for transmitting authentication information! (or don't use cookies at all) Good explanation can be found at [http://www.berenddeboer.net/rest/cookies.html]. Cookies have many disadvantages: * cookie parsing/formatting is not trivial --> extra complexity imposed on REST clients * in addition to Same-Origin Policy [http://en.wikipedia.org/wiki/Same_origin_policy], cookies can be get/set *only* for the given path --> JavaScript running at [http://example.com/webapp] *cannot* get/set cookies from requests at [http://example.com/restapi] * cookies are the primary source of Cross-Site Request Forgery [http://en.wikipedia.org/wiki/Cross-site_request_forgery] attacks --> malicious websites/scripts can forge requests to REST API that will include the cookie, compromising user session Alternative: clients could be given the *option* to use regular HTTP header for transmitting authentication information. For example, webapp could read such (sensitive information) header, store it securely via HTML5 Session Storage [http://en.wikipedia.org/wiki/Web_storage] and implement related HTTP processing on its own, e.g. pass this header for all authenticated requests (instead of pushing this responsibility to browser). -- (2) Straight-forward HTTP Basic Auth has some drawbacks! HTTP Basic Auth [http://en.wikipedia.org/wiki/Basic_access_authentication] over (non-secure) HTTP connection means sending user credentials (username/password/domain) in easy-to-decode cleartext, i.e. the value is *not* encrypted or hashed in any way. Using secure lower-level protocol (SSL) fixes the consequence, rather than the root cause of the confidentiality issue. Furthermore, browsers typically remember HTTP Basic Auth information (either via browser-specific popup, or via XmlHttpRequest) until the browser window is closed. This means the webapp has no control over HTTP Basic Auth header after it has been set! This is the reason why it's hard to implement "logout" functionality in webapps when using HTTP Basic Auth. Last but not least, HTTP Basic Auth is vulnerable to Replay attacks [http://en.wikipedia.org/wiki/Replay_attack]. Someone between client and server can intercept requests and replay them, compromising user session. Alternative: clients could be given the *option* to use more advanced authentication scheme. I've just read an excellent article at [http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/] which describes easy yet secure authentication scheme inspired by Amazon Web Services REST API authentication [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html]. The idea is simple: collect auth information, hash (sign) it with a private key, and send everything to server. To guard against Replay attacks, just provide some timestamp to enforce request expiry after some time (say, 5-15 minutes). Easy and simple! -- (3) Support JSON for resource representations! I think this is pretty much obvious. XML has no real advantages over JSON. JSON, on the other hand, has good support in webapps (JavaScript) and maps directly to common data structures (i.e. string, number, boolean, and so on). >From webapp perspective, it's much easier and natural to use JSON than to parse/format XML documents. Alternative: clients could be given the *option* to use JSON, in addition to XML representation. -- Vojtech From wei.d.chen at intel.com Mon Apr 15 14:53:34 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Mon, 15 Apr 2013 14:53:34 +0000 Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: <1045509486.480916.1366023642593.JavaMail.root@redhat.com> References: <2086624134.2126667.1365585146256.JavaMail.root@redhat.com> <1413514785.890062.1365593037724.JavaMail.root@redhat.com> <996306366.2192571.1365595398217.JavaMail.root@redhat.com> <189243164.4209095.1366006840007.JavaMail.root@redhat.com> <516BA2E8.7090207@redhat.com> <448237996.384685.1366009557875.JavaMail.root@redhat.com> <1045509486.480916.1366023642593.JavaMail.root@redhat.com> Message-ID: Good approach, thanks all. How long it needs to invoke periodic check in the class of VdsUpdateRunTimeInfo? Whether this time configurable? My concern is if the initial status of each host added into trusted cluster is non-operational, we need wait a long time for the invoking of this periodic check, so a trusted host's with initial status of non-operational will take a long time to flip to a trusted host. As I have not seen the configuration of periodic check in VdsUpdateRunTimeInfo, would you give me some tips if you has some clue. Thanks a lot. Best Regards, Dave Chen -----Original Message----- From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Omer Frenkel Sent: Monday, April 15, 2013 7:01 PM To: Doron Fediuck Cc: Oved Ourfalli; engine-devel at ovirt.org Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 ----- Original Message ----- > From: "Doron Fediuck" > To: "Itamar Heim" > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > Sent: Monday, April 15, 2013 10:05:57 AM > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > integration with oVirt in 4/9 > > > > ----- Original Message ----- > > From: "Itamar Heim" > > To: "Oved Ourfalli" > > Cc: engine-devel at ovirt.org > > Sent: Monday, April 15, 2013 9:49:12 AM > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > integration with oVirt in 4/9 > > > > On 04/15/2013 09:20 AM, Oved Ourfalli wrote: > > > > > > > > > ----- Original Message ----- > > >> From: "Wei D Chen" > > >> To: "Doron Fediuck" , "Ofri Masad" > > >> > > >> Cc: engine-devel at ovirt.org > > >> Sent: Monday, April 15, 2013 8:54:18 AM > > >> Subject: Re: [Engine-devel] minutes for sync up on Open > > >> Attestation integration with oVirt in 4/9 > > >> > > >> Hi Doron and Ofri, > > >> > > >> Thanks for your reply, here is some other question. > > >> > > >> ii. When adding a host into the trusted cluster, the host will > > >> be attested via OAT service, only trusted hosted can be added. > > >> > > >> Would you also kindly tell me if there is any mandatory logic > > >> check when adding a host into a cluster, so we can also put > > >> attestation logic with these mandatory check together? Some example or code location is better. > > >> Thanks a lot. > > >> > > > > > > I think there are two approaches, depending on the use case. > > > #1: > > > If the host trusted property is static, then you can narrow the > > > tests to two locations: > > > * AddVdsCommand - (Vds = Host) - This command is triggered when a > > > new host is added to the system. You can use the canDoAction > > > method (which we have on all commands, and it determines whether > > > an action can be run or not), and there, if cluster requires > > > trusted hosts only, you can test whether this host is trusted or > > > not. > > > * ChangeVdsClusterCommand - this command is used when you change > > > the cluster of a host. So, if the target cluster requires tursted > > > hosts, you can do a similar test in its canDoAction method. > > > > > > #2: > > > If the host trusted property can change, then I'd suggest using > > > the NonOperational property of a host. > > > We have a class called VdsUpdateRunTimeInfo that does periodic > > > tests of hosts, deciding what's their status, according to specific flags. > > > The code there is quite complex, and would require refactoring at > > > some point, but in the meantime you can use the MonitoringStrategy > > > interface that is being used there, and implement a new monitoring > > > strategy for Open Attestation. > > > > > > There, in the processHardwareCapabilities, you can test that the > > > host is trusted. > > > > > > When creating the strategy, using the MonitoringStrategyFactory, > > > you'll need to create the appropriate strategy. > > > Currently we support either virt strategy or gluster strategy or > > > both. In your case you would need virt+attestation / > > > gluster+attestation / > > > virt+gluster+attestation, according to the services deployed on > > > virt+gluster+the > > > cluster. > > > > I'd go with the 2nd approach. i.e., not block the host from being > > added, only from being used, based on monitoring / non-op status > > > +1. > It means that the admin can add the host, but the host will not be > operational until we get a positive indication from the attestation > service. > +1 if we want to test attestation only once, every time before host moves to up. the right place for it, imo, is InitVdsOnUpCommand if its periodic also after host is up, then it should be somewhere in the monitoring code > > > > > > > > > > > Does that make sense? > > > Doron and Ofri, what did you have in mind for this feature? > > > > > > Regards, > > > Oved > > > > > >> > > >> Best Regards, > > >> Dave Chen > > >> > > >> > > >> -----Original Message----- > > >> From: Doron Fediuck [mailto:dfediuck at redhat.com] > > >> Sent: Wednesday, April 10, 2013 8:03 PM > > >> To: Ofri Masad > > >> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan > > >> Subject: Re: minutes for sync up on Open Attestation integration > > >> with oVirt in 4/9 > > >> > > >> > > >> > > >> ----- Original Message ----- > > >>> From: "Ofri Masad" > > >>> To: "Gang Wei" > > >>> Cc: "Wei D Chen" , "Buddy Cao" > > >>> , "Lijuan Zhang" , > > >>> "Doron Fediuck" > > >>> Sent: Wednesday, April 10, 2013 2:23:57 PM > > >>> Subject: Re: minutes for sync up on Open Attestation integration > > >>> with oVirt in 4/9 > > >>> > > >>> Hi, > > >>> > > >>> answers inside the mail body. > > >>> > > >>> ----- Original Message ----- > > >>>> From: "Doron Fediuck" > > >>>> To: "Wei D Chen" > > >>>> Cc: "Gang Wei" , "Buddy Cao" > > >>>> , "Lijuan Zhang" , > > >>>> "Ofri Masad" > > >>>> Sent: Wednesday, April 10, 2013 12:12:26 PM > > >>>> Subject: Re: minutes for sync up on Open Attestation > > >>>> integration with oVirt in 4/9 > > >>>> > > >>>> Hi Dave, > > >>>> Adding Ofri to answer your questions. > > >>>> > > >>>> ----- Original Message ----- > > >>>>> From: "Wei D Chen" > > >>>>> To: "Gang Wei" , "Doron Fediuck" > > >>>>> , > > >>>>> "Buddy Cao" , "Lijuan Zhang" > > >>>>> > > >>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM > > >>>>> Subject: RE: minutes for sync up on Open Attestation > > >>>>> integration with oVirt in 4/9 > > >>>>> > > >>>>> Hi Doron, > > >>>>> > > >>>>> > > >>>>> iii. Then periodic trust check will be added into background > > >>>>> process > > >>>>> for > > >>>>> all existing hosts, once becoming non-trusted, mark it as > > >>>>> non-operational. > > >>>>> > > >>>>> - [Dave] Would you give me some details about the > > >>>>> ?background > > >>>>> process? mentioned in our sync up meeting? What?s the process > > >>>>> and where is related code? > > >>>>> > > >>> > > >>> The use Quartz Job to scheduled background processes. > > >>> An example can be found in: > > >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > > >>> 222) > > >>> > > >>> This code calls a method that is located in: > > >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt > > >>> /engin e/core/bll/quota/QuotaManager.java > > >>> (Line: 1000) > > >>> the @OnTimerMethodAnnotation annotation and the unique job name > > >>> connects the two in runtime. > > >>> > > >>> The job can query the attestation server for all the host and > > >>> then set untrusted hosts to Non-Operational. > > >>> the best way would be to call SetNonOperationalVdsCommand with a > > >>> new NonOperationalReason. > > >>> This command tries to migrate all VMs from the host and then set > > >>> it non operational. > > >>> (We need to think about non-migrational VMs - should we close > > >>> those VMs or keep the host running) > > >>> > > >> > > >> One more thing you may want to consider; If we get a positive > > >> response for a host which is currently non-operational, issue an > > >> activate command to try and make it operational again. > > >> Alternatively, you may decide not to handle it, assuming > > >> untrusted hosts can only be activated manually (see below Ofri's > > >> response on activating a host). > > >> > > >>>>> > > >>>>> iv. If admin fixed the non-operational node and try to switch it > > >>>>> to > > >>>>> operational mode again, a trust check will happen to gate the > > >>>>> switching. > > >>>>> > > >>>>> - [Dave] If there is a button provided from UI for checking > > >>>>> the > > >>>>> logic? or we need add an extra-button for attestation check only? > > >>>>> > > >>> > > >>> In the UI we already have the "Activate" option. What still > > >>> needs to be added is the check with the attestation provider to > > >>> make sure that if the cluster is defined 'Trusted'. If so, only > > >>> trusted host will succeed in the activate command (and, of > > >>> course, a proper Audit Log error in case the host failed to activate due to trust issue. > > >>> > > >>> the correct place to add this check would be in: > > >>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/org > > >>> /ovirt > > >>> /engine/core/vdsbroker/VdsManager.java:activate() > > >>> this is where the re-activation process begins. > > >>> > > >>>>> > > >>>>> Thanks very much. > > >>>>> > > >>>>> > > >>>>> > > >>>>> Best Regards, > > >>>>> Dave Chen > > >> _______________________________________________ > > >> 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 > _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel From deadhorseconsulting at gmail.com Mon Apr 15 15:41:33 2013 From: deadhorseconsulting at gmail.com (Dead Horse) Date: Mon, 15 Apr 2013 10:41:33 -0500 Subject: [Engine-devel] upgrade failing with latest master In-Reply-To: <1273669048.47013.1365880663823.JavaMail.root@redhat.com> References: <499700726.1036974.1365625954171.JavaMail.root@redhat.com> <269004897.1042115.1365627763231.JavaMail.root@redhat.com> <383901841.1348447.1365716007616.JavaMail.root@redhat.com> <1273669048.47013.1365880663823.JavaMail.root@redhat.com> Message-ID: Engine version I am attempting to upgrade was built from this commit: b4cc077888ba11871aa4837a73498a231050e2fc I built it same as always on a fully up to date FC17 VM. EG: Check out sources, cd /path/to/source/ make "rpm" I am unable to locate any .rpmnew in /etc after or before upgrade. - DHC On Sat, Apr 13, 2013 at 2:17 PM, Alon Bar-Lev wrote: > > Which version do you use? > Have you built it your-self? > Have you settled all .rpmnew you have in /etc? > > ----- Original Message ----- > > From: "Dead Horse" > > To: "Alon Bar-Lev" > > Cc: engine-devel at ovirt.org > > Sent: Friday, April 12, 2013 9:20:51 PM > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > Prior to engine-upgrade: > > ovirt-engine.service - oVirt Engine > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > enabled) > > Active: active (running) since Fri, 12 Apr 2013 13:11:16 -0500; > 1min > > 10s ago > > Main PID: 9023 (java) > > CGroup: name=systemd:/system/ovirt-engine.service > > ? 9023 engine-service -server -XX:+TieredCompilation -Xms... > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Started > > engine ... > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Starting > > engine... > > > > Stopping ovirt-engine service prior to engine-upgrade: > > ovirt-engine.service - oVirt Engine > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > enabled) > > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 13:12:51 > > -0500; 3s ago > > Process: 9141 ExecStop=/usr/bin/engine-service stop (code=exited, > > status=0/SUCCESS) > > Main PID: 9023 (code=exited, status=143) > > CGroup: name=systemd:/system/ovirt-engine.service > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Started > > engine ... > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Starting > > engine... > > Apr 12 13:12:50 ovirtfoo.ctt.med.ge.com engine-service[9141]: Waiting > up to > > 1... > > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: Stopped > > engine ... > > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: Stopping > > engine... > > > > After running engine-upgrade: > > ovirt-engine.service - oVirt Engine > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > enabled) > > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 13:18:22 > > -0500; 41s ago > > Main PID: 9168 (code=exited, status=143) > > CGroup: name=systemd:/system/ovirt-engine.service > > > > Apr 12 13:18:22 ovirtfoo.ctt.med.ge.com systemd[11198]: Failed at step > EXEC > > spawning /usr/bin/engine-service: No such file or directory > > > > After attemptining systemctl start ovirt-engine.service after > > engine-upgrade: > > ovirt-engine.service - oVirt Engine > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > enabled) > > Active: active (running) since Fri, 12 Apr 2013 13:19:43 -0500; 1s > ago > > Process: 11228 ExecStart=/usr/bin/engine-service start (code=exited, > > status=0/SUCCESS) > > Main PID: 11229 (java) > > CGroup: name=systemd:/system/ovirt-engine.service > > ? 11229 engine-service -server -XX:+TieredCompilation -Xms1g > > -Xmx1g -XX:PermSize=256m -XX:MaxPermSize=256m > > -Djava.net.preferIPv4Stack=tr... > > > > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: Started > > engine process 11229. > > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: Starting > > engine-service: [ OK ] > > > > > > - DHC > > > > > > > > > > On Thu, Apr 11, 2013 at 4:33 PM, Alon Bar-Lev wrote: > > > > > Please see what systemd has to say: > > > > > > # systemctl status ovirt-engine.service > > > > > > > > > And no, I never tried to backup/restore... sorry... > > > > > > ----- Original Message ----- > > > > From: "Dead Horse" > > > > To: "Alon Bar-Lev" > > > > Cc: engine-devel at ovirt.org > > > > Sent: Friday, April 12, 2013 12:28:01 AM > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > Rebuilt the engine on my FC17 build VM with the macro file above in > > > > "/etc/rpm/" > > > > Upon attempting upgrade on my FC17 upgrade test VM: > > > > I still get a failure to start the engine > > > > > > > > 013-04-11 16:06:37::ERROR::engine-upgrade::1328::root:: Traceback > (most > > > > recent call last): > > > > File "/bin/engine-upgrade", line 1321, in > > > > main(options) > > > > File "/bin/engine-upgrade", line 1293, in main > > > > runFunc([startEngine], MSG_INFO_START_ENGINE % engineService) > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > func() > > > > File "/bin/engine-upgrade", line 584, in startEngine > > > > output, rc = utils.execCmd(cmdList=cmd, failOnError=True, > > > > msg=MSG_ERR_FAILED_START_ENGINE_SERVICE) > > > > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 499, > in > > > > execCmd > > > > raise Exception(msg) > > > > Exception: Error: Can't start ovirt-engine > > > > > > > > Curiously is there a documented process somewhere for backing up data > > > from > > > > an FC17 ovirt install and doing a fresh install on a FC18 box then > > > > restoring the FC17 database + ovirt config data? > > > > > > > > Guessing it goes something like this: (someone please confirm) > > > > > > > > Back up the following directories and files: > > > > /etc/ovirt-engine > > > > /etc/pki/ovirt-engine > > > > /etc/pki/ovirt-engine-backups > > > > /var/lib/ovirt-engine/backups > > > > /var/lib/ovirt-engine/deployments > > > > /root/.rnd > > > > > > > > Dump a backup of the engine database > > > > > > > > Install ovirt-engine on FC18 system > > > > run engine-setup (answer questions same as prior install from FC17) > > > > upon completion of engine-setup stop the engine service > > > > restore all the above files and directories > > > > > > > > Drop the engine databse > > > > Restore the backed up engine database > > > > > > > > FC17 --> FC18 upgrade = icky esp. with ovirt involved as part of the > > > upgrade > > > > > > > > Thus it seems the easiest way to solve this is to bite the bullet and > > > move > > > > to FC18 providing the backup/restore works. > > > > > > > > - DHC > > > > > > > > > > > > On Wed, Apr 10, 2013 at 4:02 PM, Alon Bar-Lev > wrote: > > > > > > > > > > > > > > OK... the systemd macros are missing in fedora 17... > > > > > > > > > > Put the following file and rebuild. > > > > > I may need to add some workaround if many people still use > fedora-17 > > > for > > > > > master. > > > > > > > > > > Regards, > > > > > Alon > > > > > > > > > > /etc/rpm/macros.systemd-fc18 > > > > > --- > > > > > %systemd_post() \ > > > > > if [ $1 -eq 1 ] ; then \ > > > > > # Initial installation \ > > > > > /usr/bin/systemctl preset %{?*} >/dev/null 2>&1 || : \ > > > > > fi \ > > > > > %{nil} > > > > > > > > > > %systemd_preun() \ > > > > > if [ $1 -eq 0 ] ; then \ > > > > > # Package removal, not upgrade \ > > > > > /usr/bin/systemctl --no-reload disable %{?*} > /dev/null > 2>&1 > > > || : > > > > > \ > > > > > /usr/bin/systemctl stop %{?*} > /dev/null 2>&1 || : \ > > > > > fi \ > > > > > %{nil} > > > > > > > > > > %systemd_postun() \ > > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > > %{nil} > > > > > > > > > > %systemd_postun_with_restart() \ > > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > > if [ $1 -ge 1 ] ; then \ > > > > > # Package upgrade, not uninstall \ > > > > > /usr/bin/systemctl try-restart %{?*} >/dev/null 2>&1 || : \ > > > > > fi \ > > > > > %{nil} > > > > > --- > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Dead Horse" > > > > > > To: "Alon Bar-Lev" > > > > > > Cc: engine-devel at ovirt.org > > > > > > Sent: Wednesday, April 10, 2013 11:59:15 PM > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > > > > > Correct, FC17 > > > > > > - DHC > > > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 3:32 PM, Alon Bar-Lev > > > > wrote: > > > > > > > > > > > > > Is this fedora 17 or 18? > > > > > > > > > > > > > > I guess it is fedora 17. > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Dead Horse" > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > Sent: Wednesday, April 10, 2013 11:23:10 PM > > > > > > > > Subject: [Engine-devel] upgrade failing with latest master > > > > > > > > > > > > > > > > logs attached > > > > > > > > > > > > > > > > First attempt: > > > > > > > > 2013-04-10 13:57:32::ERROR::common_utils::355::root:: YUM: > FAIL: > > > > > Error in > > > > > > > > PREUN scriptlet in rpm package > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: > VERB: > > > > > Script > > > > > > > sink: > > > > > > > > /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control > > > > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > scriptlet > > > > > > > failed, > > > > > > > > exit status 1 > > > > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: > VERB: > > > > > Done: > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > > > > Second attempt: > > > > > > > > 2013-04-10 15:12:11::DEBUG::common_utils::347::root:: YUM: > VERB: > > > > > Building > > > > > > > > transaction > > > > > > > > 2013-04-10 15:12:12::ERROR::common_utils::355::root:: YUM: > FAIL: > > > > > > > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires > > > ovirt-engine = > > > > > > > > 3.3.0-14.fc17'] > > > > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::347::root:: YUM: > VERB: > > > > > > > Performing > > > > > > > > rollback > > > > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::1410::root:: > Locking > > > rpms > > > > > in > > > > > > > > yum-version-lock > > > > > > > > 2013-04-10 15:12:12::ERROR::engine-upgrade::1299::root:: > > > Traceback > > > > > (most > > > > > > > > recent call last): > > > > > > > > File "/bin/engine-upgrade", line 1292, in > > > > > > > > main(options) > > > > > > > > File "/bin/engine-upgrade", line 1142, in main > > > > > > > > runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) > > > > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > > > > func() > > > > > > > > File "/bin/engine-upgrade", line 310, in begin > > > > > > > > self.emptyTransaction = not self._miniyum.buildTransaction() > > > > > > > > File "/usr/share/ovirt-engine/scripts/miniyum.py", line 761, > in > > > > > > > > buildTransaction > > > > > > > > raise yum.Errors.YumBaseError(msg) > > > > > > > > YumBaseError: [u'ovirt-engine-backend-3.3.0-14.fc17.noarch > > > requires > > > > > > > > ovirt-engine = 3.3.0-14.fc17'] > > > > > > > > > > > > > > > > Realizing things were now hosed: > > > > > > > > [root at ovirtfoo /]# yum erase ovirt-* otopi-* > > > > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, > > > versionlock > > > > > > > > Resolving Dependencies > > > > > > > > --> Running transaction check > > > > > > > > ---> Package otopi.noarch 0:3.3.0-15.fc17 will be erased > > > > > > > > ---> Package otopi-java.noarch 0:3.3.0-15.fc17 will be erased > > > > > > > > ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 will be > erased > > > > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > will be > > > > > erased > > > > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > will be > > > > > erased > > > > > > > > ---> Package ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 will > be > > > erased > > > > > > > > ---> Package ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > will > > > be > > > > > erased > > > > > > > > ---> Package ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > will be > > > > > erased > > > > > > > > ---> Package ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 will > be > > > erased > > > > > > > > ---> Package ovirt-engine-setup.noarch 0:3.3.0-15.fc17 will > be > > > erased > > > > > > > > ---> Package ovirt-engine-tools.noarch 0:3.3.0-14.fc17 will > be > > > erased > > > > > > > > ---> Package ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > will > > > be > > > > > > > erased > > > > > > > > ---> Package ovirt-engine-webadmin-portal.noarch > 0:3.3.0-14.fc17 > > > > > will be > > > > > > > > erased > > > > > > > > ---> Package ovirt-host-deploy.noarch 0:3.3.0-15.fc17 will be > > > erased > > > > > > > > ---> Package ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > will > > > be > > > > > erased > > > > > > > > ---> Package ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > will be > > > > > erased > > > > > > > > ---> Package ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 will > be > > > erased > > > > > > > > ---> Package ovirt-log-collector.noarch 0:3.3.0-15.fc17 will > be > > > > > erased > > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > Removing: > > > > > > > > otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k > > > > > > > > otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k > > > > > > > > ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine 1.3 M > > > > > > > > ovirt-engine-backend noarch 3.3.0-14.fc17 @ovirt-engine 20 M > > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > > > > > > > ovirt-engine-cli noarch 3.3.0.1-15.fc17 @ovirt-engine 557 k > > > > > > > > ovirt-engine-dbscripts noarch 3.3.0-14.fc17 @ovirt-engine > 816 k > > > > > > > > ovirt-engine-restapi noarch 3.3.0-14.fc17 @ovirt-engine 1.0 M > > > > > > > > ovirt-engine-sdk noarch 3.3.0.1-15.fc17 @ovirt-engine 3.1 M > > > > > > > > ovirt-engine-setup noarch 3.3.0-15.fc17 @ovirt-engine 653 k > > > > > > > > ovirt-engine-tools noarch 3.3.0-14.fc17 @ovirt-engine 178 k > > > > > > > > ovirt-engine-userportal noarch 3.3.0-14.fc17 @ovirt-engine > 23 M > > > > > > > > ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 > @ovirt-engine > > > 32 M > > > > > > > > ovirt-host-deploy noarch 3.3.0-15.fc17 @ovirt-engine 211 k > > > > > > > > ovirt-host-deploy-java noarch 3.3.0-15.fc17 @ovirt-engine 11 > k > > > > > > > > ovirt-image-uploader noarch 3.3.0-15.fc17 @ovirt-engine 923 k > > > > > > > > ovirt-iso-uploader noarch 3.3.0-15.fc17 @ovirt-engine 98 k > > > > > > > > ovirt-log-collector noarch 3.3.0-15.fc17 @ovirt-engine 133 k > > > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > Remove 18 Packages > > > > > > > > > > > > > > > > Installed size: 104 M > > > > > > > > Is this ok [y/N]: y > > > > > > > > Downloading Packages: > > > > > > > > Running Transaction Check > > > > > > > > Running Transaction Test > > > > > > > > Transaction Test Succeeded > > > > > > > > Running Transaction > > > > > > > > Erasing : ovirt-engine-backend.noarch 1/18 > > > > > > > > Erasing : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 2/18 > > > > > > > > Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch 3/18 > > > > > > > > Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch 4/18 > > > > > > > > Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch 5/18 > > > > > > > > Erasing : ovirt-engine-userportal-3.3.0-14.fc17.noarch 6/18 > > > > > > > > Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 > > > > > > > > warning: /etc/ovirt-engine/engine.conf saved as > > > > > > > > /etc/ovirt-engine/engine.conf.rpmsave > > > > > > > > Erasing : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > 8/18 > > > > > > > > Erasing : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 9/18 > > > > > > > > Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 > > > > > > > > Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch 11/18 > > > > > > > > Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > > > > > > warning: /etc/ovirt-engine/imageuploader.conf saved as > > > > > > > > /etc/ovirt-engine/imageuploader.conf.rpmsave > > > > > > > > Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > > > > > warning: /etc/ovirt-engine/isouploader.conf saved as > > > > > > > > /etc/ovirt-engine/isouploader.conf.rpmsave > > > > > > > > Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch 14/18 > > > > > > > > warning: /etc/ovirt-engine/logcollector.conf saved as > > > > > > > > /etc/ovirt-engine/logcollector.conf.rpmsave > > > > > > > > Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 15/18 > > > > > > > > Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 16/18 > > > > > > > > Erasing : otopi-3.3.0-15.fc17.noarch 17/18 > > > > > > > > Error in PREUN scriptlet in rpm package ovirt-engine-backend > > > > > > > > /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control > > > > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > scriptlet > > > > > > > failed, > > > > > > > > exit status 1 > > > > > > > > Verifying : otopi-3.3.0-15.fc17.noarch 1/18 > > > > > > > > Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 > > > > > > > > Verifying : ovirt-log-collector-3.3.0-15.fc17.noarch 3/18 > > > > > > > > Verifying : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > > > 4/18 > > > > > > > > Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch 5/18 > > > > > > > > Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch 6/18 > > > > > > > > Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch 7/18 > > > > > > > > Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 8/18 > > > > > > > > Verifying : ovirt-engine-restapi-3.3.0-14.fc17.noarch 9/18 > > > > > > > > Verifying : ovirt-engine-userportal-3.3.0-14.fc17.noarch > 10/18 > > > > > > > > Verifying : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 11/18 > > > > > > > > Verifying : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > > > > > > Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > > > > > Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 14/18 > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch was supposed to be > > > removed > > > > > but > > > > > > > is > > > > > > > > not! > > > > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 15/18 > > > > > > > > Verifying : ovirt-engine-backend-3.3.0-14.fc17.noarch 16/18 > > > > > > > > Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 > > > > > > > > Verifying : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 18/18 > > > > > > > > > > > > > > > > Removed: > > > > > > > > otopi.noarch 0:3.3.0-15.fc17 > > > > > > > > otopi-java.noarch 0:3.3.0-15.fc17 > > > > > > > > ovirt-engine.noarch 0:3.3.0-14.fc17 > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > > > > > > > > ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > > > > > > > > ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > > > > > > > > ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > > > > > > > > ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > > > > > > > > ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > > > > > > > > ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > > > > > > > > ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > > > > > > > > ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > > > > > > > ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > > > > > > > > ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > > > > > > > > ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > > ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > > ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > Failed: > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > Complete! > > > > > > > > [root at ovirtfoo /]# rpm -qa | grep oto > > > > > > > > protobuf-java-2.4.1-12.fc17.x86_64 > > > > > > > > libgphoto2-2.4.14-1.fc17.x86_64 > > > > > > > > [root at ovirtfoo /]# rpm -qa | grep ovirt > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > [root at ovirtfoo /]# yum erase > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, > > > versionlock > > > > > > > > Resolving Dependencies > > > > > > > > --> Running transaction check > > > > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > will be > > > > > erased > > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > Removing: > > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > Remove 1 Package > > > > > > > > > > > > > > > > Installed size: 20 M > > > > > > > > Is this ok [y/N]: y > > > > > > > > Downloading Packages: > > > > > > > > Running Transaction Check > > > > > > > > Running Transaction Test > > > > > > > > Transaction Test Succeeded > > > > > > > > Running Transaction > > > > > > > > Error in PREUN scriptlet in rpm package > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control > > > > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > scriptlet > > > > > > > failed, > > > > > > > > exit status 1 > > > > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 1/1 > > > > > > > > > > > > > > > > Failed: > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > Complete! > > > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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: From alonbl at redhat.com Mon Apr 15 16:10:52 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 15 Apr 2013 12:10:52 -0400 (EDT) Subject: [Engine-devel] upgrade failing with latest master In-Reply-To: References: <269004897.1042115.1365627763231.JavaMail.root@redhat.com> <383901841.1348447.1365716007616.JavaMail.root@redhat.com> <1273669048.47013.1365880663823.JavaMail.root@redhat.com> Message-ID: <1446063899.366491.1366042252302.JavaMail.root@redhat.com> Oh... it is before I rewrote the engine service. I thought that you facing issue after the re-write. Can you please give a try to the master HEAD? ----- Original Message ----- > From: "Dead Horse" > To: "Alon Bar-Lev" > Cc: engine-devel at ovirt.org > Sent: Monday, April 15, 2013 6:41:33 PM > Subject: Re: [Engine-devel] upgrade failing with latest master > > Engine version I am attempting to upgrade was built from this commit: > b4cc077888ba11871aa4837a73498a231050e2fc > I built it same as always on a fully up to date FC17 VM. > EG: Check out sources, cd /path/to/source/ make "rpm" > > I am unable to locate any .rpmnew in /etc after or before upgrade. > > - DHC > > > On Sat, Apr 13, 2013 at 2:17 PM, Alon Bar-Lev wrote: > > > > > Which version do you use? > > Have you built it your-self? > > Have you settled all .rpmnew you have in /etc? > > > > ----- Original Message ----- > > > From: "Dead Horse" > > > To: "Alon Bar-Lev" > > > Cc: engine-devel at ovirt.org > > > Sent: Friday, April 12, 2013 9:20:51 PM > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > Prior to engine-upgrade: > > > ovirt-engine.service - oVirt Engine > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > enabled) > > > Active: active (running) since Fri, 12 Apr 2013 13:11:16 -0500; > > 1min > > > 10s ago > > > Main PID: 9023 (java) > > > CGroup: name=systemd:/system/ovirt-engine.service > > > ? 9023 engine-service -server -XX:+TieredCompilation -Xms... > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Started > > > engine ... > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Starting > > > engine... > > > > > > Stopping ovirt-engine service prior to engine-upgrade: > > > ovirt-engine.service - oVirt Engine > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > enabled) > > > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 13:12:51 > > > -0500; 3s ago > > > Process: 9141 ExecStop=/usr/bin/engine-service stop (code=exited, > > > status=0/SUCCESS) > > > Main PID: 9023 (code=exited, status=143) > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Started > > > engine ... > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Starting > > > engine... > > > Apr 12 13:12:50 ovirtfoo.ctt.med.ge.com engine-service[9141]: Waiting > > up to > > > 1... > > > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: Stopped > > > engine ... > > > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: Stopping > > > engine... > > > > > > After running engine-upgrade: > > > ovirt-engine.service - oVirt Engine > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > enabled) > > > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 13:18:22 > > > -0500; 41s ago > > > Main PID: 9168 (code=exited, status=143) > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > Apr 12 13:18:22 ovirtfoo.ctt.med.ge.com systemd[11198]: Failed at step > > EXEC > > > spawning /usr/bin/engine-service: No such file or directory > > > > > > After attemptining systemctl start ovirt-engine.service after > > > engine-upgrade: > > > ovirt-engine.service - oVirt Engine > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > enabled) > > > Active: active (running) since Fri, 12 Apr 2013 13:19:43 -0500; 1s > > ago > > > Process: 11228 ExecStart=/usr/bin/engine-service start (code=exited, > > > status=0/SUCCESS) > > > Main PID: 11229 (java) > > > CGroup: name=systemd:/system/ovirt-engine.service > > > ? 11229 engine-service -server -XX:+TieredCompilation -Xms1g > > > -Xmx1g -XX:PermSize=256m -XX:MaxPermSize=256m > > > -Djava.net.preferIPv4Stack=tr... > > > > > > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: Started > > > engine process 11229. > > > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: Starting > > > engine-service: [ OK ] > > > > > > > > > - DHC > > > > > > > > > > > > > > > On Thu, Apr 11, 2013 at 4:33 PM, Alon Bar-Lev wrote: > > > > > > > Please see what systemd has to say: > > > > > > > > # systemctl status ovirt-engine.service > > > > > > > > > > > > And no, I never tried to backup/restore... sorry... > > > > > > > > ----- Original Message ----- > > > > > From: "Dead Horse" > > > > > To: "Alon Bar-Lev" > > > > > Cc: engine-devel at ovirt.org > > > > > Sent: Friday, April 12, 2013 12:28:01 AM > > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > > > Rebuilt the engine on my FC17 build VM with the macro file above in > > > > > "/etc/rpm/" > > > > > Upon attempting upgrade on my FC17 upgrade test VM: > > > > > I still get a failure to start the engine > > > > > > > > > > 013-04-11 16:06:37::ERROR::engine-upgrade::1328::root:: Traceback > > (most > > > > > recent call last): > > > > > File "/bin/engine-upgrade", line 1321, in > > > > > main(options) > > > > > File "/bin/engine-upgrade", line 1293, in main > > > > > runFunc([startEngine], MSG_INFO_START_ENGINE % engineService) > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > func() > > > > > File "/bin/engine-upgrade", line 584, in startEngine > > > > > output, rc = utils.execCmd(cmdList=cmd, failOnError=True, > > > > > msg=MSG_ERR_FAILED_START_ENGINE_SERVICE) > > > > > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 499, > > in > > > > > execCmd > > > > > raise Exception(msg) > > > > > Exception: Error: Can't start ovirt-engine > > > > > > > > > > Curiously is there a documented process somewhere for backing up data > > > > from > > > > > an FC17 ovirt install and doing a fresh install on a FC18 box then > > > > > restoring the FC17 database + ovirt config data? > > > > > > > > > > Guessing it goes something like this: (someone please confirm) > > > > > > > > > > Back up the following directories and files: > > > > > /etc/ovirt-engine > > > > > /etc/pki/ovirt-engine > > > > > /etc/pki/ovirt-engine-backups > > > > > /var/lib/ovirt-engine/backups > > > > > /var/lib/ovirt-engine/deployments > > > > > /root/.rnd > > > > > > > > > > Dump a backup of the engine database > > > > > > > > > > Install ovirt-engine on FC18 system > > > > > run engine-setup (answer questions same as prior install from FC17) > > > > > upon completion of engine-setup stop the engine service > > > > > restore all the above files and directories > > > > > > > > > > Drop the engine databse > > > > > Restore the backed up engine database > > > > > > > > > > FC17 --> FC18 upgrade = icky esp. with ovirt involved as part of the > > > > upgrade > > > > > > > > > > Thus it seems the easiest way to solve this is to bite the bullet and > > > > move > > > > > to FC18 providing the backup/restore works. > > > > > > > > > > - DHC > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 4:02 PM, Alon Bar-Lev > > wrote: > > > > > > > > > > > > > > > > > OK... the systemd macros are missing in fedora 17... > > > > > > > > > > > > Put the following file and rebuild. > > > > > > I may need to add some workaround if many people still use > > fedora-17 > > > > for > > > > > > master. > > > > > > > > > > > > Regards, > > > > > > Alon > > > > > > > > > > > > /etc/rpm/macros.systemd-fc18 > > > > > > --- > > > > > > %systemd_post() \ > > > > > > if [ $1 -eq 1 ] ; then \ > > > > > > # Initial installation \ > > > > > > /usr/bin/systemctl preset %{?*} >/dev/null 2>&1 || : \ > > > > > > fi \ > > > > > > %{nil} > > > > > > > > > > > > %systemd_preun() \ > > > > > > if [ $1 -eq 0 ] ; then \ > > > > > > # Package removal, not upgrade \ > > > > > > /usr/bin/systemctl --no-reload disable %{?*} > /dev/null > > 2>&1 > > > > || : > > > > > > \ > > > > > > /usr/bin/systemctl stop %{?*} > /dev/null 2>&1 || : \ > > > > > > fi \ > > > > > > %{nil} > > > > > > > > > > > > %systemd_postun() \ > > > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > > > %{nil} > > > > > > > > > > > > %systemd_postun_with_restart() \ > > > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > > > if [ $1 -ge 1 ] ; then \ > > > > > > # Package upgrade, not uninstall \ > > > > > > /usr/bin/systemctl try-restart %{?*} >/dev/null 2>&1 || : \ > > > > > > fi \ > > > > > > %{nil} > > > > > > --- > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Dead Horse" > > > > > > > To: "Alon Bar-Lev" > > > > > > > Cc: engine-devel at ovirt.org > > > > > > > Sent: Wednesday, April 10, 2013 11:59:15 PM > > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > > > > > > > Correct, FC17 > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 3:32 PM, Alon Bar-Lev > > > > > > wrote: > > > > > > > > > > > > > > > Is this fedora 17 or 18? > > > > > > > > > > > > > > > > I guess it is fedora 17. > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Dead Horse" > > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > > Sent: Wednesday, April 10, 2013 11:23:10 PM > > > > > > > > > Subject: [Engine-devel] upgrade failing with latest master > > > > > > > > > > > > > > > > > > logs attached > > > > > > > > > > > > > > > > > > First attempt: > > > > > > > > > 2013-04-10 13:57:32::ERROR::common_utils::355::root:: YUM: > > FAIL: > > > > > > Error in > > > > > > > > > PREUN scriptlet in rpm package > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: > > VERB: > > > > > > Script > > > > > > > > sink: > > > > > > > > > /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control > > > > > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > scriptlet > > > > > > > > failed, > > > > > > > > > exit status 1 > > > > > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: > > VERB: > > > > > > Done: > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > > > > > > Second attempt: > > > > > > > > > 2013-04-10 15:12:11::DEBUG::common_utils::347::root:: YUM: > > VERB: > > > > > > Building > > > > > > > > > transaction > > > > > > > > > 2013-04-10 15:12:12::ERROR::common_utils::355::root:: YUM: > > FAIL: > > > > > > > > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires > > > > ovirt-engine = > > > > > > > > > 3.3.0-14.fc17'] > > > > > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::347::root:: YUM: > > VERB: > > > > > > > > Performing > > > > > > > > > rollback > > > > > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::1410::root:: > > Locking > > > > rpms > > > > > > in > > > > > > > > > yum-version-lock > > > > > > > > > 2013-04-10 15:12:12::ERROR::engine-upgrade::1299::root:: > > > > Traceback > > > > > > (most > > > > > > > > > recent call last): > > > > > > > > > File "/bin/engine-upgrade", line 1292, in > > > > > > > > > main(options) > > > > > > > > > File "/bin/engine-upgrade", line 1142, in main > > > > > > > > > runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) > > > > > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > > > > > func() > > > > > > > > > File "/bin/engine-upgrade", line 310, in begin > > > > > > > > > self.emptyTransaction = not self._miniyum.buildTransaction() > > > > > > > > > File "/usr/share/ovirt-engine/scripts/miniyum.py", line 761, > > in > > > > > > > > > buildTransaction > > > > > > > > > raise yum.Errors.YumBaseError(msg) > > > > > > > > > YumBaseError: [u'ovirt-engine-backend-3.3.0-14.fc17.noarch > > > > requires > > > > > > > > > ovirt-engine = 3.3.0-14.fc17'] > > > > > > > > > > > > > > > > > > Realizing things were now hosed: > > > > > > > > > [root at ovirtfoo /]# yum erase ovirt-* otopi-* > > > > > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, > > > > versionlock > > > > > > > > > Resolving Dependencies > > > > > > > > > --> Running transaction check > > > > > > > > > ---> Package otopi.noarch 0:3.3.0-15.fc17 will be erased > > > > > > > > > ---> Package otopi-java.noarch 0:3.3.0-15.fc17 will be erased > > > > > > > > > ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 will be > > erased > > > > > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > > will be > > > > > > erased > > > > > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > will be > > > > > > erased > > > > > > > > > ---> Package ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 will > > be > > > > erased > > > > > > > > > ---> Package ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > > will > > > > be > > > > > > erased > > > > > > > > > ---> Package ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > > will be > > > > > > erased > > > > > > > > > ---> Package ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 will > > be > > > > erased > > > > > > > > > ---> Package ovirt-engine-setup.noarch 0:3.3.0-15.fc17 will > > be > > > > erased > > > > > > > > > ---> Package ovirt-engine-tools.noarch 0:3.3.0-14.fc17 will > > be > > > > erased > > > > > > > > > ---> Package ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > > will > > > > be > > > > > > > > erased > > > > > > > > > ---> Package ovirt-engine-webadmin-portal.noarch > > 0:3.3.0-14.fc17 > > > > > > will be > > > > > > > > > erased > > > > > > > > > ---> Package ovirt-host-deploy.noarch 0:3.3.0-15.fc17 will be > > > > erased > > > > > > > > > ---> Package ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > > will > > > > be > > > > > > erased > > > > > > > > > ---> Package ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > > will be > > > > > > erased > > > > > > > > > ---> Package ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 will > > be > > > > erased > > > > > > > > > ---> Package ovirt-log-collector.noarch 0:3.3.0-15.fc17 will > > be > > > > > > erased > > > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > Removing: > > > > > > > > > otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k > > > > > > > > > otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k > > > > > > > > > ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine 1.3 M > > > > > > > > > ovirt-engine-backend noarch 3.3.0-14.fc17 @ovirt-engine 20 M > > > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > > > > > > > > ovirt-engine-cli noarch 3.3.0.1-15.fc17 @ovirt-engine 557 k > > > > > > > > > ovirt-engine-dbscripts noarch 3.3.0-14.fc17 @ovirt-engine > > 816 k > > > > > > > > > ovirt-engine-restapi noarch 3.3.0-14.fc17 @ovirt-engine 1.0 M > > > > > > > > > ovirt-engine-sdk noarch 3.3.0.1-15.fc17 @ovirt-engine 3.1 M > > > > > > > > > ovirt-engine-setup noarch 3.3.0-15.fc17 @ovirt-engine 653 k > > > > > > > > > ovirt-engine-tools noarch 3.3.0-14.fc17 @ovirt-engine 178 k > > > > > > > > > ovirt-engine-userportal noarch 3.3.0-14.fc17 @ovirt-engine > > 23 M > > > > > > > > > ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 > > @ovirt-engine > > > > 32 M > > > > > > > > > ovirt-host-deploy noarch 3.3.0-15.fc17 @ovirt-engine 211 k > > > > > > > > > ovirt-host-deploy-java noarch 3.3.0-15.fc17 @ovirt-engine 11 > > k > > > > > > > > > ovirt-image-uploader noarch 3.3.0-15.fc17 @ovirt-engine 923 k > > > > > > > > > ovirt-iso-uploader noarch 3.3.0-15.fc17 @ovirt-engine 98 k > > > > > > > > > ovirt-log-collector noarch 3.3.0-15.fc17 @ovirt-engine 133 k > > > > > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > Remove 18 Packages > > > > > > > > > > > > > > > > > > Installed size: 104 M > > > > > > > > > Is this ok [y/N]: y > > > > > > > > > Downloading Packages: > > > > > > > > > Running Transaction Check > > > > > > > > > Running Transaction Test > > > > > > > > > Transaction Test Succeeded > > > > > > > > > Running Transaction > > > > > > > > > Erasing : ovirt-engine-backend.noarch 1/18 > > > > > > > > > Erasing : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 2/18 > > > > > > > > > Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch 3/18 > > > > > > > > > Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch 4/18 > > > > > > > > > Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch 5/18 > > > > > > > > > Erasing : ovirt-engine-userportal-3.3.0-14.fc17.noarch 6/18 > > > > > > > > > Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 > > > > > > > > > warning: /etc/ovirt-engine/engine.conf saved as > > > > > > > > > /etc/ovirt-engine/engine.conf.rpmsave > > > > > > > > > Erasing : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > > 8/18 > > > > > > > > > Erasing : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 9/18 > > > > > > > > > Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 > > > > > > > > > Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch 11/18 > > > > > > > > > Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > > > > > > > warning: /etc/ovirt-engine/imageuploader.conf saved as > > > > > > > > > /etc/ovirt-engine/imageuploader.conf.rpmsave > > > > > > > > > Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > > > > > > warning: /etc/ovirt-engine/isouploader.conf saved as > > > > > > > > > /etc/ovirt-engine/isouploader.conf.rpmsave > > > > > > > > > Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch 14/18 > > > > > > > > > warning: /etc/ovirt-engine/logcollector.conf saved as > > > > > > > > > /etc/ovirt-engine/logcollector.conf.rpmsave > > > > > > > > > Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 15/18 > > > > > > > > > Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 16/18 > > > > > > > > > Erasing : otopi-3.3.0-15.fc17.noarch 17/18 > > > > > > > > > Error in PREUN scriptlet in rpm package ovirt-engine-backend > > > > > > > > > /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control > > > > > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > scriptlet > > > > > > > > failed, > > > > > > > > > exit status 1 > > > > > > > > > Verifying : otopi-3.3.0-15.fc17.noarch 1/18 > > > > > > > > > Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 > > > > > > > > > Verifying : ovirt-log-collector-3.3.0-15.fc17.noarch 3/18 > > > > > > > > > Verifying : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > > > > 4/18 > > > > > > > > > Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch 5/18 > > > > > > > > > Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch 6/18 > > > > > > > > > Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch 7/18 > > > > > > > > > Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 8/18 > > > > > > > > > Verifying : ovirt-engine-restapi-3.3.0-14.fc17.noarch 9/18 > > > > > > > > > Verifying : ovirt-engine-userportal-3.3.0-14.fc17.noarch > > 10/18 > > > > > > > > > Verifying : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 11/18 > > > > > > > > > Verifying : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > > > > > > > Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > > > > > > Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 14/18 > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch was supposed to be > > > > removed > > > > > > but > > > > > > > > is > > > > > > > > > not! > > > > > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 15/18 > > > > > > > > > Verifying : ovirt-engine-backend-3.3.0-14.fc17.noarch 16/18 > > > > > > > > > Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 > > > > > > > > > Verifying : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 18/18 > > > > > > > > > > > > > > > > > > Removed: > > > > > > > > > otopi.noarch 0:3.3.0-15.fc17 > > > > > > > > > otopi-java.noarch 0:3.3.0-15.fc17 > > > > > > > > > ovirt-engine.noarch 0:3.3.0-14.fc17 > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > > > > > > > > > ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > > > > > > > > > ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > > > > > > > > > ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > > > > > > > > > ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > > > > > > > > > ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > > > > > > > > > ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > > > > > > > > > ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > > > > > > > > > ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > > > > > > > > ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > > > > > > > > > ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > > > > > > > > > ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > > > ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > > > ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > Failed: > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > Complete! > > > > > > > > > [root at ovirtfoo /]# rpm -qa | grep oto > > > > > > > > > protobuf-java-2.4.1-12.fc17.x86_64 > > > > > > > > > libgphoto2-2.4.14-1.fc17.x86_64 > > > > > > > > > [root at ovirtfoo /]# rpm -qa | grep ovirt > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > [root at ovirtfoo /]# yum erase > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, > > > > versionlock > > > > > > > > > Resolving Dependencies > > > > > > > > > --> Running transaction check > > > > > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > will be > > > > > > erased > > > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > Removing: > > > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 M > > > > > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > Remove 1 Package > > > > > > > > > > > > > > > > > > Installed size: 20 M > > > > > > > > > Is this ok [y/N]: y > > > > > > > > > Downloading Packages: > > > > > > > > > Running Transaction Check > > > > > > > > > Running Transaction Test > > > > > > > > > Transaction Test Succeeded > > > > > > > > > Running Transaction > > > > > > > > > Error in PREUN scriptlet in rpm package > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control > > > > > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > scriptlet > > > > > > > > failed, > > > > > > > > > exit status 1 > > > > > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 1/1 > > > > > > > > > > > > > > > > > > Failed: > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > Complete! > > > > > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Engine-devel mailing list > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From alonbl at redhat.com Mon Apr 15 16:13:20 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 15 Apr 2013 12:13:20 -0400 (EDT) Subject: [Engine-devel] upgrade failing with latest master In-Reply-To: <1446063899.366491.1366042252302.JavaMail.root@redhat.com> References: <269004897.1042115.1365627763231.JavaMail.root@redhat.com> <383901841.1348447.1365716007616.JavaMail.root@redhat.com> <1273669048.47013.1365880663823.JavaMail.root@redhat.com> <1446063899.366491.1366042252302.JavaMail.root@redhat.com> Message-ID: <5152300.367225.1366042400592.JavaMail.root@redhat.com> BTW: best is to use fedora-18... If not, please put the attached file at /etc/rpm before packaging. ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Dead Horse" > Cc: engine-devel at ovirt.org > Sent: Monday, April 15, 2013 7:10:52 PM > Subject: Re: [Engine-devel] upgrade failing with latest master > > Oh... it is before I rewrote the engine service. > I thought that you facing issue after the re-write. > Can you please give a try to the master HEAD? > > ----- Original Message ----- > > From: "Dead Horse" > > To: "Alon Bar-Lev" > > Cc: engine-devel at ovirt.org > > Sent: Monday, April 15, 2013 6:41:33 PM > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > Engine version I am attempting to upgrade was built from this commit: > > b4cc077888ba11871aa4837a73498a231050e2fc > > I built it same as always on a fully up to date FC17 VM. > > EG: Check out sources, cd /path/to/source/ make "rpm" > > > > I am unable to locate any .rpmnew in /etc after or before upgrade. > > > > - DHC > > > > > > On Sat, Apr 13, 2013 at 2:17 PM, Alon Bar-Lev wrote: > > > > > > > > Which version do you use? > > > Have you built it your-self? > > > Have you settled all .rpmnew you have in /etc? > > > > > > ----- Original Message ----- > > > > From: "Dead Horse" > > > > To: "Alon Bar-Lev" > > > > Cc: engine-devel at ovirt.org > > > > Sent: Friday, April 12, 2013 9:20:51 PM > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > Prior to engine-upgrade: > > > > ovirt-engine.service - oVirt Engine > > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > > enabled) > > > > Active: active (running) since Fri, 12 Apr 2013 13:11:16 -0500; > > > 1min > > > > 10s ago > > > > Main PID: 9023 (java) > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > ? 9023 engine-service -server -XX:+TieredCompilation -Xms... > > > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Started > > > > engine ... > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Starting > > > > engine... > > > > > > > > Stopping ovirt-engine service prior to engine-upgrade: > > > > ovirt-engine.service - oVirt Engine > > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > > enabled) > > > > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 > > > > 13:12:51 > > > > -0500; 3s ago > > > > Process: 9141 ExecStop=/usr/bin/engine-service stop (code=exited, > > > > status=0/SUCCESS) > > > > Main PID: 9023 (code=exited, status=143) > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Started > > > > engine ... > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: Starting > > > > engine... > > > > Apr 12 13:12:50 ovirtfoo.ctt.med.ge.com engine-service[9141]: Waiting > > > up to > > > > 1... > > > > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: Stopped > > > > engine ... > > > > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: Stopping > > > > engine... > > > > > > > > After running engine-upgrade: > > > > ovirt-engine.service - oVirt Engine > > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > > enabled) > > > > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 > > > > 13:18:22 > > > > -0500; 41s ago > > > > Main PID: 9168 (code=exited, status=143) > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > > > Apr 12 13:18:22 ovirtfoo.ctt.med.ge.com systemd[11198]: Failed at step > > > EXEC > > > > spawning /usr/bin/engine-service: No such file or directory > > > > > > > > After attemptining systemctl start ovirt-engine.service after > > > > engine-upgrade: > > > > ovirt-engine.service - oVirt Engine > > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > > enabled) > > > > Active: active (running) since Fri, 12 Apr 2013 13:19:43 -0500; > > > > 1s > > > ago > > > > Process: 11228 ExecStart=/usr/bin/engine-service start > > > > (code=exited, > > > > status=0/SUCCESS) > > > > Main PID: 11229 (java) > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > ? 11229 engine-service -server -XX:+TieredCompilation -Xms1g > > > > -Xmx1g -XX:PermSize=256m -XX:MaxPermSize=256m > > > > -Djava.net.preferIPv4Stack=tr... > > > > > > > > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: Started > > > > engine process 11229. > > > > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: Starting > > > > engine-service: [ OK ] > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > On Thu, Apr 11, 2013 at 4:33 PM, Alon Bar-Lev > > > > wrote: > > > > > > > > > Please see what systemd has to say: > > > > > > > > > > # systemctl status ovirt-engine.service > > > > > > > > > > > > > > > And no, I never tried to backup/restore... sorry... > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Dead Horse" > > > > > > To: "Alon Bar-Lev" > > > > > > Cc: engine-devel at ovirt.org > > > > > > Sent: Friday, April 12, 2013 12:28:01 AM > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > > > > > Rebuilt the engine on my FC17 build VM with the macro file above in > > > > > > "/etc/rpm/" > > > > > > Upon attempting upgrade on my FC17 upgrade test VM: > > > > > > I still get a failure to start the engine > > > > > > > > > > > > 013-04-11 16:06:37::ERROR::engine-upgrade::1328::root:: Traceback > > > (most > > > > > > recent call last): > > > > > > File "/bin/engine-upgrade", line 1321, in > > > > > > main(options) > > > > > > File "/bin/engine-upgrade", line 1293, in main > > > > > > runFunc([startEngine], MSG_INFO_START_ENGINE % engineService) > > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > > func() > > > > > > File "/bin/engine-upgrade", line 584, in startEngine > > > > > > output, rc = utils.execCmd(cmdList=cmd, failOnError=True, > > > > > > msg=MSG_ERR_FAILED_START_ENGINE_SERVICE) > > > > > > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 499, > > > in > > > > > > execCmd > > > > > > raise Exception(msg) > > > > > > Exception: Error: Can't start ovirt-engine > > > > > > > > > > > > Curiously is there a documented process somewhere for backing up > > > > > > data > > > > > from > > > > > > an FC17 ovirt install and doing a fresh install on a FC18 box then > > > > > > restoring the FC17 database + ovirt config data? > > > > > > > > > > > > Guessing it goes something like this: (someone please confirm) > > > > > > > > > > > > Back up the following directories and files: > > > > > > /etc/ovirt-engine > > > > > > /etc/pki/ovirt-engine > > > > > > /etc/pki/ovirt-engine-backups > > > > > > /var/lib/ovirt-engine/backups > > > > > > /var/lib/ovirt-engine/deployments > > > > > > /root/.rnd > > > > > > > > > > > > Dump a backup of the engine database > > > > > > > > > > > > Install ovirt-engine on FC18 system > > > > > > run engine-setup (answer questions same as prior install from FC17) > > > > > > upon completion of engine-setup stop the engine service > > > > > > restore all the above files and directories > > > > > > > > > > > > Drop the engine databse > > > > > > Restore the backed up engine database > > > > > > > > > > > > FC17 --> FC18 upgrade = icky esp. with ovirt involved as part of > > > > > > the > > > > > upgrade > > > > > > > > > > > > Thus it seems the easiest way to solve this is to bite the bullet > > > > > > and > > > > > move > > > > > > to FC18 providing the backup/restore works. > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 4:02 PM, Alon Bar-Lev > > > wrote: > > > > > > > > > > > > > > > > > > > > OK... the systemd macros are missing in fedora 17... > > > > > > > > > > > > > > Put the following file and rebuild. > > > > > > > I may need to add some workaround if many people still use > > > fedora-17 > > > > > for > > > > > > > master. > > > > > > > > > > > > > > Regards, > > > > > > > Alon > > > > > > > > > > > > > > /etc/rpm/macros.systemd-fc18 > > > > > > > --- > > > > > > > %systemd_post() \ > > > > > > > if [ $1 -eq 1 ] ; then \ > > > > > > > # Initial installation \ > > > > > > > /usr/bin/systemctl preset %{?*} >/dev/null 2>&1 || : \ > > > > > > > fi \ > > > > > > > %{nil} > > > > > > > > > > > > > > %systemd_preun() \ > > > > > > > if [ $1 -eq 0 ] ; then \ > > > > > > > # Package removal, not upgrade \ > > > > > > > /usr/bin/systemctl --no-reload disable %{?*} > /dev/null > > > 2>&1 > > > > > || : > > > > > > > \ > > > > > > > /usr/bin/systemctl stop %{?*} > /dev/null 2>&1 || : \ > > > > > > > fi \ > > > > > > > %{nil} > > > > > > > > > > > > > > %systemd_postun() \ > > > > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > > > > %{nil} > > > > > > > > > > > > > > %systemd_postun_with_restart() \ > > > > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > > > > if [ $1 -ge 1 ] ; then \ > > > > > > > # Package upgrade, not uninstall \ > > > > > > > /usr/bin/systemctl try-restart %{?*} >/dev/null 2>&1 || : > > > > > > > \ > > > > > > > fi \ > > > > > > > %{nil} > > > > > > > --- > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Dead Horse" > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > Cc: engine-devel at ovirt.org > > > > > > > > Sent: Wednesday, April 10, 2013 11:59:15 PM > > > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > > > > > > > > > Correct, FC17 > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 3:32 PM, Alon Bar-Lev > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Is this fedora 17 or 18? > > > > > > > > > > > > > > > > > > I guess it is fedora 17. > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Dead Horse" > > > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > > > Sent: Wednesday, April 10, 2013 11:23:10 PM > > > > > > > > > > Subject: [Engine-devel] upgrade failing with latest master > > > > > > > > > > > > > > > > > > > > logs attached > > > > > > > > > > > > > > > > > > > > First attempt: > > > > > > > > > > 2013-04-10 13:57:32::ERROR::common_utils::355::root:: YUM: > > > FAIL: > > > > > > > Error in > > > > > > > > > > PREUN scriptlet in rpm package > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: > > > VERB: > > > > > > > Script > > > > > > > > > sink: > > > > > > > > > > /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control > > > > > > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > > scriptlet > > > > > > > > > failed, > > > > > > > > > > exit status 1 > > > > > > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: YUM: > > > VERB: > > > > > > > Done: > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > > > > > > > > Second attempt: > > > > > > > > > > 2013-04-10 15:12:11::DEBUG::common_utils::347::root:: YUM: > > > VERB: > > > > > > > Building > > > > > > > > > > transaction > > > > > > > > > > 2013-04-10 15:12:12::ERROR::common_utils::355::root:: YUM: > > > FAIL: > > > > > > > > > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires > > > > > ovirt-engine = > > > > > > > > > > 3.3.0-14.fc17'] > > > > > > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::347::root:: YUM: > > > VERB: > > > > > > > > > Performing > > > > > > > > > > rollback > > > > > > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::1410::root:: > > > Locking > > > > > rpms > > > > > > > in > > > > > > > > > > yum-version-lock > > > > > > > > > > 2013-04-10 15:12:12::ERROR::engine-upgrade::1299::root:: > > > > > Traceback > > > > > > > (most > > > > > > > > > > recent call last): > > > > > > > > > > File "/bin/engine-upgrade", line 1292, in > > > > > > > > > > main(options) > > > > > > > > > > File "/bin/engine-upgrade", line 1142, in main > > > > > > > > > > runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) > > > > > > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > > > > > > func() > > > > > > > > > > File "/bin/engine-upgrade", line 310, in begin > > > > > > > > > > self.emptyTransaction = not > > > > > > > > > > self._miniyum.buildTransaction() > > > > > > > > > > File "/usr/share/ovirt-engine/scripts/miniyum.py", line > > > > > > > > > > 761, > > > in > > > > > > > > > > buildTransaction > > > > > > > > > > raise yum.Errors.YumBaseError(msg) > > > > > > > > > > YumBaseError: [u'ovirt-engine-backend-3.3.0-14.fc17.noarch > > > > > requires > > > > > > > > > > ovirt-engine = 3.3.0-14.fc17'] > > > > > > > > > > > > > > > > > > > > Realizing things were now hosed: > > > > > > > > > > [root at ovirtfoo /]# yum erase ovirt-* otopi-* > > > > > > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, > > > > > versionlock > > > > > > > > > > Resolving Dependencies > > > > > > > > > > --> Running transaction check > > > > > > > > > > ---> Package otopi.noarch 0:3.3.0-15.fc17 will be erased > > > > > > > > > > ---> Package otopi-java.noarch 0:3.3.0-15.fc17 will be > > > > > > > > > > erased > > > > > > > > > > ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 will be > > > erased > > > > > > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > > > will be > > > > > > > erased > > > > > > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > will be > > > > > > > erased > > > > > > > > > > ---> Package ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 will > > > be > > > > > erased > > > > > > > > > > ---> Package ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > > > will > > > > > be > > > > > > > erased > > > > > > > > > > ---> Package ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > > > will be > > > > > > > erased > > > > > > > > > > ---> Package ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 will > > > be > > > > > erased > > > > > > > > > > ---> Package ovirt-engine-setup.noarch 0:3.3.0-15.fc17 will > > > be > > > > > erased > > > > > > > > > > ---> Package ovirt-engine-tools.noarch 0:3.3.0-14.fc17 will > > > be > > > > > erased > > > > > > > > > > ---> Package ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > > > will > > > > > be > > > > > > > > > erased > > > > > > > > > > ---> Package ovirt-engine-webadmin-portal.noarch > > > 0:3.3.0-14.fc17 > > > > > > > will be > > > > > > > > > > erased > > > > > > > > > > ---> Package ovirt-host-deploy.noarch 0:3.3.0-15.fc17 will > > > > > > > > > > be > > > > > erased > > > > > > > > > > ---> Package ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > > > will > > > > > be > > > > > > > erased > > > > > > > > > > ---> Package ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > > > will be > > > > > > > erased > > > > > > > > > > ---> Package ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 will > > > be > > > > > erased > > > > > > > > > > ---> Package ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > > > > > > > will > > > be > > > > > > > erased > > > > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > Removing: > > > > > > > > > > otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k > > > > > > > > > > otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k > > > > > > > > > > ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine 1.3 M > > > > > > > > > > ovirt-engine-backend noarch 3.3.0-14.fc17 @ovirt-engine 20 > > > > > > > > > > M > > > > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 > > > > > > > > > > M > > > > > > > > > > ovirt-engine-cli noarch 3.3.0.1-15.fc17 @ovirt-engine 557 k > > > > > > > > > > ovirt-engine-dbscripts noarch 3.3.0-14.fc17 @ovirt-engine > > > 816 k > > > > > > > > > > ovirt-engine-restapi noarch 3.3.0-14.fc17 @ovirt-engine 1.0 > > > > > > > > > > M > > > > > > > > > > ovirt-engine-sdk noarch 3.3.0.1-15.fc17 @ovirt-engine 3.1 M > > > > > > > > > > ovirt-engine-setup noarch 3.3.0-15.fc17 @ovirt-engine 653 k > > > > > > > > > > ovirt-engine-tools noarch 3.3.0-14.fc17 @ovirt-engine 178 k > > > > > > > > > > ovirt-engine-userportal noarch 3.3.0-14.fc17 @ovirt-engine > > > 23 M > > > > > > > > > > ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 > > > @ovirt-engine > > > > > 32 M > > > > > > > > > > ovirt-host-deploy noarch 3.3.0-15.fc17 @ovirt-engine 211 k > > > > > > > > > > ovirt-host-deploy-java noarch 3.3.0-15.fc17 @ovirt-engine > > > > > > > > > > 11 > > > k > > > > > > > > > > ovirt-image-uploader noarch 3.3.0-15.fc17 @ovirt-engine 923 > > > > > > > > > > k > > > > > > > > > > ovirt-iso-uploader noarch 3.3.0-15.fc17 @ovirt-engine 98 k > > > > > > > > > > ovirt-log-collector noarch 3.3.0-15.fc17 @ovirt-engine 133 > > > > > > > > > > k > > > > > > > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > Remove 18 Packages > > > > > > > > > > > > > > > > > > > > Installed size: 104 M > > > > > > > > > > Is this ok [y/N]: y > > > > > > > > > > Downloading Packages: > > > > > > > > > > Running Transaction Check > > > > > > > > > > Running Transaction Test > > > > > > > > > > Transaction Test Succeeded > > > > > > > > > > Running Transaction > > > > > > > > > > Erasing : ovirt-engine-backend.noarch 1/18 > > > > > > > > > > Erasing : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch 2/18 > > > > > > > > > > Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch 3/18 > > > > > > > > > > Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch 4/18 > > > > > > > > > > Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch 5/18 > > > > > > > > > > Erasing : ovirt-engine-userportal-3.3.0-14.fc17.noarch 6/18 > > > > > > > > > > Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 > > > > > > > > > > warning: /etc/ovirt-engine/engine.conf saved as > > > > > > > > > > /etc/ovirt-engine/engine.conf.rpmsave > > > > > > > > > > Erasing : ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > > > 8/18 > > > > > > > > > > Erasing : ovirt-host-deploy-java-3.3.0-15.fc17.noarch 9/18 > > > > > > > > > > Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 > > > > > > > > > > Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch 11/18 > > > > > > > > > > Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > > > > > > > > warning: /etc/ovirt-engine/imageuploader.conf saved as > > > > > > > > > > /etc/ovirt-engine/imageuploader.conf.rpmsave > > > > > > > > > > Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > > > > > > > warning: /etc/ovirt-engine/isouploader.conf saved as > > > > > > > > > > /etc/ovirt-engine/isouploader.conf.rpmsave > > > > > > > > > > Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch 14/18 > > > > > > > > > > warning: /etc/ovirt-engine/logcollector.conf saved as > > > > > > > > > > /etc/ovirt-engine/logcollector.conf.rpmsave > > > > > > > > > > Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 15/18 > > > > > > > > > > Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 16/18 > > > > > > > > > > Erasing : otopi-3.3.0-15.fc17.noarch 17/18 > > > > > > > > > > Error in PREUN scriptlet in rpm package > > > > > > > > > > ovirt-engine-backend > > > > > > > > > > /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control > > > > > > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > > scriptlet > > > > > > > > > failed, > > > > > > > > > > exit status 1 > > > > > > > > > > Verifying : otopi-3.3.0-15.fc17.noarch 1/18 > > > > > > > > > > Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 > > > > > > > > > > Verifying : ovirt-log-collector-3.3.0-15.fc17.noarch 3/18 > > > > > > > > > > Verifying : > > > > > > > > > > ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > > > > > 4/18 > > > > > > > > > > Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch 5/18 > > > > > > > > > > Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch 6/18 > > > > > > > > > > Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch 7/18 > > > > > > > > > > Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 8/18 > > > > > > > > > > Verifying : ovirt-engine-restapi-3.3.0-14.fc17.noarch 9/18 > > > > > > > > > > Verifying : ovirt-engine-userportal-3.3.0-14.fc17.noarch > > > 10/18 > > > > > > > > > > Verifying : ovirt-host-deploy-java-3.3.0-15.fc17.noarch > > > > > > > > > > 11/18 > > > > > > > > > > Verifying : ovirt-image-uploader-3.3.0-15.fc17.noarch 12/18 > > > > > > > > > > Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > > > > > > > Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 14/18 > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch was supposed to > > > > > > > > > > be > > > > > removed > > > > > > > but > > > > > > > > > is > > > > > > > > > > not! > > > > > > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 15/18 > > > > > > > > > > Verifying : ovirt-engine-backend-3.3.0-14.fc17.noarch 16/18 > > > > > > > > > > Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 > > > > > > > > > > Verifying : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch > > > > > > > > > > 18/18 > > > > > > > > > > > > > > > > > > > > Removed: > > > > > > > > > > otopi.noarch 0:3.3.0-15.fc17 > > > > > > > > > > otopi-java.noarch 0:3.3.0-15.fc17 > > > > > > > > > > ovirt-engine.noarch 0:3.3.0-14.fc17 > > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > > > > > > > > > > ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > > > > > > > > > > ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > > > > > > > > > > ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > > > > > > > > > > ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > > > > > > > > > > ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > > > > > > > > > > ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > > > > > > > > > > ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > > > > > > > > > > ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > > > > > > > > > ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > > > > > > > > > > ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > > > > > > > > > > ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > > > > ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > > > > ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > > > Failed: > > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > > > Complete! > > > > > > > > > > [root at ovirtfoo /]# rpm -qa | grep oto > > > > > > > > > > protobuf-java-2.4.1-12.fc17.x86_64 > > > > > > > > > > libgphoto2-2.4.14-1.fc17.x86_64 > > > > > > > > > > [root at ovirtfoo /]# rpm -qa | grep ovirt > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > [root at ovirtfoo /]# yum erase > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, > > > > > versionlock > > > > > > > > > > Resolving Dependencies > > > > > > > > > > --> Running transaction check > > > > > > > > > > ---> Package ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > will be > > > > > > > erased > > > > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > Removing: > > > > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 @ovirt-engine 20 > > > > > > > > > > M > > > > > > > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > Remove 1 Package > > > > > > > > > > > > > > > > > > > > Installed size: 20 M > > > > > > > > > > Is this ok [y/N]: y > > > > > > > > > > Downloading Packages: > > > > > > > > > > Running Transaction Check > > > > > > > > > > Running Transaction Test > > > > > > > > > > Transaction Test Succeeded > > > > > > > > > > Running Transaction > > > > > > > > > > Error in PREUN scriptlet in rpm package > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control > > > > > > > > > > error: %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > > scriptlet > > > > > > > > > failed, > > > > > > > > > > exit status 1 > > > > > > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch 1/1 > > > > > > > > > > > > > > > > > > > > Failed: > > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > > > Complete! > > > > > > > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: macros.systemd.fc18 Type: application/octet-stream Size: 711 bytes Desc: not available URL: From deadhorseconsulting at gmail.com Mon Apr 15 17:25:48 2013 From: deadhorseconsulting at gmail.com (Dead Horse) Date: Mon, 15 Apr 2013 12:25:48 -0500 Subject: [Engine-devel] upgrade failing with latest master In-Reply-To: <5152300.367225.1366042400592.JavaMail.root@redhat.com> References: <269004897.1042115.1365627763231.JavaMail.root@redhat.com> <383901841.1348447.1365716007616.JavaMail.root@redhat.com> <1273669048.47013.1365880663823.JavaMail.root@redhat.com> <1446063899.366491.1366042252302.JavaMail.root@redhat.com> <5152300.367225.1366042400592.JavaMail.root@redhat.com> Message-ID: Guessing you are referring to the changes you made at commit: eb8d8010a35a20a871c0af7674879da548d971f1 and the few commits prior? If so I have built engine from master since then along with the macros file added to /etc/rpm before initiating the build on my FC17 build VM. All builds even with the macros included still result in the above most recent reported upgrade failures with the engine service. - DHC On Mon, Apr 15, 2013 at 11:13 AM, Alon Bar-Lev wrote: > BTW: best is to use fedora-18... If not, please put the attached file at > /etc/rpm before packaging. > > > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "Dead Horse" > > Cc: engine-devel at ovirt.org > > Sent: Monday, April 15, 2013 7:10:52 PM > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > Oh... it is before I rewrote the engine service. > > I thought that you facing issue after the re-write. > > Can you please give a try to the master HEAD? > > > > ----- Original Message ----- > > > From: "Dead Horse" > > > To: "Alon Bar-Lev" > > > Cc: engine-devel at ovirt.org > > > Sent: Monday, April 15, 2013 6:41:33 PM > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > Engine version I am attempting to upgrade was built from this commit: > > > b4cc077888ba11871aa4837a73498a231050e2fc > > > I built it same as always on a fully up to date FC17 VM. > > > EG: Check out sources, cd /path/to/source/ make "rpm" > > > > > > I am unable to locate any .rpmnew in /etc after or before upgrade. > > > > > > - DHC > > > > > > > > > On Sat, Apr 13, 2013 at 2:17 PM, Alon Bar-Lev > wrote: > > > > > > > > > > > Which version do you use? > > > > Have you built it your-self? > > > > Have you settled all .rpmnew you have in /etc? > > > > > > > > ----- Original Message ----- > > > > > From: "Dead Horse" > > > > > To: "Alon Bar-Lev" > > > > > Cc: engine-devel at ovirt.org > > > > > Sent: Friday, April 12, 2013 9:20:51 PM > > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > > > Prior to engine-upgrade: > > > > > ovirt-engine.service - oVirt Engine > > > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > > > enabled) > > > > > Active: active (running) since Fri, 12 Apr 2013 13:11:16 > -0500; > > > > 1min > > > > > 10s ago > > > > > Main PID: 9023 (java) > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > ? 9023 engine-service -server -XX:+TieredCompilation > -Xms... > > > > > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > Started > > > > > engine ... > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > Starting > > > > > engine... > > > > > > > > > > Stopping ovirt-engine service prior to engine-upgrade: > > > > > ovirt-engine.service - oVirt Engine > > > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > > > enabled) > > > > > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 > > > > > 13:12:51 > > > > > -0500; 3s ago > > > > > Process: 9141 ExecStop=/usr/bin/engine-service stop > (code=exited, > > > > > status=0/SUCCESS) > > > > > Main PID: 9023 (code=exited, status=143) > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > Started > > > > > engine ... > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > Starting > > > > > engine... > > > > > Apr 12 13:12:50 ovirtfoo.ctt.med.ge.com engine-service[9141]: > Waiting > > > > up to > > > > > 1... > > > > > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: > Stopped > > > > > engine ... > > > > > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: > Stopping > > > > > engine... > > > > > > > > > > After running engine-upgrade: > > > > > ovirt-engine.service - oVirt Engine > > > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > > > enabled) > > > > > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 > > > > > 13:18:22 > > > > > -0500; 41s ago > > > > > Main PID: 9168 (code=exited, status=143) > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > > > > > Apr 12 13:18:22 ovirtfoo.ctt.med.ge.com systemd[11198]: Failed at > step > > > > EXEC > > > > > spawning /usr/bin/engine-service: No such file or directory > > > > > > > > > > After attemptining systemctl start ovirt-engine.service after > > > > > engine-upgrade: > > > > > ovirt-engine.service - oVirt Engine > > > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > > > enabled) > > > > > Active: active (running) since Fri, 12 Apr 2013 13:19:43 > -0500; > > > > > 1s > > > > ago > > > > > Process: 11228 ExecStart=/usr/bin/engine-service start > > > > > (code=exited, > > > > > status=0/SUCCESS) > > > > > Main PID: 11229 (java) > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > ? 11229 engine-service -server -XX:+TieredCompilation > -Xms1g > > > > > -Xmx1g -XX:PermSize=256m -XX:MaxPermSize=256m > > > > > -Djava.net.preferIPv4Stack=tr... > > > > > > > > > > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: > Started > > > > > engine process 11229. > > > > > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: > Starting > > > > > engine-service: [ OK ] > > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Apr 11, 2013 at 4:33 PM, Alon Bar-Lev > > > > > wrote: > > > > > > > > > > > Please see what systemd has to say: > > > > > > > > > > > > # systemctl status ovirt-engine.service > > > > > > > > > > > > > > > > > > And no, I never tried to backup/restore... sorry... > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Dead Horse" > > > > > > > To: "Alon Bar-Lev" > > > > > > > Cc: engine-devel at ovirt.org > > > > > > > Sent: Friday, April 12, 2013 12:28:01 AM > > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > > > > > > > Rebuilt the engine on my FC17 build VM with the macro file > above in > > > > > > > "/etc/rpm/" > > > > > > > Upon attempting upgrade on my FC17 upgrade test VM: > > > > > > > I still get a failure to start the engine > > > > > > > > > > > > > > 013-04-11 16:06:37::ERROR::engine-upgrade::1328::root:: > Traceback > > > > (most > > > > > > > recent call last): > > > > > > > File "/bin/engine-upgrade", line 1321, in > > > > > > > main(options) > > > > > > > File "/bin/engine-upgrade", line 1293, in main > > > > > > > runFunc([startEngine], MSG_INFO_START_ENGINE % > engineService) > > > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > > > func() > > > > > > > File "/bin/engine-upgrade", line 584, in startEngine > > > > > > > output, rc = utils.execCmd(cmdList=cmd, failOnError=True, > > > > > > > msg=MSG_ERR_FAILED_START_ENGINE_SERVICE) > > > > > > > File "/usr/share/ovirt-engine/scripts/common_utils.py", line > 499, > > > > in > > > > > > > execCmd > > > > > > > raise Exception(msg) > > > > > > > Exception: Error: Can't start ovirt-engine > > > > > > > > > > > > > > Curiously is there a documented process somewhere for backing > up > > > > > > > data > > > > > > from > > > > > > > an FC17 ovirt install and doing a fresh install on a FC18 box > then > > > > > > > restoring the FC17 database + ovirt config data? > > > > > > > > > > > > > > Guessing it goes something like this: (someone please confirm) > > > > > > > > > > > > > > Back up the following directories and files: > > > > > > > /etc/ovirt-engine > > > > > > > /etc/pki/ovirt-engine > > > > > > > /etc/pki/ovirt-engine-backups > > > > > > > /var/lib/ovirt-engine/backups > > > > > > > /var/lib/ovirt-engine/deployments > > > > > > > /root/.rnd > > > > > > > > > > > > > > Dump a backup of the engine database > > > > > > > > > > > > > > Install ovirt-engine on FC18 system > > > > > > > run engine-setup (answer questions same as prior install from > FC17) > > > > > > > upon completion of engine-setup stop the engine service > > > > > > > restore all the above files and directories > > > > > > > > > > > > > > Drop the engine databse > > > > > > > Restore the backed up engine database > > > > > > > > > > > > > > FC17 --> FC18 upgrade = icky esp. with ovirt involved as part > of > > > > > > > the > > > > > > upgrade > > > > > > > > > > > > > > Thus it seems the easiest way to solve this is to bite the > bullet > > > > > > > and > > > > > > move > > > > > > > to FC18 providing the backup/restore works. > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 4:02 PM, Alon Bar-Lev < > alonbl at redhat.com> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > OK... the systemd macros are missing in fedora 17... > > > > > > > > > > > > > > > > Put the following file and rebuild. > > > > > > > > I may need to add some workaround if many people still use > > > > fedora-17 > > > > > > for > > > > > > > > master. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Alon > > > > > > > > > > > > > > > > /etc/rpm/macros.systemd-fc18 > > > > > > > > --- > > > > > > > > %systemd_post() \ > > > > > > > > if [ $1 -eq 1 ] ; then \ > > > > > > > > # Initial installation \ > > > > > > > > /usr/bin/systemctl preset %{?*} >/dev/null 2>&1 || : > \ > > > > > > > > fi \ > > > > > > > > %{nil} > > > > > > > > > > > > > > > > %systemd_preun() \ > > > > > > > > if [ $1 -eq 0 ] ; then \ > > > > > > > > # Package removal, not upgrade \ > > > > > > > > /usr/bin/systemctl --no-reload disable %{?*} > > /dev/null > > > > 2>&1 > > > > > > || : > > > > > > > > \ > > > > > > > > /usr/bin/systemctl stop %{?*} > /dev/null 2>&1 || : \ > > > > > > > > fi \ > > > > > > > > %{nil} > > > > > > > > > > > > > > > > %systemd_postun() \ > > > > > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > > > > > %{nil} > > > > > > > > > > > > > > > > %systemd_postun_with_restart() \ > > > > > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > > > > > if [ $1 -ge 1 ] ; then \ > > > > > > > > # Package upgrade, not uninstall \ > > > > > > > > /usr/bin/systemctl try-restart %{?*} >/dev/null 2>&1 > || : > > > > > > > > \ > > > > > > > > fi \ > > > > > > > > %{nil} > > > > > > > > --- > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Dead Horse" > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > Cc: engine-devel at ovirt.org > > > > > > > > > Sent: Wednesday, April 10, 2013 11:59:15 PM > > > > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest > master > > > > > > > > > > > > > > > > > > Correct, FC17 > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 3:32 PM, Alon Bar-Lev > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Is this fedora 17 or 18? > > > > > > > > > > > > > > > > > > > > I guess it is fedora 17. > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Dead Horse" > > > > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > > > > Sent: Wednesday, April 10, 2013 11:23:10 PM > > > > > > > > > > > Subject: [Engine-devel] upgrade failing with latest > master > > > > > > > > > > > > > > > > > > > > > > logs attached > > > > > > > > > > > > > > > > > > > > > > First attempt: > > > > > > > > > > > 2013-04-10 13:57:32::ERROR::common_utils::355::root:: > YUM: > > > > FAIL: > > > > > > > > Error in > > > > > > > > > > > PREUN scriptlet in rpm package > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: > YUM: > > > > VERB: > > > > > > > > Script > > > > > > > > > > sink: > > > > > > > > > > > /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control > > > > > > > > > > > error: > %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > > > scriptlet > > > > > > > > > > failed, > > > > > > > > > > > exit status 1 > > > > > > > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: > YUM: > > > > VERB: > > > > > > > > Done: > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > > > > > > > > > > Second attempt: > > > > > > > > > > > 2013-04-10 15:12:11::DEBUG::common_utils::347::root:: > YUM: > > > > VERB: > > > > > > > > Building > > > > > > > > > > > transaction > > > > > > > > > > > 2013-04-10 15:12:12::ERROR::common_utils::355::root:: > YUM: > > > > FAIL: > > > > > > > > > > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires > > > > > > ovirt-engine = > > > > > > > > > > > 3.3.0-14.fc17'] > > > > > > > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::347::root:: > YUM: > > > > VERB: > > > > > > > > > > Performing > > > > > > > > > > > rollback > > > > > > > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::1410::root:: > > > > Locking > > > > > > rpms > > > > > > > > in > > > > > > > > > > > yum-version-lock > > > > > > > > > > > 2013-04-10 > 15:12:12::ERROR::engine-upgrade::1299::root:: > > > > > > Traceback > > > > > > > > (most > > > > > > > > > > > recent call last): > > > > > > > > > > > File "/bin/engine-upgrade", line 1292, in > > > > > > > > > > > main(options) > > > > > > > > > > > File "/bin/engine-upgrade", line 1142, in main > > > > > > > > > > > runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) > > > > > > > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > > > > > > > func() > > > > > > > > > > > File "/bin/engine-upgrade", line 310, in begin > > > > > > > > > > > self.emptyTransaction = not > > > > > > > > > > > self._miniyum.buildTransaction() > > > > > > > > > > > File "/usr/share/ovirt-engine/scripts/miniyum.py", line > > > > > > > > > > > 761, > > > > in > > > > > > > > > > > buildTransaction > > > > > > > > > > > raise yum.Errors.YumBaseError(msg) > > > > > > > > > > > YumBaseError: > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch > > > > > > requires > > > > > > > > > > > ovirt-engine = 3.3.0-14.fc17'] > > > > > > > > > > > > > > > > > > > > > > Realizing things were now hosed: > > > > > > > > > > > [root at ovirtfoo /]# yum erase ovirt-* otopi-* > > > > > > > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, > > > > > > versionlock > > > > > > > > > > > Resolving Dependencies > > > > > > > > > > > --> Running transaction check > > > > > > > > > > > ---> Package otopi.noarch 0:3.3.0-15.fc17 will be > erased > > > > > > > > > > > ---> Package otopi-java.noarch 0:3.3.0-15.fc17 will be > > > > > > > > > > > erased > > > > > > > > > > > ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 will > be > > > > erased > > > > > > > > > > > ---> Package ovirt-engine-backend.noarch > 0:3.3.0-14.fc17 > > > > will be > > > > > > > > erased > > > > > > > > > > > ---> Package ovirt-engine-backend.noarch > 0:3.3.0-15.fc17 > > > > will be > > > > > > > > erased > > > > > > > > > > > ---> Package ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > will > > > > be > > > > > > erased > > > > > > > > > > > ---> Package ovirt-engine-dbscripts.noarch > 0:3.3.0-14.fc17 > > > > will > > > > > > be > > > > > > > > erased > > > > > > > > > > > ---> Package ovirt-engine-restapi.noarch > 0:3.3.0-14.fc17 > > > > will be > > > > > > > > erased > > > > > > > > > > > ---> Package ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > will > > > > be > > > > > > erased > > > > > > > > > > > ---> Package ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > will > > > > be > > > > > > erased > > > > > > > > > > > ---> Package ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > will > > > > be > > > > > > erased > > > > > > > > > > > ---> Package ovirt-engine-userportal.noarch > 0:3.3.0-14.fc17 > > > > will > > > > > > be > > > > > > > > > > erased > > > > > > > > > > > ---> Package ovirt-engine-webadmin-portal.noarch > > > > 0:3.3.0-14.fc17 > > > > > > > > will be > > > > > > > > > > > erased > > > > > > > > > > > ---> Package ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > will > > > > > > > > > > > be > > > > > > erased > > > > > > > > > > > ---> Package ovirt-host-deploy-java.noarch > 0:3.3.0-15.fc17 > > > > will > > > > > > be > > > > > > > > erased > > > > > > > > > > > ---> Package ovirt-image-uploader.noarch > 0:3.3.0-15.fc17 > > > > will be > > > > > > > > erased > > > > > > > > > > > ---> Package ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > will > > > > be > > > > > > erased > > > > > > > > > > > ---> Package ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > will > > > > be > > > > > > > > erased > > > > > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > Removing: > > > > > > > > > > > otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k > > > > > > > > > > > otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k > > > > > > > > > > > ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine 1.3 M > > > > > > > > > > > ovirt-engine-backend noarch 3.3.0-14.fc17 > @ovirt-engine 20 > > > > > > > > > > > M > > > > > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 > @ovirt-engine 20 > > > > > > > > > > > M > > > > > > > > > > > ovirt-engine-cli noarch 3.3.0.1-15.fc17 @ovirt-engine > 557 k > > > > > > > > > > > ovirt-engine-dbscripts noarch 3.3.0-14.fc17 > @ovirt-engine > > > > 816 k > > > > > > > > > > > ovirt-engine-restapi noarch 3.3.0-14.fc17 > @ovirt-engine 1.0 > > > > > > > > > > > M > > > > > > > > > > > ovirt-engine-sdk noarch 3.3.0.1-15.fc17 @ovirt-engine > 3.1 M > > > > > > > > > > > ovirt-engine-setup noarch 3.3.0-15.fc17 @ovirt-engine > 653 k > > > > > > > > > > > ovirt-engine-tools noarch 3.3.0-14.fc17 @ovirt-engine > 178 k > > > > > > > > > > > ovirt-engine-userportal noarch 3.3.0-14.fc17 > @ovirt-engine > > > > 23 M > > > > > > > > > > > ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 > > > > @ovirt-engine > > > > > > 32 M > > > > > > > > > > > ovirt-host-deploy noarch 3.3.0-15.fc17 @ovirt-engine > 211 k > > > > > > > > > > > ovirt-host-deploy-java noarch 3.3.0-15.fc17 > @ovirt-engine > > > > > > > > > > > 11 > > > > k > > > > > > > > > > > ovirt-image-uploader noarch 3.3.0-15.fc17 > @ovirt-engine 923 > > > > > > > > > > > k > > > > > > > > > > > ovirt-iso-uploader noarch 3.3.0-15.fc17 @ovirt-engine > 98 k > > > > > > > > > > > ovirt-log-collector noarch 3.3.0-15.fc17 @ovirt-engine > 133 > > > > > > > > > > > k > > > > > > > > > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > Remove 18 Packages > > > > > > > > > > > > > > > > > > > > > > Installed size: 104 M > > > > > > > > > > > Is this ok [y/N]: y > > > > > > > > > > > Downloading Packages: > > > > > > > > > > > Running Transaction Check > > > > > > > > > > > Running Transaction Test > > > > > > > > > > > Transaction Test Succeeded > > > > > > > > > > > Running Transaction > > > > > > > > > > > Erasing : ovirt-engine-backend.noarch 1/18 > > > > > > > > > > > Erasing : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch > 2/18 > > > > > > > > > > > Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch > 3/18 > > > > > > > > > > > Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch 4/18 > > > > > > > > > > > Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch 5/18 > > > > > > > > > > > Erasing : ovirt-engine-userportal-3.3.0-14.fc17.noarch > 6/18 > > > > > > > > > > > Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 > > > > > > > > > > > warning: /etc/ovirt-engine/engine.conf saved as > > > > > > > > > > > /etc/ovirt-engine/engine.conf.rpmsave > > > > > > > > > > > Erasing : > ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > > > > 8/18 > > > > > > > > > > > Erasing : ovirt-host-deploy-java-3.3.0-15.fc17.noarch > 9/18 > > > > > > > > > > > Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 > > > > > > > > > > > Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch 11/18 > > > > > > > > > > > Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch > 12/18 > > > > > > > > > > > warning: /etc/ovirt-engine/imageuploader.conf saved as > > > > > > > > > > > /etc/ovirt-engine/imageuploader.conf.rpmsave > > > > > > > > > > > Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > > > > > > > > warning: /etc/ovirt-engine/isouploader.conf saved as > > > > > > > > > > > /etc/ovirt-engine/isouploader.conf.rpmsave > > > > > > > > > > > Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch > 14/18 > > > > > > > > > > > warning: /etc/ovirt-engine/logcollector.conf saved as > > > > > > > > > > > /etc/ovirt-engine/logcollector.conf.rpmsave > > > > > > > > > > > Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 15/18 > > > > > > > > > > > Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 16/18 > > > > > > > > > > > Erasing : otopi-3.3.0-15.fc17.noarch 17/18 > > > > > > > > > > > Error in PREUN scriptlet in rpm package > > > > > > > > > > > ovirt-engine-backend > > > > > > > > > > > /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control > > > > > > > > > > > error: > %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > > > scriptlet > > > > > > > > > > failed, > > > > > > > > > > > exit status 1 > > > > > > > > > > > Verifying : otopi-3.3.0-15.fc17.noarch 1/18 > > > > > > > > > > > Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 > > > > > > > > > > > Verifying : ovirt-log-collector-3.3.0-15.fc17.noarch > 3/18 > > > > > > > > > > > Verifying : > > > > > > > > > > > ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > > > > > > 4/18 > > > > > > > > > > > Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch 5/18 > > > > > > > > > > > Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch > 6/18 > > > > > > > > > > > Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch > 7/18 > > > > > > > > > > > Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch > 8/18 > > > > > > > > > > > Verifying : ovirt-engine-restapi-3.3.0-14.fc17.noarch > 9/18 > > > > > > > > > > > Verifying : > ovirt-engine-userportal-3.3.0-14.fc17.noarch > > > > 10/18 > > > > > > > > > > > Verifying : ovirt-host-deploy-java-3.3.0-15.fc17.noarch > > > > > > > > > > > 11/18 > > > > > > > > > > > Verifying : ovirt-image-uploader-3.3.0-15.fc17.noarch > 12/18 > > > > > > > > > > > Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch > 13/18 > > > > > > > > > > > Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch > 14/18 > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch was supposed > to > > > > > > > > > > > be > > > > > > removed > > > > > > > > but > > > > > > > > > > is > > > > > > > > > > > not! > > > > > > > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch > 15/18 > > > > > > > > > > > Verifying : ovirt-engine-backend-3.3.0-14.fc17.noarch > 16/18 > > > > > > > > > > > Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 > > > > > > > > > > > Verifying : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch > > > > > > > > > > > 18/18 > > > > > > > > > > > > > > > > > > > > > > Removed: > > > > > > > > > > > otopi.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > otopi-java.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > ovirt-engine.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > > > > > > > > > > > ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > > > > > > > > > > > ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > > > > > Failed: > > > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > > > > > Complete! > > > > > > > > > > > [root at ovirtfoo /]# rpm -qa | grep oto > > > > > > > > > > > protobuf-java-2.4.1-12.fc17.x86_64 > > > > > > > > > > > libgphoto2-2.4.14-1.fc17.x86_64 > > > > > > > > > > > [root at ovirtfoo /]# rpm -qa | grep ovirt > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > [root at ovirtfoo /]# yum erase > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, > > > > > > versionlock > > > > > > > > > > > Resolving Dependencies > > > > > > > > > > > --> Running transaction check > > > > > > > > > > > ---> Package ovirt-engine-backend.noarch > 0:3.3.0-15.fc17 > > > > will be > > > > > > > > erased > > > > > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > Removing: > > > > > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 > @ovirt-engine 20 > > > > > > > > > > > M > > > > > > > > > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > Remove 1 Package > > > > > > > > > > > > > > > > > > > > > > Installed size: 20 M > > > > > > > > > > > Is this ok [y/N]: y > > > > > > > > > > > Downloading Packages: > > > > > > > > > > > Running Transaction Check > > > > > > > > > > > Running Transaction Test > > > > > > > > > > > Transaction Test Succeeded > > > > > > > > > > > Running Transaction > > > > > > > > > > > Error in PREUN scriptlet in rpm package > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control > > > > > > > > > > > error: > %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > > > scriptlet > > > > > > > > > > failed, > > > > > > > > > > > exit status 1 > > > > > > > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch > 1/1 > > > > > > > > > > > > > > > > > > > > > > Failed: > > > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > > > > > Complete! > > > > > > > > > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > 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: From alonbl at redhat.com Mon Apr 15 19:23:39 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 15 Apr 2013 15:23:39 -0400 (EDT) Subject: [Engine-devel] upgrade failing with latest master In-Reply-To: References: <383901841.1348447.1365716007616.JavaMail.root@redhat.com> <1273669048.47013.1365880663823.JavaMail.root@redhat.com> <1446063899.366491.1366042252302.JavaMail.root@redhat.com> <5152300.367225.1366042400592.JavaMail.root@redhat.com> Message-ID: <1383860034.427016.1366053819732.JavaMail.root@redhat.com> It was not single commit, please take most recent master (HEAD) Please attach logs and systemd journal messages. Thanks! ----- Original Message ----- > From: "Dead Horse" > To: "Alon Bar-Lev" > Cc: engine-devel at ovirt.org > Sent: Monday, April 15, 2013 8:25:48 PM > Subject: Re: [Engine-devel] upgrade failing with latest master > > Guessing you are referring to the changes you made at commit: > eb8d8010a35a20a871c0af7674879da548d971f1 > and the few commits prior? > > If so I have built engine from master since then along with the macros file > added to /etc/rpm before initiating the build on my FC17 build VM. > All builds even with the macros included still result in the above most > recent reported upgrade failures with the engine service. > > - DHC > > > > On Mon, Apr 15, 2013 at 11:13 AM, Alon Bar-Lev wrote: > > > BTW: best is to use fedora-18... If not, please put the attached file at > > /etc/rpm before packaging. > > > > > > > > ----- Original Message ----- > > > From: "Alon Bar-Lev" > > > To: "Dead Horse" > > > Cc: engine-devel at ovirt.org > > > Sent: Monday, April 15, 2013 7:10:52 PM > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > Oh... it is before I rewrote the engine service. > > > I thought that you facing issue after the re-write. > > > Can you please give a try to the master HEAD? > > > > > > ----- Original Message ----- > > > > From: "Dead Horse" > > > > To: "Alon Bar-Lev" > > > > Cc: engine-devel at ovirt.org > > > > Sent: Monday, April 15, 2013 6:41:33 PM > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > Engine version I am attempting to upgrade was built from this commit: > > > > b4cc077888ba11871aa4837a73498a231050e2fc > > > > I built it same as always on a fully up to date FC17 VM. > > > > EG: Check out sources, cd /path/to/source/ make "rpm" > > > > > > > > I am unable to locate any .rpmnew in /etc after or before upgrade. > > > > > > > > - DHC > > > > > > > > > > > > On Sat, Apr 13, 2013 at 2:17 PM, Alon Bar-Lev > > wrote: > > > > > > > > > > > > > > Which version do you use? > > > > > Have you built it your-self? > > > > > Have you settled all .rpmnew you have in /etc? > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Dead Horse" > > > > > > To: "Alon Bar-Lev" > > > > > > Cc: engine-devel at ovirt.org > > > > > > Sent: Friday, April 12, 2013 9:20:51 PM > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > > > > > Prior to engine-upgrade: > > > > > > ovirt-engine.service - oVirt Engine > > > > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > > > > enabled) > > > > > > Active: active (running) since Fri, 12 Apr 2013 13:11:16 > > -0500; > > > > > 1min > > > > > > 10s ago > > > > > > Main PID: 9023 (java) > > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > ? 9023 engine-service -server -XX:+TieredCompilation > > -Xms... > > > > > > > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > > Started > > > > > > engine ... > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > > Starting > > > > > > engine... > > > > > > > > > > > > Stopping ovirt-engine service prior to engine-upgrade: > > > > > > ovirt-engine.service - oVirt Engine > > > > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > > > > enabled) > > > > > > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 > > > > > > 13:12:51 > > > > > > -0500; 3s ago > > > > > > Process: 9141 ExecStop=/usr/bin/engine-service stop > > (code=exited, > > > > > > status=0/SUCCESS) > > > > > > Main PID: 9023 (code=exited, status=143) > > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > > Started > > > > > > engine ... > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > > Starting > > > > > > engine... > > > > > > Apr 12 13:12:50 ovirtfoo.ctt.med.ge.com engine-service[9141]: > > Waiting > > > > > up to > > > > > > 1... > > > > > > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: > > Stopped > > > > > > engine ... > > > > > > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: > > Stopping > > > > > > engine... > > > > > > > > > > > > After running engine-upgrade: > > > > > > ovirt-engine.service - oVirt Engine > > > > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > > > > enabled) > > > > > > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 > > > > > > 13:18:22 > > > > > > -0500; 41s ago > > > > > > Main PID: 9168 (code=exited, status=143) > > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > > > > > > > Apr 12 13:18:22 ovirtfoo.ctt.med.ge.com systemd[11198]: Failed at > > step > > > > > EXEC > > > > > > spawning /usr/bin/engine-service: No such file or directory > > > > > > > > > > > > After attemptining systemctl start ovirt-engine.service after > > > > > > engine-upgrade: > > > > > > ovirt-engine.service - oVirt Engine > > > > > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; > > > > > enabled) > > > > > > Active: active (running) since Fri, 12 Apr 2013 13:19:43 > > -0500; > > > > > > 1s > > > > > ago > > > > > > Process: 11228 ExecStart=/usr/bin/engine-service start > > > > > > (code=exited, > > > > > > status=0/SUCCESS) > > > > > > Main PID: 11229 (java) > > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > ? 11229 engine-service -server -XX:+TieredCompilation > > -Xms1g > > > > > > -Xmx1g -XX:PermSize=256m -XX:MaxPermSize=256m > > > > > > -Djava.net.preferIPv4Stack=tr... > > > > > > > > > > > > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: > > Started > > > > > > engine process 11229. > > > > > > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: > > Starting > > > > > > engine-service: [ OK ] > > > > > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Apr 11, 2013 at 4:33 PM, Alon Bar-Lev > > > > > > wrote: > > > > > > > > > > > > > Please see what systemd has to say: > > > > > > > > > > > > > > # systemctl status ovirt-engine.service > > > > > > > > > > > > > > > > > > > > > And no, I never tried to backup/restore... sorry... > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Dead Horse" > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > Cc: engine-devel at ovirt.org > > > > > > > > Sent: Friday, April 12, 2013 12:28:01 AM > > > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > > > > > > > > > Rebuilt the engine on my FC17 build VM with the macro file > > above in > > > > > > > > "/etc/rpm/" > > > > > > > > Upon attempting upgrade on my FC17 upgrade test VM: > > > > > > > > I still get a failure to start the engine > > > > > > > > > > > > > > > > 013-04-11 16:06:37::ERROR::engine-upgrade::1328::root:: > > Traceback > > > > > (most > > > > > > > > recent call last): > > > > > > > > File "/bin/engine-upgrade", line 1321, in > > > > > > > > main(options) > > > > > > > > File "/bin/engine-upgrade", line 1293, in main > > > > > > > > runFunc([startEngine], MSG_INFO_START_ENGINE % > > engineService) > > > > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > > > > func() > > > > > > > > File "/bin/engine-upgrade", line 584, in startEngine > > > > > > > > output, rc = utils.execCmd(cmdList=cmd, failOnError=True, > > > > > > > > msg=MSG_ERR_FAILED_START_ENGINE_SERVICE) > > > > > > > > File "/usr/share/ovirt-engine/scripts/common_utils.py", line > > 499, > > > > > in > > > > > > > > execCmd > > > > > > > > raise Exception(msg) > > > > > > > > Exception: Error: Can't start ovirt-engine > > > > > > > > > > > > > > > > Curiously is there a documented process somewhere for backing > > up > > > > > > > > data > > > > > > > from > > > > > > > > an FC17 ovirt install and doing a fresh install on a FC18 box > > then > > > > > > > > restoring the FC17 database + ovirt config data? > > > > > > > > > > > > > > > > Guessing it goes something like this: (someone please confirm) > > > > > > > > > > > > > > > > Back up the following directories and files: > > > > > > > > /etc/ovirt-engine > > > > > > > > /etc/pki/ovirt-engine > > > > > > > > /etc/pki/ovirt-engine-backups > > > > > > > > /var/lib/ovirt-engine/backups > > > > > > > > /var/lib/ovirt-engine/deployments > > > > > > > > /root/.rnd > > > > > > > > > > > > > > > > Dump a backup of the engine database > > > > > > > > > > > > > > > > Install ovirt-engine on FC18 system > > > > > > > > run engine-setup (answer questions same as prior install from > > FC17) > > > > > > > > upon completion of engine-setup stop the engine service > > > > > > > > restore all the above files and directories > > > > > > > > > > > > > > > > Drop the engine databse > > > > > > > > Restore the backed up engine database > > > > > > > > > > > > > > > > FC17 --> FC18 upgrade = icky esp. with ovirt involved as part > > of > > > > > > > > the > > > > > > > upgrade > > > > > > > > > > > > > > > > Thus it seems the easiest way to solve this is to bite the > > bullet > > > > > > > > and > > > > > > > move > > > > > > > > to FC18 providing the backup/restore works. > > > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 4:02 PM, Alon Bar-Lev < > > alonbl at redhat.com> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > OK... the systemd macros are missing in fedora 17... > > > > > > > > > > > > > > > > > > Put the following file and rebuild. > > > > > > > > > I may need to add some workaround if many people still use > > > > > fedora-17 > > > > > > > for > > > > > > > > > master. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Alon > > > > > > > > > > > > > > > > > > /etc/rpm/macros.systemd-fc18 > > > > > > > > > --- > > > > > > > > > %systemd_post() \ > > > > > > > > > if [ $1 -eq 1 ] ; then \ > > > > > > > > > # Initial installation \ > > > > > > > > > /usr/bin/systemctl preset %{?*} >/dev/null 2>&1 || : > > \ > > > > > > > > > fi \ > > > > > > > > > %{nil} > > > > > > > > > > > > > > > > > > %systemd_preun() \ > > > > > > > > > if [ $1 -eq 0 ] ; then \ > > > > > > > > > # Package removal, not upgrade \ > > > > > > > > > /usr/bin/systemctl --no-reload disable %{?*} > > > /dev/null > > > > > 2>&1 > > > > > > > || : > > > > > > > > > \ > > > > > > > > > /usr/bin/systemctl stop %{?*} > /dev/null 2>&1 || : \ > > > > > > > > > fi \ > > > > > > > > > %{nil} > > > > > > > > > > > > > > > > > > %systemd_postun() \ > > > > > > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > > > > > > %{nil} > > > > > > > > > > > > > > > > > > %systemd_postun_with_restart() \ > > > > > > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > > > > > > if [ $1 -ge 1 ] ; then \ > > > > > > > > > # Package upgrade, not uninstall \ > > > > > > > > > /usr/bin/systemctl try-restart %{?*} >/dev/null 2>&1 > > || : > > > > > > > > > \ > > > > > > > > > fi \ > > > > > > > > > %{nil} > > > > > > > > > --- > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Dead Horse" > > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > > Cc: engine-devel at ovirt.org > > > > > > > > > > Sent: Wednesday, April 10, 2013 11:59:15 PM > > > > > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest > > master > > > > > > > > > > > > > > > > > > > > Correct, FC17 > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 3:32 PM, Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Is this fedora 17 or 18? > > > > > > > > > > > > > > > > > > > > > > I guess it is fedora 17. > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Dead Horse" > > > > > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > > > > > Sent: Wednesday, April 10, 2013 11:23:10 PM > > > > > > > > > > > > Subject: [Engine-devel] upgrade failing with latest > > master > > > > > > > > > > > > > > > > > > > > > > > > logs attached > > > > > > > > > > > > > > > > > > > > > > > > First attempt: > > > > > > > > > > > > 2013-04-10 13:57:32::ERROR::common_utils::355::root:: > > YUM: > > > > > FAIL: > > > > > > > > > Error in > > > > > > > > > > > > PREUN scriptlet in rpm package > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: > > YUM: > > > > > VERB: > > > > > > > > > Script > > > > > > > > > > > sink: > > > > > > > > > > > > /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control > > > > > > > > > > > > error: > > %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > > > > scriptlet > > > > > > > > > > > failed, > > > > > > > > > > > > exit status 1 > > > > > > > > > > > > 2013-04-10 13:57:32::DEBUG::common_utils::347::root:: > > YUM: > > > > > VERB: > > > > > > > > > Done: > > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > > > > > > > > > > > > Second attempt: > > > > > > > > > > > > 2013-04-10 15:12:11::DEBUG::common_utils::347::root:: > > YUM: > > > > > VERB: > > > > > > > > > Building > > > > > > > > > > > > transaction > > > > > > > > > > > > 2013-04-10 15:12:12::ERROR::common_utils::355::root:: > > YUM: > > > > > FAIL: > > > > > > > > > > > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch requires > > > > > > > ovirt-engine = > > > > > > > > > > > > 3.3.0-14.fc17'] > > > > > > > > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::347::root:: > > YUM: > > > > > VERB: > > > > > > > > > > > Performing > > > > > > > > > > > > rollback > > > > > > > > > > > > 2013-04-10 15:12:12::DEBUG::common_utils::1410::root:: > > > > > Locking > > > > > > > rpms > > > > > > > > > in > > > > > > > > > > > > yum-version-lock > > > > > > > > > > > > 2013-04-10 > > 15:12:12::ERROR::engine-upgrade::1299::root:: > > > > > > > Traceback > > > > > > > > > (most > > > > > > > > > > > > recent call last): > > > > > > > > > > > > File "/bin/engine-upgrade", line 1292, in > > > > > > > > > > > > main(options) > > > > > > > > > > > > File "/bin/engine-upgrade", line 1142, in main > > > > > > > > > > > > runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) > > > > > > > > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > > > > > > > > func() > > > > > > > > > > > > File "/bin/engine-upgrade", line 310, in begin > > > > > > > > > > > > self.emptyTransaction = not > > > > > > > > > > > > self._miniyum.buildTransaction() > > > > > > > > > > > > File "/usr/share/ovirt-engine/scripts/miniyum.py", line > > > > > > > > > > > > 761, > > > > > in > > > > > > > > > > > > buildTransaction > > > > > > > > > > > > raise yum.Errors.YumBaseError(msg) > > > > > > > > > > > > YumBaseError: > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch > > > > > > > requires > > > > > > > > > > > > ovirt-engine = 3.3.0-14.fc17'] > > > > > > > > > > > > > > > > > > > > > > > > Realizing things were now hosed: > > > > > > > > > > > > [root at ovirtfoo /]# yum erase ovirt-* otopi-* > > > > > > > > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, > > > > > > > versionlock > > > > > > > > > > > > Resolving Dependencies > > > > > > > > > > > > --> Running transaction check > > > > > > > > > > > > ---> Package otopi.noarch 0:3.3.0-15.fc17 will be > > erased > > > > > > > > > > > > ---> Package otopi-java.noarch 0:3.3.0-15.fc17 will be > > > > > > > > > > > > erased > > > > > > > > > > > > ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 will > > be > > > > > erased > > > > > > > > > > > > ---> Package ovirt-engine-backend.noarch > > 0:3.3.0-14.fc17 > > > > > will be > > > > > > > > > erased > > > > > > > > > > > > ---> Package ovirt-engine-backend.noarch > > 0:3.3.0-15.fc17 > > > > > will be > > > > > > > > > erased > > > > > > > > > > > > ---> Package ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > > will > > > > > be > > > > > > > erased > > > > > > > > > > > > ---> Package ovirt-engine-dbscripts.noarch > > 0:3.3.0-14.fc17 > > > > > will > > > > > > > be > > > > > > > > > erased > > > > > > > > > > > > ---> Package ovirt-engine-restapi.noarch > > 0:3.3.0-14.fc17 > > > > > will be > > > > > > > > > erased > > > > > > > > > > > > ---> Package ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > > will > > > > > be > > > > > > > erased > > > > > > > > > > > > ---> Package ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > > will > > > > > be > > > > > > > erased > > > > > > > > > > > > ---> Package ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > > will > > > > > be > > > > > > > erased > > > > > > > > > > > > ---> Package ovirt-engine-userportal.noarch > > 0:3.3.0-14.fc17 > > > > > will > > > > > > > be > > > > > > > > > > > erased > > > > > > > > > > > > ---> Package ovirt-engine-webadmin-portal.noarch > > > > > 0:3.3.0-14.fc17 > > > > > > > > > will be > > > > > > > > > > > > erased > > > > > > > > > > > > ---> Package ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > > will > > > > > > > > > > > > be > > > > > > > erased > > > > > > > > > > > > ---> Package ovirt-host-deploy-java.noarch > > 0:3.3.0-15.fc17 > > > > > will > > > > > > > be > > > > > > > > > erased > > > > > > > > > > > > ---> Package ovirt-image-uploader.noarch > > 0:3.3.0-15.fc17 > > > > > will be > > > > > > > > > erased > > > > > > > > > > > > ---> Package ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > > will > > > > > be > > > > > > > erased > > > > > > > > > > > > ---> Package ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > will > > > > > be > > > > > > > > > erased > > > > > > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > Removing: > > > > > > > > > > > > otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k > > > > > > > > > > > > otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k > > > > > > > > > > > > ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine 1.3 M > > > > > > > > > > > > ovirt-engine-backend noarch 3.3.0-14.fc17 > > @ovirt-engine 20 > > > > > > > > > > > > M > > > > > > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 > > @ovirt-engine 20 > > > > > > > > > > > > M > > > > > > > > > > > > ovirt-engine-cli noarch 3.3.0.1-15.fc17 @ovirt-engine > > 557 k > > > > > > > > > > > > ovirt-engine-dbscripts noarch 3.3.0-14.fc17 > > @ovirt-engine > > > > > 816 k > > > > > > > > > > > > ovirt-engine-restapi noarch 3.3.0-14.fc17 > > @ovirt-engine 1.0 > > > > > > > > > > > > M > > > > > > > > > > > > ovirt-engine-sdk noarch 3.3.0.1-15.fc17 @ovirt-engine > > 3.1 M > > > > > > > > > > > > ovirt-engine-setup noarch 3.3.0-15.fc17 @ovirt-engine > > 653 k > > > > > > > > > > > > ovirt-engine-tools noarch 3.3.0-14.fc17 @ovirt-engine > > 178 k > > > > > > > > > > > > ovirt-engine-userportal noarch 3.3.0-14.fc17 > > @ovirt-engine > > > > > 23 M > > > > > > > > > > > > ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 > > > > > @ovirt-engine > > > > > > > 32 M > > > > > > > > > > > > ovirt-host-deploy noarch 3.3.0-15.fc17 @ovirt-engine > > 211 k > > > > > > > > > > > > ovirt-host-deploy-java noarch 3.3.0-15.fc17 > > @ovirt-engine > > > > > > > > > > > > 11 > > > > > k > > > > > > > > > > > > ovirt-image-uploader noarch 3.3.0-15.fc17 > > @ovirt-engine 923 > > > > > > > > > > > > k > > > > > > > > > > > > ovirt-iso-uploader noarch 3.3.0-15.fc17 @ovirt-engine > > 98 k > > > > > > > > > > > > ovirt-log-collector noarch 3.3.0-15.fc17 @ovirt-engine > > 133 > > > > > > > > > > > > k > > > > > > > > > > > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > Remove 18 Packages > > > > > > > > > > > > > > > > > > > > > > > > Installed size: 104 M > > > > > > > > > > > > Is this ok [y/N]: y > > > > > > > > > > > > Downloading Packages: > > > > > > > > > > > > Running Transaction Check > > > > > > > > > > > > Running Transaction Test > > > > > > > > > > > > Transaction Test Succeeded > > > > > > > > > > > > Running Transaction > > > > > > > > > > > > Erasing : ovirt-engine-backend.noarch 1/18 > > > > > > > > > > > > Erasing : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch > > 2/18 > > > > > > > > > > > > Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch > > 3/18 > > > > > > > > > > > > Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch 4/18 > > > > > > > > > > > > Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch 5/18 > > > > > > > > > > > > Erasing : ovirt-engine-userportal-3.3.0-14.fc17.noarch > > 6/18 > > > > > > > > > > > > Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 > > > > > > > > > > > > warning: /etc/ovirt-engine/engine.conf saved as > > > > > > > > > > > > /etc/ovirt-engine/engine.conf.rpmsave > > > > > > > > > > > > Erasing : > > ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > > > > > 8/18 > > > > > > > > > > > > Erasing : ovirt-host-deploy-java-3.3.0-15.fc17.noarch > > 9/18 > > > > > > > > > > > > Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 > > > > > > > > > > > > Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch 11/18 > > > > > > > > > > > > Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch > > 12/18 > > > > > > > > > > > > warning: /etc/ovirt-engine/imageuploader.conf saved as > > > > > > > > > > > > /etc/ovirt-engine/imageuploader.conf.rpmsave > > > > > > > > > > > > Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch 13/18 > > > > > > > > > > > > warning: /etc/ovirt-engine/isouploader.conf saved as > > > > > > > > > > > > /etc/ovirt-engine/isouploader.conf.rpmsave > > > > > > > > > > > > Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch > > 14/18 > > > > > > > > > > > > warning: /etc/ovirt-engine/logcollector.conf saved as > > > > > > > > > > > > /etc/ovirt-engine/logcollector.conf.rpmsave > > > > > > > > > > > > Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch 15/18 > > > > > > > > > > > > Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch 16/18 > > > > > > > > > > > > Erasing : otopi-3.3.0-15.fc17.noarch 17/18 > > > > > > > > > > > > Error in PREUN scriptlet in rpm package > > > > > > > > > > > > ovirt-engine-backend > > > > > > > > > > > > /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control > > > > > > > > > > > > error: > > %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > > > > scriptlet > > > > > > > > > > > failed, > > > > > > > > > > > > exit status 1 > > > > > > > > > > > > Verifying : otopi-3.3.0-15.fc17.noarch 1/18 > > > > > > > > > > > > Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 > > > > > > > > > > > > Verifying : ovirt-log-collector-3.3.0-15.fc17.noarch > > 3/18 > > > > > > > > > > > > Verifying : > > > > > > > > > > > > ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > > > > > > > 4/18 > > > > > > > > > > > > Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch 5/18 > > > > > > > > > > > > Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch > > 6/18 > > > > > > > > > > > > Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch > > 7/18 > > > > > > > > > > > > Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch > > 8/18 > > > > > > > > > > > > Verifying : ovirt-engine-restapi-3.3.0-14.fc17.noarch > > 9/18 > > > > > > > > > > > > Verifying : > > ovirt-engine-userportal-3.3.0-14.fc17.noarch > > > > > 10/18 > > > > > > > > > > > > Verifying : ovirt-host-deploy-java-3.3.0-15.fc17.noarch > > > > > > > > > > > > 11/18 > > > > > > > > > > > > Verifying : ovirt-image-uploader-3.3.0-15.fc17.noarch > > 12/18 > > > > > > > > > > > > Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch > > 13/18 > > > > > > > > > > > > Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch > > 14/18 > > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch was supposed > > to > > > > > > > > > > > > be > > > > > > > removed > > > > > > > > > but > > > > > > > > > > > is > > > > > > > > > > > > not! > > > > > > > > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch > > 15/18 > > > > > > > > > > > > Verifying : ovirt-engine-backend-3.3.0-14.fc17.noarch > > 16/18 > > > > > > > > > > > > Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 > > > > > > > > > > > > Verifying : ovirt-engine-dbscripts-3.3.0-14.fc17.noarch > > > > > > > > > > > > 18/18 > > > > > > > > > > > > > > > > > > > > > > > > Removed: > > > > > > > > > > > > otopi.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > otopi-java.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > ovirt-engine.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > > > > > > > > > > > > ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > > > > > > > > > > > > ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > > > > > > > Failed: > > > > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > > > > > > > Complete! > > > > > > > > > > > > [root at ovirtfoo /]# rpm -qa | grep oto > > > > > > > > > > > > protobuf-java-2.4.1-12.fc17.x86_64 > > > > > > > > > > > > libgphoto2-2.4.14-1.fc17.x86_64 > > > > > > > > > > > > [root at ovirtfoo /]# rpm -qa | grep ovirt > > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > [root at ovirtfoo /]# yum erase > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > Loaded plugins: langpacks, presto, refresh-packagekit, > > > > > > > versionlock > > > > > > > > > > > > Resolving Dependencies > > > > > > > > > > > > --> Running transaction check > > > > > > > > > > > > ---> Package ovirt-engine-backend.noarch > > 0:3.3.0-15.fc17 > > > > > will be > > > > > > > > > erased > > > > > > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > Removing: > > > > > > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 > > @ovirt-engine 20 > > > > > > > > > > > > M > > > > > > > > > > > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > Remove 1 Package > > > > > > > > > > > > > > > > > > > > > > > > Installed size: 20 M > > > > > > > > > > > > Is this ok [y/N]: y > > > > > > > > > > > > Downloading Packages: > > > > > > > > > > > > Running Transaction Check > > > > > > > > > > > > Running Transaction Test > > > > > > > > > > > > Transaction Test Succeeded > > > > > > > > > > > > Running Transaction > > > > > > > > > > > > Error in PREUN scriptlet in rpm package > > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control > > > > > > > > > > > > error: > > %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > > > > scriptlet > > > > > > > > > > > failed, > > > > > > > > > > > > exit status 1 > > > > > > > > > > > > Verifying : ovirt-engine-backend-3.3.0-15.fc17.noarch > > 1/1 > > > > > > > > > > > > > > > > > > > > > > > > Failed: > > > > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > > > > > > > Complete! > > > > > > > > > > > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From deadhorseconsulting at gmail.com Mon Apr 15 21:36:54 2013 From: deadhorseconsulting at gmail.com (Dead Horse) Date: Mon, 15 Apr 2013 16:36:54 -0500 Subject: [Engine-devel] upgrade failing with latest master In-Reply-To: <1383860034.427016.1366053819732.JavaMail.root@redhat.com> References: <383901841.1348447.1365716007616.JavaMail.root@redhat.com> <1273669048.47013.1365880663823.JavaMail.root@redhat.com> <1446063899.366491.1366042252302.JavaMail.root@redhat.com> <5152300.367225.1366042400592.JavaMail.root@redhat.com> <1383860034.427016.1366053819732.JavaMail.root@redhat.com> Message-ID: Strangely I reverted back the ovirt test VM back to a state in time about 3 weeks back. I then upgraded with rpms built from commit: b4cc077888ba11871aa4837a73498a231050e2fc. I then upgraded that with rpms built from master with the macros packaged and all was well. I then forked a fresh FC17 VM updated it, and freshly installed rpms from commit: b4cc077888ba11871aa4837a73498a231050e2fc. I then again attempted upgrade with rpms built from master and again got the above failures. Very odd something must be different with the fresh install vs an upgraded one. I will take the suggestion of moving to FC18. I will try out the fresh FC18 build/install and backup/restore approach rather then the upgrade approach. - DHC On Mon, Apr 15, 2013 at 2:23 PM, Alon Bar-Lev wrote: > It was not single commit, please take most recent master (HEAD) > Please attach logs and systemd journal messages. > Thanks! > > ----- Original Message ----- > > From: "Dead Horse" > > To: "Alon Bar-Lev" > > Cc: engine-devel at ovirt.org > > Sent: Monday, April 15, 2013 8:25:48 PM > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > Guessing you are referring to the changes you made at commit: > > eb8d8010a35a20a871c0af7674879da548d971f1 > > and the few commits prior? > > > > If so I have built engine from master since then along with the macros > file > > added to /etc/rpm before initiating the build on my FC17 build VM. > > All builds even with the macros included still result in the above most > > recent reported upgrade failures with the engine service. > > > > - DHC > > > > > > > > On Mon, Apr 15, 2013 at 11:13 AM, Alon Bar-Lev > wrote: > > > > > BTW: best is to use fedora-18... If not, please put the attached file > at > > > /etc/rpm before packaging. > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Alon Bar-Lev" > > > > To: "Dead Horse" > > > > Cc: engine-devel at ovirt.org > > > > Sent: Monday, April 15, 2013 7:10:52 PM > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > Oh... it is before I rewrote the engine service. > > > > I thought that you facing issue after the re-write. > > > > Can you please give a try to the master HEAD? > > > > > > > > ----- Original Message ----- > > > > > From: "Dead Horse" > > > > > To: "Alon Bar-Lev" > > > > > Cc: engine-devel at ovirt.org > > > > > Sent: Monday, April 15, 2013 6:41:33 PM > > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > > > Engine version I am attempting to upgrade was built from this > commit: > > > > > b4cc077888ba11871aa4837a73498a231050e2fc > > > > > I built it same as always on a fully up to date FC17 VM. > > > > > EG: Check out sources, cd /path/to/source/ make "rpm" > > > > > > > > > > I am unable to locate any .rpmnew in /etc after or before upgrade. > > > > > > > > > > - DHC > > > > > > > > > > > > > > > On Sat, Apr 13, 2013 at 2:17 PM, Alon Bar-Lev > > > wrote: > > > > > > > > > > > > > > > > > Which version do you use? > > > > > > Have you built it your-self? > > > > > > Have you settled all .rpmnew you have in /etc? > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Dead Horse" > > > > > > > To: "Alon Bar-Lev" > > > > > > > Cc: engine-devel at ovirt.org > > > > > > > Sent: Friday, April 12, 2013 9:20:51 PM > > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > > > > > > > Prior to engine-upgrade: > > > > > > > ovirt-engine.service - oVirt Engine > > > > > > > Loaded: loaded > (/usr/lib/systemd/system/ovirt-engine.service; > > > > > > enabled) > > > > > > > Active: active (running) since Fri, 12 Apr 2013 13:11:16 > > > -0500; > > > > > > 1min > > > > > > > 10s ago > > > > > > > Main PID: 9023 (java) > > > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > > ? 9023 engine-service -server -XX:+TieredCompilation > > > -Xms... > > > > > > > > > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > > > Started > > > > > > > engine ... > > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > > > Starting > > > > > > > engine... > > > > > > > > > > > > > > Stopping ovirt-engine service prior to engine-upgrade: > > > > > > > ovirt-engine.service - oVirt Engine > > > > > > > Loaded: loaded > (/usr/lib/systemd/system/ovirt-engine.service; > > > > > > enabled) > > > > > > > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 > > > > > > > 13:12:51 > > > > > > > -0500; 3s ago > > > > > > > Process: 9141 ExecStop=/usr/bin/engine-service stop > > > (code=exited, > > > > > > > status=0/SUCCESS) > > > > > > > Main PID: 9023 (code=exited, status=143) > > > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > > > > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > > > Started > > > > > > > engine ... > > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > > > Starting > > > > > > > engine... > > > > > > > Apr 12 13:12:50 ovirtfoo.ctt.med.ge.com engine-service[9141]: > > > Waiting > > > > > > up to > > > > > > > 1... > > > > > > > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: > > > Stopped > > > > > > > engine ... > > > > > > > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: > > > Stopping > > > > > > > engine... > > > > > > > > > > > > > > After running engine-upgrade: > > > > > > > ovirt-engine.service - oVirt Engine > > > > > > > Loaded: loaded > (/usr/lib/systemd/system/ovirt-engine.service; > > > > > > enabled) > > > > > > > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 > > > > > > > 13:18:22 > > > > > > > -0500; 41s ago > > > > > > > Main PID: 9168 (code=exited, status=143) > > > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > > > > > > > > > Apr 12 13:18:22 ovirtfoo.ctt.med.ge.com systemd[11198]: > Failed at > > > step > > > > > > EXEC > > > > > > > spawning /usr/bin/engine-service: No such file or directory > > > > > > > > > > > > > > After attemptining systemctl start ovirt-engine.service after > > > > > > > engine-upgrade: > > > > > > > ovirt-engine.service - oVirt Engine > > > > > > > Loaded: loaded > (/usr/lib/systemd/system/ovirt-engine.service; > > > > > > enabled) > > > > > > > Active: active (running) since Fri, 12 Apr 2013 13:19:43 > > > -0500; > > > > > > > 1s > > > > > > ago > > > > > > > Process: 11228 ExecStart=/usr/bin/engine-service start > > > > > > > (code=exited, > > > > > > > status=0/SUCCESS) > > > > > > > Main PID: 11229 (java) > > > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > > ? 11229 engine-service -server -XX:+TieredCompilation > > > -Xms1g > > > > > > > -Xmx1g -XX:PermSize=256m -XX:MaxPermSize=256m > > > > > > > -Djava.net.preferIPv4Stack=tr... > > > > > > > > > > > > > > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: > > > Started > > > > > > > engine process 11229. > > > > > > > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: > > > Starting > > > > > > > engine-service: [ OK ] > > > > > > > > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Apr 11, 2013 at 4:33 PM, Alon Bar-Lev < > alonbl at redhat.com> > > > > > > > wrote: > > > > > > > > > > > > > > > Please see what systemd has to say: > > > > > > > > > > > > > > > > # systemctl status ovirt-engine.service > > > > > > > > > > > > > > > > > > > > > > > > And no, I never tried to backup/restore... sorry... > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Dead Horse" > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > Cc: engine-devel at ovirt.org > > > > > > > > > Sent: Friday, April 12, 2013 12:28:01 AM > > > > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest > master > > > > > > > > > > > > > > > > > > Rebuilt the engine on my FC17 build VM with the macro file > > > above in > > > > > > > > > "/etc/rpm/" > > > > > > > > > Upon attempting upgrade on my FC17 upgrade test VM: > > > > > > > > > I still get a failure to start the engine > > > > > > > > > > > > > > > > > > 013-04-11 16:06:37::ERROR::engine-upgrade::1328::root:: > > > Traceback > > > > > > (most > > > > > > > > > recent call last): > > > > > > > > > File "/bin/engine-upgrade", line 1321, in > > > > > > > > > main(options) > > > > > > > > > File "/bin/engine-upgrade", line 1293, in main > > > > > > > > > runFunc([startEngine], MSG_INFO_START_ENGINE % > > > engineService) > > > > > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > > > > > func() > > > > > > > > > File "/bin/engine-upgrade", line 584, in startEngine > > > > > > > > > output, rc = utils.execCmd(cmdList=cmd, > failOnError=True, > > > > > > > > > msg=MSG_ERR_FAILED_START_ENGINE_SERVICE) > > > > > > > > > File "/usr/share/ovirt-engine/scripts/common_utils.py", > line > > > 499, > > > > > > in > > > > > > > > > execCmd > > > > > > > > > raise Exception(msg) > > > > > > > > > Exception: Error: Can't start ovirt-engine > > > > > > > > > > > > > > > > > > Curiously is there a documented process somewhere for > backing > > > up > > > > > > > > > data > > > > > > > > from > > > > > > > > > an FC17 ovirt install and doing a fresh install on a FC18 > box > > > then > > > > > > > > > restoring the FC17 database + ovirt config data? > > > > > > > > > > > > > > > > > > Guessing it goes something like this: (someone please > confirm) > > > > > > > > > > > > > > > > > > Back up the following directories and files: > > > > > > > > > /etc/ovirt-engine > > > > > > > > > /etc/pki/ovirt-engine > > > > > > > > > /etc/pki/ovirt-engine-backups > > > > > > > > > /var/lib/ovirt-engine/backups > > > > > > > > > /var/lib/ovirt-engine/deployments > > > > > > > > > /root/.rnd > > > > > > > > > > > > > > > > > > Dump a backup of the engine database > > > > > > > > > > > > > > > > > > Install ovirt-engine on FC18 system > > > > > > > > > run engine-setup (answer questions same as prior install > from > > > FC17) > > > > > > > > > upon completion of engine-setup stop the engine service > > > > > > > > > restore all the above files and directories > > > > > > > > > > > > > > > > > > Drop the engine databse > > > > > > > > > Restore the backed up engine database > > > > > > > > > > > > > > > > > > FC17 --> FC18 upgrade = icky esp. with ovirt involved as > part > > > of > > > > > > > > > the > > > > > > > > upgrade > > > > > > > > > > > > > > > > > > Thus it seems the easiest way to solve this is to bite the > > > bullet > > > > > > > > > and > > > > > > > > move > > > > > > > > > to FC18 providing the backup/restore works. > > > > > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 4:02 PM, Alon Bar-Lev < > > > alonbl at redhat.com> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > OK... the systemd macros are missing in fedora 17... > > > > > > > > > > > > > > > > > > > > Put the following file and rebuild. > > > > > > > > > > I may need to add some workaround if many people still > use > > > > > > fedora-17 > > > > > > > > for > > > > > > > > > > master. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Alon > > > > > > > > > > > > > > > > > > > > /etc/rpm/macros.systemd-fc18 > > > > > > > > > > --- > > > > > > > > > > %systemd_post() \ > > > > > > > > > > if [ $1 -eq 1 ] ; then \ > > > > > > > > > > # Initial installation \ > > > > > > > > > > /usr/bin/systemctl preset %{?*} >/dev/null 2>&1 > || : > > > \ > > > > > > > > > > fi \ > > > > > > > > > > %{nil} > > > > > > > > > > > > > > > > > > > > %systemd_preun() \ > > > > > > > > > > if [ $1 -eq 0 ] ; then \ > > > > > > > > > > # Package removal, not upgrade \ > > > > > > > > > > /usr/bin/systemctl --no-reload disable %{?*} > > > > /dev/null > > > > > > 2>&1 > > > > > > > > || : > > > > > > > > > > \ > > > > > > > > > > /usr/bin/systemctl stop %{?*} > /dev/null 2>&1 > || : \ > > > > > > > > > > fi \ > > > > > > > > > > %{nil} > > > > > > > > > > > > > > > > > > > > %systemd_postun() \ > > > > > > > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > > > > > > > %{nil} > > > > > > > > > > > > > > > > > > > > %systemd_postun_with_restart() \ > > > > > > > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > > > > > > > if [ $1 -ge 1 ] ; then \ > > > > > > > > > > # Package upgrade, not uninstall \ > > > > > > > > > > /usr/bin/systemctl try-restart %{?*} >/dev/null > 2>&1 > > > || : > > > > > > > > > > \ > > > > > > > > > > fi \ > > > > > > > > > > %{nil} > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Dead Horse" > > > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > > > Cc: engine-devel at ovirt.org > > > > > > > > > > > Sent: Wednesday, April 10, 2013 11:59:15 PM > > > > > > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest > > > master > > > > > > > > > > > > > > > > > > > > > > Correct, FC17 > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 3:32 PM, Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Is this fedora 17 or 18? > > > > > > > > > > > > > > > > > > > > > > > > I guess it is fedora 17. > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > From: "Dead Horse" > > > > > > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > > > > > > Sent: Wednesday, April 10, 2013 11:23:10 PM > > > > > > > > > > > > > Subject: [Engine-devel] upgrade failing with latest > > > master > > > > > > > > > > > > > > > > > > > > > > > > > > logs attached > > > > > > > > > > > > > > > > > > > > > > > > > > First attempt: > > > > > > > > > > > > > 2013-04-10 > 13:57:32::ERROR::common_utils::355::root:: > > > YUM: > > > > > > FAIL: > > > > > > > > > > Error in > > > > > > > > > > > > > PREUN scriptlet in rpm package > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > 2013-04-10 > 13:57:32::DEBUG::common_utils::347::root:: > > > YUM: > > > > > > VERB: > > > > > > > > > > Script > > > > > > > > > > > > sink: > > > > > > > > > > > > > /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control > > > > > > > > > > > > > error: > > > %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > > > > > scriptlet > > > > > > > > > > > > failed, > > > > > > > > > > > > > exit status 1 > > > > > > > > > > > > > 2013-04-10 > 13:57:32::DEBUG::common_utils::347::root:: > > > YUM: > > > > > > VERB: > > > > > > > > > > Done: > > > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > > > > > > > > > > > > > > Second attempt: > > > > > > > > > > > > > 2013-04-10 > 15:12:11::DEBUG::common_utils::347::root:: > > > YUM: > > > > > > VERB: > > > > > > > > > > Building > > > > > > > > > > > > > transaction > > > > > > > > > > > > > 2013-04-10 > 15:12:12::ERROR::common_utils::355::root:: > > > YUM: > > > > > > FAIL: > > > > > > > > > > > > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch > requires > > > > > > > > ovirt-engine = > > > > > > > > > > > > > 3.3.0-14.fc17'] > > > > > > > > > > > > > 2013-04-10 > 15:12:12::DEBUG::common_utils::347::root:: > > > YUM: > > > > > > VERB: > > > > > > > > > > > > Performing > > > > > > > > > > > > > rollback > > > > > > > > > > > > > 2013-04-10 > 15:12:12::DEBUG::common_utils::1410::root:: > > > > > > Locking > > > > > > > > rpms > > > > > > > > > > in > > > > > > > > > > > > > yum-version-lock > > > > > > > > > > > > > 2013-04-10 > > > 15:12:12::ERROR::engine-upgrade::1299::root:: > > > > > > > > Traceback > > > > > > > > > > (most > > > > > > > > > > > > > recent call last): > > > > > > > > > > > > > File "/bin/engine-upgrade", line 1292, in > > > > > > > > > > > > > main(options) > > > > > > > > > > > > > File "/bin/engine-upgrade", line 1142, in main > > > > > > > > > > > > > runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) > > > > > > > > > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > > > > > > > > > func() > > > > > > > > > > > > > File "/bin/engine-upgrade", line 310, in begin > > > > > > > > > > > > > self.emptyTransaction = not > > > > > > > > > > > > > self._miniyum.buildTransaction() > > > > > > > > > > > > > File "/usr/share/ovirt-engine/scripts/miniyum.py", > line > > > > > > > > > > > > > 761, > > > > > > in > > > > > > > > > > > > > buildTransaction > > > > > > > > > > > > > raise yum.Errors.YumBaseError(msg) > > > > > > > > > > > > > YumBaseError: > > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch > > > > > > > > requires > > > > > > > > > > > > > ovirt-engine = 3.3.0-14.fc17'] > > > > > > > > > > > > > > > > > > > > > > > > > > Realizing things were now hosed: > > > > > > > > > > > > > [root at ovirtfoo /]# yum erase ovirt-* otopi-* > > > > > > > > > > > > > Loaded plugins: langpacks, presto, > refresh-packagekit, > > > > > > > > versionlock > > > > > > > > > > > > > Resolving Dependencies > > > > > > > > > > > > > --> Running transaction check > > > > > > > > > > > > > ---> Package otopi.noarch 0:3.3.0-15.fc17 will be > > > erased > > > > > > > > > > > > > ---> Package otopi-java.noarch 0:3.3.0-15.fc17 > will be > > > > > > > > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 > will > > > be > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-engine-backend.noarch > > > 0:3.3.0-14.fc17 > > > > > > will be > > > > > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-engine-backend.noarch > > > 0:3.3.0-15.fc17 > > > > > > will be > > > > > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-engine-cli.noarch > 0:3.3.0.1-15.fc17 > > > will > > > > > > be > > > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-engine-dbscripts.noarch > > > 0:3.3.0-14.fc17 > > > > > > will > > > > > > > > be > > > > > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-engine-restapi.noarch > > > 0:3.3.0-14.fc17 > > > > > > will be > > > > > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-engine-sdk.noarch > 0:3.3.0.1-15.fc17 > > > will > > > > > > be > > > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-engine-setup.noarch > 0:3.3.0-15.fc17 > > > will > > > > > > be > > > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-engine-tools.noarch > 0:3.3.0-14.fc17 > > > will > > > > > > be > > > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-engine-userportal.noarch > > > 0:3.3.0-14.fc17 > > > > > > will > > > > > > > > be > > > > > > > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-engine-webadmin-portal.noarch > > > > > > 0:3.3.0-14.fc17 > > > > > > > > > > will be > > > > > > > > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-host-deploy.noarch > 0:3.3.0-15.fc17 > > > will > > > > > > > > > > > > > be > > > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-host-deploy-java.noarch > > > 0:3.3.0-15.fc17 > > > > > > will > > > > > > > > be > > > > > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-image-uploader.noarch > > > 0:3.3.0-15.fc17 > > > > > > will be > > > > > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-iso-uploader.noarch > 0:3.3.0-15.fc17 > > > will > > > > > > be > > > > > > > > erased > > > > > > > > > > > > > ---> Package ovirt-log-collector.noarch > 0:3.3.0-15.fc17 > > > > > > > > > > > > > will > > > > > > be > > > > > > > > > > erased > > > > > > > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > > Removing: > > > > > > > > > > > > > otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k > > > > > > > > > > > > > otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k > > > > > > > > > > > > > ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine > 1.3 M > > > > > > > > > > > > > ovirt-engine-backend noarch 3.3.0-14.fc17 > > > @ovirt-engine 20 > > > > > > > > > > > > > M > > > > > > > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 > > > @ovirt-engine 20 > > > > > > > > > > > > > M > > > > > > > > > > > > > ovirt-engine-cli noarch 3.3.0.1-15.fc17 > @ovirt-engine > > > 557 k > > > > > > > > > > > > > ovirt-engine-dbscripts noarch 3.3.0-14.fc17 > > > @ovirt-engine > > > > > > 816 k > > > > > > > > > > > > > ovirt-engine-restapi noarch 3.3.0-14.fc17 > > > @ovirt-engine 1.0 > > > > > > > > > > > > > M > > > > > > > > > > > > > ovirt-engine-sdk noarch 3.3.0.1-15.fc17 > @ovirt-engine > > > 3.1 M > > > > > > > > > > > > > ovirt-engine-setup noarch 3.3.0-15.fc17 > @ovirt-engine > > > 653 k > > > > > > > > > > > > > ovirt-engine-tools noarch 3.3.0-14.fc17 > @ovirt-engine > > > 178 k > > > > > > > > > > > > > ovirt-engine-userportal noarch 3.3.0-14.fc17 > > > @ovirt-engine > > > > > > 23 M > > > > > > > > > > > > > ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 > > > > > > @ovirt-engine > > > > > > > > 32 M > > > > > > > > > > > > > ovirt-host-deploy noarch 3.3.0-15.fc17 > @ovirt-engine > > > 211 k > > > > > > > > > > > > > ovirt-host-deploy-java noarch 3.3.0-15.fc17 > > > @ovirt-engine > > > > > > > > > > > > > 11 > > > > > > k > > > > > > > > > > > > > ovirt-image-uploader noarch 3.3.0-15.fc17 > > > @ovirt-engine 923 > > > > > > > > > > > > > k > > > > > > > > > > > > > ovirt-iso-uploader noarch 3.3.0-15.fc17 > @ovirt-engine > > > 98 k > > > > > > > > > > > > > ovirt-log-collector noarch 3.3.0-15.fc17 > @ovirt-engine > > > 133 > > > > > > > > > > > > > k > > > > > > > > > > > > > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > > Remove 18 Packages > > > > > > > > > > > > > > > > > > > > > > > > > > Installed size: 104 M > > > > > > > > > > > > > Is this ok [y/N]: y > > > > > > > > > > > > > Downloading Packages: > > > > > > > > > > > > > Running Transaction Check > > > > > > > > > > > > > Running Transaction Test > > > > > > > > > > > > > Transaction Test Succeeded > > > > > > > > > > > > > Running Transaction > > > > > > > > > > > > > Erasing : ovirt-engine-backend.noarch 1/18 > > > > > > > > > > > > > Erasing : > ovirt-engine-dbscripts-3.3.0-14.fc17.noarch > > > 2/18 > > > > > > > > > > > > > Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch > > > 3/18 > > > > > > > > > > > > > Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch > 4/18 > > > > > > > > > > > > > Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch > 5/18 > > > > > > > > > > > > > Erasing : > ovirt-engine-userportal-3.3.0-14.fc17.noarch > > > 6/18 > > > > > > > > > > > > > Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 > > > > > > > > > > > > > warning: /etc/ovirt-engine/engine.conf saved as > > > > > > > > > > > > > /etc/ovirt-engine/engine.conf.rpmsave > > > > > > > > > > > > > Erasing : > > > ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > > > > > > 8/18 > > > > > > > > > > > > > Erasing : > ovirt-host-deploy-java-3.3.0-15.fc17.noarch > > > 9/18 > > > > > > > > > > > > > Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 > > > > > > > > > > > > > Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch > 11/18 > > > > > > > > > > > > > Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch > > > 12/18 > > > > > > > > > > > > > warning: /etc/ovirt-engine/imageuploader.conf > saved as > > > > > > > > > > > > > /etc/ovirt-engine/imageuploader.conf.rpmsave > > > > > > > > > > > > > Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch > 13/18 > > > > > > > > > > > > > warning: /etc/ovirt-engine/isouploader.conf saved > as > > > > > > > > > > > > > /etc/ovirt-engine/isouploader.conf.rpmsave > > > > > > > > > > > > > Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch > > > 14/18 > > > > > > > > > > > > > warning: /etc/ovirt-engine/logcollector.conf saved > as > > > > > > > > > > > > > /etc/ovirt-engine/logcollector.conf.rpmsave > > > > > > > > > > > > > Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch > 15/18 > > > > > > > > > > > > > Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch > 16/18 > > > > > > > > > > > > > Erasing : otopi-3.3.0-15.fc17.noarch 17/18 > > > > > > > > > > > > > Error in PREUN scriptlet in rpm package > > > > > > > > > > > > > ovirt-engine-backend > > > > > > > > > > > > > /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control > > > > > > > > > > > > > error: > > > %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > > > > > scriptlet > > > > > > > > > > > > failed, > > > > > > > > > > > > > exit status 1 > > > > > > > > > > > > > Verifying : otopi-3.3.0-15.fc17.noarch 1/18 > > > > > > > > > > > > > Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 > > > > > > > > > > > > > Verifying : > ovirt-log-collector-3.3.0-15.fc17.noarch > > > 3/18 > > > > > > > > > > > > > Verifying : > > > > > > > > > > > > > ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > > > > > > > > 4/18 > > > > > > > > > > > > > Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch > 5/18 > > > > > > > > > > > > > Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch > > > 6/18 > > > > > > > > > > > > > Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch > > > 7/18 > > > > > > > > > > > > > Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch > > > 8/18 > > > > > > > > > > > > > Verifying : > ovirt-engine-restapi-3.3.0-14.fc17.noarch > > > 9/18 > > > > > > > > > > > > > Verifying : > > > ovirt-engine-userportal-3.3.0-14.fc17.noarch > > > > > > 10/18 > > > > > > > > > > > > > Verifying : > ovirt-host-deploy-java-3.3.0-15.fc17.noarch > > > > > > > > > > > > > 11/18 > > > > > > > > > > > > > Verifying : > ovirt-image-uploader-3.3.0-15.fc17.noarch > > > 12/18 > > > > > > > > > > > > > Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch > > > 13/18 > > > > > > > > > > > > > Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch > > > 14/18 > > > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch was > supposed > > > to > > > > > > > > > > > > > be > > > > > > > > removed > > > > > > > > > > but > > > > > > > > > > > > is > > > > > > > > > > > > > not! > > > > > > > > > > > > > Verifying : > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > 15/18 > > > > > > > > > > > > > Verifying : > ovirt-engine-backend-3.3.0-14.fc17.noarch > > > 16/18 > > > > > > > > > > > > > Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 > > > > > > > > > > > > > Verifying : > ovirt-engine-dbscripts-3.3.0-14.fc17.noarch > > > > > > > > > > > > > 18/18 > > > > > > > > > > > > > > > > > > > > > > > > > > Removed: > > > > > > > > > > > > > otopi.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > otopi-java.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > ovirt-engine.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > > ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > > > > > > > > > > > > > ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > > ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > > ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > > > > > > > > > > > > > ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > > ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > > ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > > ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > > > > > > > > > Failed: > > > > > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > > > > > > > > > Complete! > > > > > > > > > > > > > [root at ovirtfoo /]# rpm -qa | grep oto > > > > > > > > > > > > > protobuf-java-2.4.1-12.fc17.x86_64 > > > > > > > > > > > > > libgphoto2-2.4.14-1.fc17.x86_64 > > > > > > > > > > > > > [root at ovirtfoo /]# rpm -qa | grep ovirt > > > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > [root at ovirtfoo /]# yum erase > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > Loaded plugins: langpacks, presto, > refresh-packagekit, > > > > > > > > versionlock > > > > > > > > > > > > > Resolving Dependencies > > > > > > > > > > > > > --> Running transaction check > > > > > > > > > > > > > ---> Package ovirt-engine-backend.noarch > > > 0:3.3.0-15.fc17 > > > > > > will be > > > > > > > > > > erased > > > > > > > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > > Removing: > > > > > > > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 > > > @ovirt-engine 20 > > > > > > > > > > > > > M > > > > > > > > > > > > > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > > Remove 1 Package > > > > > > > > > > > > > > > > > > > > > > > > > > Installed size: 20 M > > > > > > > > > > > > > Is this ok [y/N]: y > > > > > > > > > > > > > Downloading Packages: > > > > > > > > > > > > > Running Transaction Check > > > > > > > > > > > > > Running Transaction Test > > > > > > > > > > > > > Transaction Test Succeeded > > > > > > > > > > > > > Running Transaction > > > > > > > > > > > > > Error in PREUN scriptlet in rpm package > > > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control > > > > > > > > > > > > > error: > > > %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > > > > > scriptlet > > > > > > > > > > > > failed, > > > > > > > > > > > > > exit status 1 > > > > > > > > > > > > > Verifying : > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > 1/1 > > > > > > > > > > > > > > > > > > > > > > > > > > Failed: > > > > > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > > > > > > > > > Complete! > > > > > > > > > > > > > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > 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: From wei.d.chen at intel.com Tue Apr 16 02:43:52 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Tue, 16 Apr 2013 02:43:52 +0000 Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: <448237996.384685.1366009557875.JavaMail.root@redhat.com> References: <2086624134.2126667.1365585146256.JavaMail.root@redhat.com> <1413514785.890062.1365593037724.JavaMail.root@redhat.com> <996306366.2192571.1365595398217.JavaMail.root@redhat.com> <189243164.4209095.1366006840007.JavaMail.root@redhat.com> <516BA2E8.7090207@redhat.com> <448237996.384685.1366009557875.JavaMail.root@redhat.com> Message-ID: Hi, I just found there maybe another big performance issue. Currently, I am not sure how long this periodic check need, suppose there are 100+ hosts running in a trusted cluster, one host may take 3-5 seconds to poll attestation server, it will still take 5-9 mins to get all of the status for these hosts. Would we poll each host when this host's adding into cluster only once, as host's status change from trusted to untrusted and take effect is depended on host's reboot operation, is it possible for us to make it an event driven notification? Best Regards, Dave Chen -----Original Message----- From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Doron Fediuck Sent: Monday, April 15, 2013 3:06 PM To: Itamar Heim Cc: Oved Ourfalli; engine-devel at ovirt.org Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 ----- Original Message ----- > From: "Itamar Heim" > To: "Oved Ourfalli" > Cc: engine-devel at ovirt.org > Sent: Monday, April 15, 2013 9:49:12 AM > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > integration with oVirt in 4/9 > > On 04/15/2013 09:20 AM, Oved Ourfalli wrote: > > > > > > ----- Original Message ----- > >> From: "Wei D Chen" > >> To: "Doron Fediuck" , "Ofri Masad" > >> > >> Cc: engine-devel at ovirt.org > >> Sent: Monday, April 15, 2013 8:54:18 AM > >> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > >> integration with oVirt in 4/9 > >> > >> Hi Doron and Ofri, > >> > >> Thanks for your reply, here is some other question. > >> > >> ii. When adding a host into the trusted cluster, the host will be > >> attested via OAT service, only trusted hosted can be added. > >> > >> Would you also kindly tell me if there is any mandatory logic check > >> when adding a host into a cluster, so we can also put attestation > >> logic with these mandatory check together? Some example or code location is better. > >> Thanks a lot. > >> > > > > I think there are two approaches, depending on the use case. > > #1: > > If the host trusted property is static, then you can narrow the > > tests to two locations: > > * AddVdsCommand - (Vds = Host) - This command is triggered when a > > new host is added to the system. You can use the canDoAction method > > (which we have on all commands, and it determines whether an action > > can be run or not), and there, if cluster requires trusted hosts > > only, you can test whether this host is trusted or not. > > * ChangeVdsClusterCommand - this command is used when you change the > > cluster of a host. So, if the target cluster requires tursted hosts, > > you can do a similar test in its canDoAction method. > > > > #2: > > If the host trusted property can change, then I'd suggest using the > > NonOperational property of a host. > > We have a class called VdsUpdateRunTimeInfo that does periodic tests > > of hosts, deciding what's their status, according to specific flags. > > The code there is quite complex, and would require refactoring at > > some point, but in the meantime you can use the MonitoringStrategy > > interface that is being used there, and implement a new monitoring > > strategy for Open Attestation. > > > > There, in the processHardwareCapabilities, you can test that the > > host is trusted. > > > > When creating the strategy, using the MonitoringStrategyFactory, > > you'll need to create the appropriate strategy. > > Currently we support either virt strategy or gluster strategy or > > both. In your case you would need virt+attestation / > > gluster+attestation / > > virt+gluster+attestation, according to the services deployed on the > > cluster. > > I'd go with the 2nd approach. i.e., not block the host from being > added, only from being used, based on monitoring / non-op status > +1. It means that the admin can add the host, but the host will not be operational until we get a positive indication from the attestation service. > > > > > > > Does that make sense? > > Doron and Ofri, what did you have in mind for this feature? > > > > Regards, > > Oved > > > >> > >> Best Regards, > >> Dave Chen > >> > >> > >> -----Original Message----- > >> From: Doron Fediuck [mailto:dfediuck at redhat.com] > >> Sent: Wednesday, April 10, 2013 8:03 PM > >> To: Ofri Masad > >> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan > >> Subject: Re: minutes for sync up on Open Attestation integration > >> with oVirt in 4/9 > >> > >> > >> > >> ----- Original Message ----- > >>> From: "Ofri Masad" > >>> To: "Gang Wei" > >>> Cc: "Wei D Chen" , "Buddy Cao" > >>> , "Lijuan Zhang" , > >>> "Doron Fediuck" > >>> Sent: Wednesday, April 10, 2013 2:23:57 PM > >>> Subject: Re: minutes for sync up on Open Attestation integration > >>> with oVirt in 4/9 > >>> > >>> Hi, > >>> > >>> answers inside the mail body. > >>> > >>> ----- Original Message ----- > >>>> From: "Doron Fediuck" > >>>> To: "Wei D Chen" > >>>> Cc: "Gang Wei" , "Buddy Cao" > >>>> , "Lijuan Zhang" , > >>>> "Ofri Masad" > >>>> Sent: Wednesday, April 10, 2013 12:12:26 PM > >>>> Subject: Re: minutes for sync up on Open Attestation integration > >>>> with oVirt in 4/9 > >>>> > >>>> Hi Dave, > >>>> Adding Ofri to answer your questions. > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Wei D Chen" > >>>>> To: "Gang Wei" , "Doron Fediuck" > >>>>> , > >>>>> "Buddy Cao" , "Lijuan Zhang" > >>>>> > >>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM > >>>>> Subject: RE: minutes for sync up on Open Attestation integration > >>>>> with oVirt in 4/9 > >>>>> > >>>>> Hi Doron, > >>>>> > >>>>> > >>>>> iii. Then periodic trust check will be added into background process > >>>>> for > >>>>> all existing hosts, once becoming non-trusted, mark it as > >>>>> non-operational. > >>>>> > >>>>> - [Dave] Would you give me some details about the ?background > >>>>> process? mentioned in our sync up meeting? What?s the process > >>>>> and where is related code? > >>>>> > >>> > >>> The use Quartz Job to scheduled background processes. > >>> An example can be found in: > >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > >>> 222) > >>> > >>> This code calls a method that is located in: > >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/e > >>> ngin e/core/bll/quota/QuotaManager.java > >>> (Line: 1000) > >>> the @OnTimerMethodAnnotation annotation and the unique job name > >>> connects the two in runtime. > >>> > >>> The job can query the attestation server for all the host and then > >>> set untrusted hosts to Non-Operational. > >>> the best way would be to call SetNonOperationalVdsCommand with a > >>> new NonOperationalReason. > >>> This command tries to migrate all VMs from the host and then set > >>> it non operational. > >>> (We need to think about non-migrational VMs - should we close > >>> those VMs or keep the host running) > >>> > >> > >> One more thing you may want to consider; If we get a positive > >> response for a host which is currently non-operational, issue an > >> activate command to try and make it operational again. > >> Alternatively, you may decide not to handle it, assuming untrusted > >> hosts can only be activated manually (see below Ofri's response on > >> activating a host). > >> > >>>>> > >>>>> iv. If admin fixed the non-operational node and try to switch it to > >>>>> operational mode again, a trust check will happen to gate the > >>>>> switching. > >>>>> > >>>>> - [Dave] If there is a button provided from UI for checking > >>>>> the > >>>>> logic? or we need add an extra-button for attestation check only? > >>>>> > >>> > >>> In the UI we already have the "Activate" option. What still needs > >>> to be added is the check with the attestation provider to make > >>> sure that if the cluster is defined 'Trusted'. If so, only trusted > >>> host will succeed in the activate command (and, of course, a > >>> proper Audit Log error in case the host failed to activate due to trust issue. > >>> > >>> the correct place to add this check would be in: > >>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/org/o > >>> virt > >>> /engine/core/vdsbroker/VdsManager.java:activate() > >>> this is where the re-activation process begins. > >>> > >>>>> > >>>>> Thanks very much. > >>>>> > >>>>> > >>>>> > >>>>> Best Regards, > >>>>> Dave Chen > >> _______________________________________________ > >> 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 alonbl at redhat.com Tue Apr 16 06:34:18 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 16 Apr 2013 02:34:18 -0400 (EDT) Subject: [Engine-devel] upgrade failing with latest master In-Reply-To: References: <1273669048.47013.1365880663823.JavaMail.root@redhat.com> <1446063899.366491.1366042252302.JavaMail.root@redhat.com> <5152300.367225.1366042400592.JavaMail.root@redhat.com> <1383860034.427016.1366053819732.JavaMail.root@redhat.com> Message-ID: <487596290.516825.1366094058686.JavaMail.root@redhat.com> Hello, Without logs I don't think anyone will be able to help you. Alon ----- Original Message ----- > From: "Dead Horse" > To: "Alon Bar-Lev" > Cc: engine-devel at ovirt.org > Sent: Tuesday, April 16, 2013 12:36:54 AM > Subject: Re: [Engine-devel] upgrade failing with latest master > > Strangely I reverted back the ovirt test VM back to a state in time about 3 > weeks back. I then upgraded with rpms built from commit: > b4cc077888ba11871aa4837a73498a231050e2fc. > I then upgraded that with rpms built from master with the macros packaged > and all was well. I then forked a fresh FC17 VM updated it, and freshly > installed rpms from commit: b4cc077888ba11871aa4837a73498a231050e2fc. I > then again attempted upgrade with rpms built from master and again got the > above failures. > Very odd something must be different with the fresh install vs an upgraded > one. > > I will take the suggestion of moving to FC18. I will try out the fresh FC18 > build/install and backup/restore approach rather then the upgrade approach. > - DHC > > > On Mon, Apr 15, 2013 at 2:23 PM, Alon Bar-Lev wrote: > > > It was not single commit, please take most recent master (HEAD) > > Please attach logs and systemd journal messages. > > Thanks! > > > > ----- Original Message ----- > > > From: "Dead Horse" > > > To: "Alon Bar-Lev" > > > Cc: engine-devel at ovirt.org > > > Sent: Monday, April 15, 2013 8:25:48 PM > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > Guessing you are referring to the changes you made at commit: > > > eb8d8010a35a20a871c0af7674879da548d971f1 > > > and the few commits prior? > > > > > > If so I have built engine from master since then along with the macros > > file > > > added to /etc/rpm before initiating the build on my FC17 build VM. > > > All builds even with the macros included still result in the above most > > > recent reported upgrade failures with the engine service. > > > > > > - DHC > > > > > > > > > > > > On Mon, Apr 15, 2013 at 11:13 AM, Alon Bar-Lev > > wrote: > > > > > > > BTW: best is to use fedora-18... If not, please put the attached file > > at > > > > /etc/rpm before packaging. > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Alon Bar-Lev" > > > > > To: "Dead Horse" > > > > > Cc: engine-devel at ovirt.org > > > > > Sent: Monday, April 15, 2013 7:10:52 PM > > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > > > Oh... it is before I rewrote the engine service. > > > > > I thought that you facing issue after the re-write. > > > > > Can you please give a try to the master HEAD? > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Dead Horse" > > > > > > To: "Alon Bar-Lev" > > > > > > Cc: engine-devel at ovirt.org > > > > > > Sent: Monday, April 15, 2013 6:41:33 PM > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > > > > > Engine version I am attempting to upgrade was built from this > > commit: > > > > > > b4cc077888ba11871aa4837a73498a231050e2fc > > > > > > I built it same as always on a fully up to date FC17 VM. > > > > > > EG: Check out sources, cd /path/to/source/ make "rpm" > > > > > > > > > > > > I am unable to locate any .rpmnew in /etc after or before upgrade. > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > On Sat, Apr 13, 2013 at 2:17 PM, Alon Bar-Lev > > > > wrote: > > > > > > > > > > > > > > > > > > > > Which version do you use? > > > > > > > Have you built it your-self? > > > > > > > Have you settled all .rpmnew you have in /etc? > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Dead Horse" > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > Cc: engine-devel at ovirt.org > > > > > > > > Sent: Friday, April 12, 2013 9:20:51 PM > > > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest master > > > > > > > > > > > > > > > > Prior to engine-upgrade: > > > > > > > > ovirt-engine.service - oVirt Engine > > > > > > > > Loaded: loaded > > (/usr/lib/systemd/system/ovirt-engine.service; > > > > > > > enabled) > > > > > > > > Active: active (running) since Fri, 12 Apr 2013 13:11:16 > > > > -0500; > > > > > > > 1min > > > > > > > > 10s ago > > > > > > > > Main PID: 9023 (java) > > > > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > > > ? 9023 engine-service -server -XX:+TieredCompilation > > > > -Xms... > > > > > > > > > > > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > > > > Started > > > > > > > > engine ... > > > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > > > > Starting > > > > > > > > engine... > > > > > > > > > > > > > > > > Stopping ovirt-engine service prior to engine-upgrade: > > > > > > > > ovirt-engine.service - oVirt Engine > > > > > > > > Loaded: loaded > > (/usr/lib/systemd/system/ovirt-engine.service; > > > > > > > enabled) > > > > > > > > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 > > > > > > > > 13:12:51 > > > > > > > > -0500; 3s ago > > > > > > > > Process: 9141 ExecStop=/usr/bin/engine-service stop > > > > (code=exited, > > > > > > > > status=0/SUCCESS) > > > > > > > > Main PID: 9023 (code=exited, status=143) > > > > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > > > > > > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > > > > Started > > > > > > > > engine ... > > > > > > > > Apr 12 13:11:16 ovirtfoo.ctt.med.ge.com engine-service[9022]: > > > > Starting > > > > > > > > engine... > > > > > > > > Apr 12 13:12:50 ovirtfoo.ctt.med.ge.com engine-service[9141]: > > > > Waiting > > > > > > > up to > > > > > > > > 1... > > > > > > > > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: > > > > Stopped > > > > > > > > engine ... > > > > > > > > Apr 12 13:12:51 ovirtfoo.ctt.med.ge.com engine-service[9141]: > > > > Stopping > > > > > > > > engine... > > > > > > > > > > > > > > > > After running engine-upgrade: > > > > > > > > ovirt-engine.service - oVirt Engine > > > > > > > > Loaded: loaded > > (/usr/lib/systemd/system/ovirt-engine.service; > > > > > > > enabled) > > > > > > > > Active: failed (Result: exit-code) since Fri, 12 Apr 2013 > > > > > > > > 13:18:22 > > > > > > > > -0500; 41s ago > > > > > > > > Main PID: 9168 (code=exited, status=143) > > > > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > > > > > > > > > > > Apr 12 13:18:22 ovirtfoo.ctt.med.ge.com systemd[11198]: > > Failed at > > > > step > > > > > > > EXEC > > > > > > > > spawning /usr/bin/engine-service: No such file or directory > > > > > > > > > > > > > > > > After attemptining systemctl start ovirt-engine.service after > > > > > > > > engine-upgrade: > > > > > > > > ovirt-engine.service - oVirt Engine > > > > > > > > Loaded: loaded > > (/usr/lib/systemd/system/ovirt-engine.service; > > > > > > > enabled) > > > > > > > > Active: active (running) since Fri, 12 Apr 2013 13:19:43 > > > > -0500; > > > > > > > > 1s > > > > > > > ago > > > > > > > > Process: 11228 ExecStart=/usr/bin/engine-service start > > > > > > > > (code=exited, > > > > > > > > status=0/SUCCESS) > > > > > > > > Main PID: 11229 (java) > > > > > > > > CGroup: name=systemd:/system/ovirt-engine.service > > > > > > > > ? 11229 engine-service -server -XX:+TieredCompilation > > > > -Xms1g > > > > > > > > -Xmx1g -XX:PermSize=256m -XX:MaxPermSize=256m > > > > > > > > -Djava.net.preferIPv4Stack=tr... > > > > > > > > > > > > > > > > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: > > > > Started > > > > > > > > engine process 11229. > > > > > > > > Apr 12 13:19:43 ovirtfoo.ctt.med.ge.com engine-service[11228]: > > > > Starting > > > > > > > > engine-service: [ OK ] > > > > > > > > > > > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Apr 11, 2013 at 4:33 PM, Alon Bar-Lev < > > alonbl at redhat.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Please see what systemd has to say: > > > > > > > > > > > > > > > > > > # systemctl status ovirt-engine.service > > > > > > > > > > > > > > > > > > > > > > > > > > > And no, I never tried to backup/restore... sorry... > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Dead Horse" > > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > > Cc: engine-devel at ovirt.org > > > > > > > > > > Sent: Friday, April 12, 2013 12:28:01 AM > > > > > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest > > master > > > > > > > > > > > > > > > > > > > > Rebuilt the engine on my FC17 build VM with the macro file > > > > above in > > > > > > > > > > "/etc/rpm/" > > > > > > > > > > Upon attempting upgrade on my FC17 upgrade test VM: > > > > > > > > > > I still get a failure to start the engine > > > > > > > > > > > > > > > > > > > > 013-04-11 16:06:37::ERROR::engine-upgrade::1328::root:: > > > > Traceback > > > > > > > (most > > > > > > > > > > recent call last): > > > > > > > > > > File "/bin/engine-upgrade", line 1321, in > > > > > > > > > > main(options) > > > > > > > > > > File "/bin/engine-upgrade", line 1293, in main > > > > > > > > > > runFunc([startEngine], MSG_INFO_START_ENGINE % > > > > engineService) > > > > > > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > > > > > > func() > > > > > > > > > > File "/bin/engine-upgrade", line 584, in startEngine > > > > > > > > > > output, rc = utils.execCmd(cmdList=cmd, > > failOnError=True, > > > > > > > > > > msg=MSG_ERR_FAILED_START_ENGINE_SERVICE) > > > > > > > > > > File "/usr/share/ovirt-engine/scripts/common_utils.py", > > line > > > > 499, > > > > > > > in > > > > > > > > > > execCmd > > > > > > > > > > raise Exception(msg) > > > > > > > > > > Exception: Error: Can't start ovirt-engine > > > > > > > > > > > > > > > > > > > > Curiously is there a documented process somewhere for > > backing > > > > up > > > > > > > > > > data > > > > > > > > > from > > > > > > > > > > an FC17 ovirt install and doing a fresh install on a FC18 > > box > > > > then > > > > > > > > > > restoring the FC17 database + ovirt config data? > > > > > > > > > > > > > > > > > > > > Guessing it goes something like this: (someone please > > confirm) > > > > > > > > > > > > > > > > > > > > Back up the following directories and files: > > > > > > > > > > /etc/ovirt-engine > > > > > > > > > > /etc/pki/ovirt-engine > > > > > > > > > > /etc/pki/ovirt-engine-backups > > > > > > > > > > /var/lib/ovirt-engine/backups > > > > > > > > > > /var/lib/ovirt-engine/deployments > > > > > > > > > > /root/.rnd > > > > > > > > > > > > > > > > > > > > Dump a backup of the engine database > > > > > > > > > > > > > > > > > > > > Install ovirt-engine on FC18 system > > > > > > > > > > run engine-setup (answer questions same as prior install > > from > > > > FC17) > > > > > > > > > > upon completion of engine-setup stop the engine service > > > > > > > > > > restore all the above files and directories > > > > > > > > > > > > > > > > > > > > Drop the engine databse > > > > > > > > > > Restore the backed up engine database > > > > > > > > > > > > > > > > > > > > FC17 --> FC18 upgrade = icky esp. with ovirt involved as > > part > > > > of > > > > > > > > > > the > > > > > > > > > upgrade > > > > > > > > > > > > > > > > > > > > Thus it seems the easiest way to solve this is to bite the > > > > bullet > > > > > > > > > > and > > > > > > > > > move > > > > > > > > > > to FC18 providing the backup/restore works. > > > > > > > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 4:02 PM, Alon Bar-Lev < > > > > alonbl at redhat.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > OK... the systemd macros are missing in fedora 17... > > > > > > > > > > > > > > > > > > > > > > Put the following file and rebuild. > > > > > > > > > > > I may need to add some workaround if many people still > > use > > > > > > > fedora-17 > > > > > > > > > for > > > > > > > > > > > master. > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > Alon > > > > > > > > > > > > > > > > > > > > > > /etc/rpm/macros.systemd-fc18 > > > > > > > > > > > --- > > > > > > > > > > > %systemd_post() \ > > > > > > > > > > > if [ $1 -eq 1 ] ; then \ > > > > > > > > > > > # Initial installation \ > > > > > > > > > > > /usr/bin/systemctl preset %{?*} >/dev/null 2>&1 > > || : > > > > \ > > > > > > > > > > > fi \ > > > > > > > > > > > %{nil} > > > > > > > > > > > > > > > > > > > > > > %systemd_preun() \ > > > > > > > > > > > if [ $1 -eq 0 ] ; then \ > > > > > > > > > > > # Package removal, not upgrade \ > > > > > > > > > > > /usr/bin/systemctl --no-reload disable %{?*} > > > > > /dev/null > > > > > > > 2>&1 > > > > > > > > > || : > > > > > > > > > > > \ > > > > > > > > > > > /usr/bin/systemctl stop %{?*} > /dev/null 2>&1 > > || : \ > > > > > > > > > > > fi \ > > > > > > > > > > > %{nil} > > > > > > > > > > > > > > > > > > > > > > %systemd_postun() \ > > > > > > > > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > > > > > > > > %{nil} > > > > > > > > > > > > > > > > > > > > > > %systemd_postun_with_restart() \ > > > > > > > > > > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : \ > > > > > > > > > > > if [ $1 -ge 1 ] ; then \ > > > > > > > > > > > # Package upgrade, not uninstall \ > > > > > > > > > > > /usr/bin/systemctl try-restart %{?*} >/dev/null > > 2>&1 > > > > || : > > > > > > > > > > > \ > > > > > > > > > > > fi \ > > > > > > > > > > > %{nil} > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Dead Horse" > > > > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > > > > Cc: engine-devel at ovirt.org > > > > > > > > > > > > Sent: Wednesday, April 10, 2013 11:59:15 PM > > > > > > > > > > > > Subject: Re: [Engine-devel] upgrade failing with latest > > > > master > > > > > > > > > > > > > > > > > > > > > > > > Correct, FC17 > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 3:32 PM, Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Is this fedora 17 or 18? > > > > > > > > > > > > > > > > > > > > > > > > > > I guess it is fedora 17. > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Dead Horse" > > > > > > > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > > > > > > > Sent: Wednesday, April 10, 2013 11:23:10 PM > > > > > > > > > > > > > > Subject: [Engine-devel] upgrade failing with latest > > > > master > > > > > > > > > > > > > > > > > > > > > > > > > > > > logs attached > > > > > > > > > > > > > > > > > > > > > > > > > > > > First attempt: > > > > > > > > > > > > > > 2013-04-10 > > 13:57:32::ERROR::common_utils::355::root:: > > > > YUM: > > > > > > > FAIL: > > > > > > > > > > > Error in > > > > > > > > > > > > > > PREUN scriptlet in rpm package > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > > 2013-04-10 > > 13:57:32::DEBUG::common_utils::347::root:: > > > > YUM: > > > > > > > VERB: > > > > > > > > > > > Script > > > > > > > > > > > > > sink: > > > > > > > > > > > > > > /var/tmp/rpm-tmp.J0HyUz: line 1: fg: no job control > > > > > > > > > > > > > > error: > > > > %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > > > > > > scriptlet > > > > > > > > > > > > > failed, > > > > > > > > > > > > > > exit status 1 > > > > > > > > > > > > > > 2013-04-10 > > 13:57:32::DEBUG::common_utils::347::root:: > > > > YUM: > > > > > > > VERB: > > > > > > > > > > > Done: > > > > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > > > > > > > > > > > > > > > > Second attempt: > > > > > > > > > > > > > > 2013-04-10 > > 15:12:11::DEBUG::common_utils::347::root:: > > > > YUM: > > > > > > > VERB: > > > > > > > > > > > Building > > > > > > > > > > > > > > transaction > > > > > > > > > > > > > > 2013-04-10 > > 15:12:12::ERROR::common_utils::355::root:: > > > > YUM: > > > > > > > FAIL: > > > > > > > > > > > > > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch > > requires > > > > > > > > > ovirt-engine = > > > > > > > > > > > > > > 3.3.0-14.fc17'] > > > > > > > > > > > > > > 2013-04-10 > > 15:12:12::DEBUG::common_utils::347::root:: > > > > YUM: > > > > > > > VERB: > > > > > > > > > > > > > Performing > > > > > > > > > > > > > > rollback > > > > > > > > > > > > > > 2013-04-10 > > 15:12:12::DEBUG::common_utils::1410::root:: > > > > > > > Locking > > > > > > > > > rpms > > > > > > > > > > > in > > > > > > > > > > > > > > yum-version-lock > > > > > > > > > > > > > > 2013-04-10 > > > > 15:12:12::ERROR::engine-upgrade::1299::root:: > > > > > > > > > Traceback > > > > > > > > > > > (most > > > > > > > > > > > > > > recent call last): > > > > > > > > > > > > > > File "/bin/engine-upgrade", line 1292, in > > > > > > > > > > > > > > main(options) > > > > > > > > > > > > > > File "/bin/engine-upgrade", line 1142, in main > > > > > > > > > > > > > > runFunc([rhyum.begin], MSG_INFO_CHECK_UPDATE) > > > > > > > > > > > > > > File "/bin/engine-upgrade", line 617, in runFunc > > > > > > > > > > > > > > func() > > > > > > > > > > > > > > File "/bin/engine-upgrade", line 310, in begin > > > > > > > > > > > > > > self.emptyTransaction = not > > > > > > > > > > > > > > self._miniyum.buildTransaction() > > > > > > > > > > > > > > File "/usr/share/ovirt-engine/scripts/miniyum.py", > > line > > > > > > > > > > > > > > 761, > > > > > > > in > > > > > > > > > > > > > > buildTransaction > > > > > > > > > > > > > > raise yum.Errors.YumBaseError(msg) > > > > > > > > > > > > > > YumBaseError: > > > > [u'ovirt-engine-backend-3.3.0-14.fc17.noarch > > > > > > > > > requires > > > > > > > > > > > > > > ovirt-engine = 3.3.0-14.fc17'] > > > > > > > > > > > > > > > > > > > > > > > > > > > > Realizing things were now hosed: > > > > > > > > > > > > > > [root at ovirtfoo /]# yum erase ovirt-* otopi-* > > > > > > > > > > > > > > Loaded plugins: langpacks, presto, > > refresh-packagekit, > > > > > > > > > versionlock > > > > > > > > > > > > > > Resolving Dependencies > > > > > > > > > > > > > > --> Running transaction check > > > > > > > > > > > > > > ---> Package otopi.noarch 0:3.3.0-15.fc17 will be > > > > erased > > > > > > > > > > > > > > ---> Package otopi-java.noarch 0:3.3.0-15.fc17 > > will be > > > > > > > > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-engine.noarch 0:3.3.0-14.fc17 > > will > > > > be > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-engine-backend.noarch > > > > 0:3.3.0-14.fc17 > > > > > > > will be > > > > > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-engine-backend.noarch > > > > 0:3.3.0-15.fc17 > > > > > > > will be > > > > > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-engine-cli.noarch > > 0:3.3.0.1-15.fc17 > > > > will > > > > > > > be > > > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-engine-dbscripts.noarch > > > > 0:3.3.0-14.fc17 > > > > > > > will > > > > > > > > > be > > > > > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-engine-restapi.noarch > > > > 0:3.3.0-14.fc17 > > > > > > > will be > > > > > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-engine-sdk.noarch > > 0:3.3.0.1-15.fc17 > > > > will > > > > > > > be > > > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-engine-setup.noarch > > 0:3.3.0-15.fc17 > > > > will > > > > > > > be > > > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-engine-tools.noarch > > 0:3.3.0-14.fc17 > > > > will > > > > > > > be > > > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-engine-userportal.noarch > > > > 0:3.3.0-14.fc17 > > > > > > > will > > > > > > > > > be > > > > > > > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-engine-webadmin-portal.noarch > > > > > > > 0:3.3.0-14.fc17 > > > > > > > > > > > will be > > > > > > > > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-host-deploy.noarch > > 0:3.3.0-15.fc17 > > > > will > > > > > > > > > > > > > > be > > > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-host-deploy-java.noarch > > > > 0:3.3.0-15.fc17 > > > > > > > will > > > > > > > > > be > > > > > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-image-uploader.noarch > > > > 0:3.3.0-15.fc17 > > > > > > > will be > > > > > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-iso-uploader.noarch > > 0:3.3.0-15.fc17 > > > > will > > > > > > > be > > > > > > > > > erased > > > > > > > > > > > > > > ---> Package ovirt-log-collector.noarch > > 0:3.3.0-15.fc17 > > > > > > > > > > > > > > will > > > > > > > be > > > > > > > > > > > erased > > > > > > > > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > > > Removing: > > > > > > > > > > > > > > otopi noarch 3.3.0-15.fc17 @ovirt-engine 463 k > > > > > > > > > > > > > > otopi-java noarch 3.3.0-15.fc17 @ovirt-engine 27 k > > > > > > > > > > > > > > ovirt-engine noarch 3.3.0-14.fc17 @ovirt-engine > > 1.3 M > > > > > > > > > > > > > > ovirt-engine-backend noarch 3.3.0-14.fc17 > > > > @ovirt-engine 20 > > > > > > > > > > > > > > M > > > > > > > > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 > > > > @ovirt-engine 20 > > > > > > > > > > > > > > M > > > > > > > > > > > > > > ovirt-engine-cli noarch 3.3.0.1-15.fc17 > > @ovirt-engine > > > > 557 k > > > > > > > > > > > > > > ovirt-engine-dbscripts noarch 3.3.0-14.fc17 > > > > @ovirt-engine > > > > > > > 816 k > > > > > > > > > > > > > > ovirt-engine-restapi noarch 3.3.0-14.fc17 > > > > @ovirt-engine 1.0 > > > > > > > > > > > > > > M > > > > > > > > > > > > > > ovirt-engine-sdk noarch 3.3.0.1-15.fc17 > > @ovirt-engine > > > > 3.1 M > > > > > > > > > > > > > > ovirt-engine-setup noarch 3.3.0-15.fc17 > > @ovirt-engine > > > > 653 k > > > > > > > > > > > > > > ovirt-engine-tools noarch 3.3.0-14.fc17 > > @ovirt-engine > > > > 178 k > > > > > > > > > > > > > > ovirt-engine-userportal noarch 3.3.0-14.fc17 > > > > @ovirt-engine > > > > > > > 23 M > > > > > > > > > > > > > > ovirt-engine-webadmin-portal noarch 3.3.0-14.fc17 > > > > > > > @ovirt-engine > > > > > > > > > 32 M > > > > > > > > > > > > > > ovirt-host-deploy noarch 3.3.0-15.fc17 > > @ovirt-engine > > > > 211 k > > > > > > > > > > > > > > ovirt-host-deploy-java noarch 3.3.0-15.fc17 > > > > @ovirt-engine > > > > > > > > > > > > > > 11 > > > > > > > k > > > > > > > > > > > > > > ovirt-image-uploader noarch 3.3.0-15.fc17 > > > > @ovirt-engine 923 > > > > > > > > > > > > > > k > > > > > > > > > > > > > > ovirt-iso-uploader noarch 3.3.0-15.fc17 > > @ovirt-engine > > > > 98 k > > > > > > > > > > > > > > ovirt-log-collector noarch 3.3.0-15.fc17 > > @ovirt-engine > > > > 133 > > > > > > > > > > > > > > k > > > > > > > > > > > > > > > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > > > Remove 18 Packages > > > > > > > > > > > > > > > > > > > > > > > > > > > > Installed size: 104 M > > > > > > > > > > > > > > Is this ok [y/N]: y > > > > > > > > > > > > > > Downloading Packages: > > > > > > > > > > > > > > Running Transaction Check > > > > > > > > > > > > > > Running Transaction Test > > > > > > > > > > > > > > Transaction Test Succeeded > > > > > > > > > > > > > > Running Transaction > > > > > > > > > > > > > > Erasing : ovirt-engine-backend.noarch 1/18 > > > > > > > > > > > > > > Erasing : > > ovirt-engine-dbscripts-3.3.0-14.fc17.noarch > > > > 2/18 > > > > > > > > > > > > > > Erasing : ovirt-engine-restapi-3.3.0-14.fc17.noarch > > > > 3/18 > > > > > > > > > > > > > > Erasing : ovirt-engine-setup-3.3.0-15.fc17.noarch > > 4/18 > > > > > > > > > > > > > > Erasing : ovirt-engine-tools-3.3.0-14.fc17.noarch > > 5/18 > > > > > > > > > > > > > > Erasing : > > ovirt-engine-userportal-3.3.0-14.fc17.noarch > > > > 6/18 > > > > > > > > > > > > > > Erasing : ovirt-engine-3.3.0-14.fc17.noarch 7/18 > > > > > > > > > > > > > > warning: /etc/ovirt-engine/engine.conf saved as > > > > > > > > > > > > > > /etc/ovirt-engine/engine.conf.rpmsave > > > > > > > > > > > > > > Erasing : > > > > ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > > > > > > > 8/18 > > > > > > > > > > > > > > Erasing : > > ovirt-host-deploy-java-3.3.0-15.fc17.noarch > > > > 9/18 > > > > > > > > > > > > > > Erasing : otopi-java-3.3.0-15.fc17.noarch 10/18 > > > > > > > > > > > > > > Erasing : ovirt-host-deploy-3.3.0-15.fc17.noarch > > 11/18 > > > > > > > > > > > > > > Erasing : ovirt-image-uploader-3.3.0-15.fc17.noarch > > > > 12/18 > > > > > > > > > > > > > > warning: /etc/ovirt-engine/imageuploader.conf > > saved as > > > > > > > > > > > > > > /etc/ovirt-engine/imageuploader.conf.rpmsave > > > > > > > > > > > > > > Erasing : ovirt-iso-uploader-3.3.0-15.fc17.noarch > > 13/18 > > > > > > > > > > > > > > warning: /etc/ovirt-engine/isouploader.conf saved > > as > > > > > > > > > > > > > > /etc/ovirt-engine/isouploader.conf.rpmsave > > > > > > > > > > > > > > Erasing : ovirt-log-collector-3.3.0-15.fc17.noarch > > > > 14/18 > > > > > > > > > > > > > > warning: /etc/ovirt-engine/logcollector.conf saved > > as > > > > > > > > > > > > > > /etc/ovirt-engine/logcollector.conf.rpmsave > > > > > > > > > > > > > > Erasing : ovirt-engine-cli-3.3.0.1-15.fc17.noarch > > 15/18 > > > > > > > > > > > > > > Erasing : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch > > 16/18 > > > > > > > > > > > > > > Erasing : otopi-3.3.0-15.fc17.noarch 17/18 > > > > > > > > > > > > > > Error in PREUN scriptlet in rpm package > > > > > > > > > > > > > > ovirt-engine-backend > > > > > > > > > > > > > > /var/tmp/rpm-tmp.uFqX1f: line 1: fg: no job control > > > > > > > > > > > > > > error: > > > > %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > > > > > > scriptlet > > > > > > > > > > > > > failed, > > > > > > > > > > > > > > exit status 1 > > > > > > > > > > > > > > Verifying : otopi-3.3.0-15.fc17.noarch 1/18 > > > > > > > > > > > > > > Verifying : otopi-java-3.3.0-15.fc17.noarch 2/18 > > > > > > > > > > > > > > Verifying : > > ovirt-log-collector-3.3.0-15.fc17.noarch > > > > 3/18 > > > > > > > > > > > > > > Verifying : > > > > > > > > > > > > > > ovirt-engine-webadmin-portal-3.3.0-14.fc17.noarch > > > > > > > > > 4/18 > > > > > > > > > > > > > > Verifying : ovirt-host-deploy-3.3.0-15.fc17.noarch > > 5/18 > > > > > > > > > > > > > > Verifying : ovirt-engine-tools-3.3.0-14.fc17.noarch > > > > 6/18 > > > > > > > > > > > > > > Verifying : ovirt-engine-setup-3.3.0-15.fc17.noarch > > > > 7/18 > > > > > > > > > > > > > > Verifying : ovirt-engine-sdk-3.3.0.1-15.fc17.noarch > > > > 8/18 > > > > > > > > > > > > > > Verifying : > > ovirt-engine-restapi-3.3.0-14.fc17.noarch > > > > 9/18 > > > > > > > > > > > > > > Verifying : > > > > ovirt-engine-userportal-3.3.0-14.fc17.noarch > > > > > > > 10/18 > > > > > > > > > > > > > > Verifying : > > ovirt-host-deploy-java-3.3.0-15.fc17.noarch > > > > > > > > > > > > > > 11/18 > > > > > > > > > > > > > > Verifying : > > ovirt-image-uploader-3.3.0-15.fc17.noarch > > > > 12/18 > > > > > > > > > > > > > > Verifying : ovirt-iso-uploader-3.3.0-15.fc17.noarch > > > > 13/18 > > > > > > > > > > > > > > Verifying : ovirt-engine-cli-3.3.0.1-15.fc17.noarch > > > > 14/18 > > > > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch was > > supposed > > > > to > > > > > > > > > > > > > > be > > > > > > > > > removed > > > > > > > > > > > but > > > > > > > > > > > > > is > > > > > > > > > > > > > > not! > > > > > > > > > > > > > > Verifying : > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > 15/18 > > > > > > > > > > > > > > Verifying : > > ovirt-engine-backend-3.3.0-14.fc17.noarch > > > > 16/18 > > > > > > > > > > > > > > Verifying : ovirt-engine-3.3.0-14.fc17.noarch 17/18 > > > > > > > > > > > > > > Verifying : > > ovirt-engine-dbscripts-3.3.0-14.fc17.noarch > > > > > > > > > > > > > > 18/18 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Removed: > > > > > > > > > > > > > > otopi.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > otopi-java.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > ovirt-engine.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > > > ovirt-engine-cli.noarch 0:3.3.0.1-15.fc17 > > > > > > > > > > > > > > ovirt-engine-dbscripts.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > > > ovirt-engine-restapi.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > > > ovirt-engine-sdk.noarch 0:3.3.0.1-15.fc17 > > > > > > > > > > > > > > ovirt-engine-setup.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > ovirt-engine-tools.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > > > ovirt-engine-userportal.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > > > ovirt-engine-webadmin-portal.noarch 0:3.3.0-14.fc17 > > > > > > > > > > > > > > ovirt-host-deploy.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > ovirt-host-deploy-java.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > ovirt-image-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > ovirt-iso-uploader.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > ovirt-log-collector.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Failed: > > > > > > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Complete! > > > > > > > > > > > > > > [root at ovirtfoo /]# rpm -qa | grep oto > > > > > > > > > > > > > > protobuf-java-2.4.1-12.fc17.x86_64 > > > > > > > > > > > > > > libgphoto2-2.4.14-1.fc17.x86_64 > > > > > > > > > > > > > > [root at ovirtfoo /]# rpm -qa | grep ovirt > > > > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > > [root at ovirtfoo /]# yum erase > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > > Loaded plugins: langpacks, presto, > > refresh-packagekit, > > > > > > > > > versionlock > > > > > > > > > > > > > > Resolving Dependencies > > > > > > > > > > > > > > --> Running transaction check > > > > > > > > > > > > > > ---> Package ovirt-engine-backend.noarch > > > > 0:3.3.0-15.fc17 > > > > > > > will be > > > > > > > > > > > erased > > > > > > > > > > > > > > --> Finished Dependency Resolution > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dependencies Resolved > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > > > Package Arch Version Repository Size > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > > > Removing: > > > > > > > > > > > > > > ovirt-engine-backend noarch 3.3.0-15.fc17 > > > > @ovirt-engine 20 > > > > > > > > > > > > > > M > > > > > > > > > > > > > > > > > > > > > > > > > > > > Transaction Summary > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================================ > > > > > > > > > > > > > > Remove 1 Package > > > > > > > > > > > > > > > > > > > > > > > > > > > > Installed size: 20 M > > > > > > > > > > > > > > Is this ok [y/N]: y > > > > > > > > > > > > > > Downloading Packages: > > > > > > > > > > > > > > Running Transaction Check > > > > > > > > > > > > > > Running Transaction Test > > > > > > > > > > > > > > Transaction Test Succeeded > > > > > > > > > > > > > > Running Transaction > > > > > > > > > > > > > > Error in PREUN scriptlet in rpm package > > > > > > > > > > > > > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > > > > > > > > > > > /var/tmp/rpm-tmp.jq1b7e: line 1: fg: no job control > > > > > > > > > > > > > > error: > > > > %preun(ovirt-engine-backend-3.3.0-15.fc17.noarch) > > > > > > > > > scriptlet > > > > > > > > > > > > > failed, > > > > > > > > > > > > > > exit status 1 > > > > > > > > > > > > > > Verifying : > > ovirt-engine-backend-3.3.0-15.fc17.noarch > > > > 1/1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Failed: > > > > > > > > > > > > > > ovirt-engine-backend.noarch 0:3.3.0-15.fc17 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Complete! > > > > > > > > > > > > > > > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From avishwan at redhat.com Tue Apr 16 08:43:25 2013 From: avishwan at redhat.com (Aravinda) Date: Tue, 16 Apr 2013 14:13:25 +0530 Subject: [Engine-devel] [vdsm] Adding vdsm_api support for gluster vdsm verbs In-Reply-To: <516D0E85.1070407@redhat.com> References: <516BDA06.5080101@redhat.com> <516D0E85.1070407@redhat.com> Message-ID: <516D0F2D.8000100@redhat.com> [Adding engine-devel] On 04/16/2013 02:10 PM, Aravinda wrote: > > vdsm/gluster is vdsm plugin for gluster related functionality. These > functionalities are available only when vdsm-gluster package is > installed. So the schema JSON of vdsm-gluster cannot be added to the > same file(vdsm_api/vdsmapi-schema.json) > > Looks like vdsm_api is not providing plugin support. This patch adds > functionality to vdsm_api to read vdsmapi-gluster-schema.json if > available. But with this approach we need to edit the core vdsmapi.py > file. > > http://gerrit.ovirt.org/#/c/13921/ > > Alternate approach: > We can have "vdsm_api/plugins" or "vdsm_api/schema" directory inside > vdsm_api, so that we can modify vdsmapi.py to read all schema files > from that dir. When vdsm-gluster package installed, it copies > vdsmapi-gluster-schema.json into schema directory. > > > -- > regards > Aravinda > > > On 04/15/2013 04:14 PM, Aravinda wrote: >> Hi, >> >> We are trying to add json rpc support for vdsm gluster verbs. I >> submitted a patch to read gluster verbs schema from vdsm/gluster >> directory. >> http://gerrit.ovirt.org/#/c/13921/ >> >> Let me know if the approach is fine. >> >> -- >> regards >> Aravinda >> _______________________________________________ >> vdsm-devel mailing list >> vdsm-devel at lists.fedorahosted.org >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel From omasad at redhat.com Wed Apr 17 07:23:26 2013 From: omasad at redhat.com (Ofri Masad) Date: Wed, 17 Apr 2013 03:23:26 -0400 (EDT) Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: References: <996306366.2192571.1365595398217.JavaMail.root@redhat.com> <189243164.4209095.1366006840007.JavaMail.root@redhat.com> <516BA2E8.7090207@redhat.com> <448237996.384685.1366009557875.JavaMail.root@redhat.com> <1045509486.480916.1366023642593.JavaMail.root@redhat.com> Message-ID: <1308686351.886592.1366183406691.JavaMail.root@redhat.com> Hi Dave, The VdsUpdateRunTimeInfo runs every 3 seconds or so. so it not a good place to call the attestation host. Instead, like we suggested earlier, create a new Quartz job (like the one I've sent you in the QuotaManager class) which run every couple of minutes and update the hosts state. You can also add the check to InitVdsOnUpCommand, so that if a host was down for a different reason, it will be rechecked for attestation. You can add a UI to allow manual "refresh attestation". Ofri ----- Original Message ----- > From: "Wei D Chen" > To: "Omer Frenkel" , "Doron Fediuck" > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > Sent: Monday, April 15, 2013 5:53:34 PM > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 > > Good approach, thanks all. How long it needs to invoke periodic check in the > class of VdsUpdateRunTimeInfo? Whether this time configurable? My concern is > if the initial status of each host added into trusted cluster is > non-operational, we need wait a long time for the invoking of this periodic > check, so a trusted host's with initial status of non-operational will take > a long time to flip to a trusted host. > > As I have not seen the configuration of periodic check in > VdsUpdateRunTimeInfo, would you give me some tips if you has some clue. > Thanks a lot. > > Best Regards, > Dave Chen > > -----Original Message----- > From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] > On Behalf Of Omer Frenkel > Sent: Monday, April 15, 2013 7:01 PM > To: Doron Fediuck > Cc: Oved Ourfalli; engine-devel at ovirt.org > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > integration with oVirt in 4/9 > > > > ----- Original Message ----- > > From: "Doron Fediuck" > > To: "Itamar Heim" > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > Sent: Monday, April 15, 2013 10:05:57 AM > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > integration with oVirt in 4/9 > > > > > > > > ----- Original Message ----- > > > From: "Itamar Heim" > > > To: "Oved Ourfalli" > > > Cc: engine-devel at ovirt.org > > > Sent: Monday, April 15, 2013 9:49:12 AM > > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > > integration with oVirt in 4/9 > > > > > > On 04/15/2013 09:20 AM, Oved Ourfalli wrote: > > > > > > > > > > > > ----- Original Message ----- > > > >> From: "Wei D Chen" > > > >> To: "Doron Fediuck" , "Ofri Masad" > > > >> > > > >> Cc: engine-devel at ovirt.org > > > >> Sent: Monday, April 15, 2013 8:54:18 AM > > > >> Subject: Re: [Engine-devel] minutes for sync up on Open > > > >> Attestation integration with oVirt in 4/9 > > > >> > > > >> Hi Doron and Ofri, > > > >> > > > >> Thanks for your reply, here is some other question. > > > >> > > > >> ii. When adding a host into the trusted cluster, the host will > > > >> be attested via OAT service, only trusted hosted can be added. > > > >> > > > >> Would you also kindly tell me if there is any mandatory logic > > > >> check when adding a host into a cluster, so we can also put > > > >> attestation logic with these mandatory check together? Some example or > > > >> code location is better. > > > >> Thanks a lot. > > > >> > > > > > > > > I think there are two approaches, depending on the use case. > > > > #1: > > > > If the host trusted property is static, then you can narrow the > > > > tests to two locations: > > > > * AddVdsCommand - (Vds = Host) - This command is triggered when a > > > > new host is added to the system. You can use the canDoAction > > > > method (which we have on all commands, and it determines whether > > > > an action can be run or not), and there, if cluster requires > > > > trusted hosts only, you can test whether this host is trusted or > > > > not. > > > > * ChangeVdsClusterCommand - this command is used when you change > > > > the cluster of a host. So, if the target cluster requires tursted > > > > hosts, you can do a similar test in its canDoAction method. > > > > > > > > #2: > > > > If the host trusted property can change, then I'd suggest using > > > > the NonOperational property of a host. > > > > We have a class called VdsUpdateRunTimeInfo that does periodic > > > > tests of hosts, deciding what's their status, according to specific > > > > flags. > > > > The code there is quite complex, and would require refactoring at > > > > some point, but in the meantime you can use the MonitoringStrategy > > > > interface that is being used there, and implement a new monitoring > > > > strategy for Open Attestation. > > > > > > > > There, in the processHardwareCapabilities, you can test that the > > > > host is trusted. > > > > > > > > When creating the strategy, using the MonitoringStrategyFactory, > > > > you'll need to create the appropriate strategy. > > > > Currently we support either virt strategy or gluster strategy or > > > > both. In your case you would need virt+attestation / > > > > gluster+attestation / > > > > virt+gluster+attestation, according to the services deployed on > > > > virt+gluster+the > > > > cluster. > > > > > > I'd go with the 2nd approach. i.e., not block the host from being > > > added, only from being used, based on monitoring / non-op status > > > > > +1. > > It means that the admin can add the host, but the host will not be > > operational until we get a positive indication from the attestation > > service. > > > +1 > if we want to test attestation only once, every time before host moves to up. > the right place for it, imo, is InitVdsOnUpCommand if its periodic also after > host is up, then it should be somewhere in the monitoring code > > > > > > > > > > > > > > > > Does that make sense? > > > > Doron and Ofri, what did you have in mind for this feature? > > > > > > > > Regards, > > > > Oved > > > > > > > >> > > > >> Best Regards, > > > >> Dave Chen > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: Doron Fediuck [mailto:dfediuck at redhat.com] > > > >> Sent: Wednesday, April 10, 2013 8:03 PM > > > >> To: Ofri Masad > > > >> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan > > > >> Subject: Re: minutes for sync up on Open Attestation integration > > > >> with oVirt in 4/9 > > > >> > > > >> > > > >> > > > >> ----- Original Message ----- > > > >>> From: "Ofri Masad" > > > >>> To: "Gang Wei" > > > >>> Cc: "Wei D Chen" , "Buddy Cao" > > > >>> , "Lijuan Zhang" , > > > >>> "Doron Fediuck" > > > >>> Sent: Wednesday, April 10, 2013 2:23:57 PM > > > >>> Subject: Re: minutes for sync up on Open Attestation integration > > > >>> with oVirt in 4/9 > > > >>> > > > >>> Hi, > > > >>> > > > >>> answers inside the mail body. > > > >>> > > > >>> ----- Original Message ----- > > > >>>> From: "Doron Fediuck" > > > >>>> To: "Wei D Chen" > > > >>>> Cc: "Gang Wei" , "Buddy Cao" > > > >>>> , "Lijuan Zhang" , > > > >>>> "Ofri Masad" > > > >>>> Sent: Wednesday, April 10, 2013 12:12:26 PM > > > >>>> Subject: Re: minutes for sync up on Open Attestation > > > >>>> integration with oVirt in 4/9 > > > >>>> > > > >>>> Hi Dave, > > > >>>> Adding Ofri to answer your questions. > > > >>>> > > > >>>> ----- Original Message ----- > > > >>>>> From: "Wei D Chen" > > > >>>>> To: "Gang Wei" , "Doron Fediuck" > > > >>>>> , > > > >>>>> "Buddy Cao" , "Lijuan Zhang" > > > >>>>> > > > >>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM > > > >>>>> Subject: RE: minutes for sync up on Open Attestation > > > >>>>> integration with oVirt in 4/9 > > > >>>>> > > > >>>>> Hi Doron, > > > >>>>> > > > >>>>> > > > >>>>> iii. Then periodic trust check will be added into background > > > >>>>> process > > > >>>>> for > > > >>>>> all existing hosts, once becoming non-trusted, mark it as > > > >>>>> non-operational. > > > >>>>> > > > >>>>> - [Dave] Would you give me some details about the > > > >>>>> ?background > > > >>>>> process? mentioned in our sync up meeting? What?s the process > > > >>>>> and where is related code? > > > >>>>> > > > >>> > > > >>> The use Quartz Job to scheduled background processes. > > > >>> An example can be found in: > > > >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > > > >>> 222) > > > >>> > > > >>> This code calls a method that is located in: > > > >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt > > > >>> /engin e/core/bll/quota/QuotaManager.java > > > >>> (Line: 1000) > > > >>> the @OnTimerMethodAnnotation annotation and the unique job name > > > >>> connects the two in runtime. > > > >>> > > > >>> The job can query the attestation server for all the host and > > > >>> then set untrusted hosts to Non-Operational. > > > >>> the best way would be to call SetNonOperationalVdsCommand with a > > > >>> new NonOperationalReason. > > > >>> This command tries to migrate all VMs from the host and then set > > > >>> it non operational. > > > >>> (We need to think about non-migrational VMs - should we close > > > >>> those VMs or keep the host running) > > > >>> > > > >> > > > >> One more thing you may want to consider; If we get a positive > > > >> response for a host which is currently non-operational, issue an > > > >> activate command to try and make it operational again. > > > >> Alternatively, you may decide not to handle it, assuming > > > >> untrusted hosts can only be activated manually (see below Ofri's > > > >> response on activating a host). > > > >> > > > >>>>> > > > >>>>> iv. If admin fixed the non-operational node and try to switch > > > >>>>> it > > > >>>>> to > > > >>>>> operational mode again, a trust check will happen to gate the > > > >>>>> switching. > > > >>>>> > > > >>>>> - [Dave] If there is a button provided from UI for > > > >>>>> checking > > > >>>>> the > > > >>>>> logic? or we need add an extra-button for attestation check only? > > > >>>>> > > > >>> > > > >>> In the UI we already have the "Activate" option. What still > > > >>> needs to be added is the check with the attestation provider to > > > >>> make sure that if the cluster is defined 'Trusted'. If so, only > > > >>> trusted host will succeed in the activate command (and, of > > > >>> course, a proper Audit Log error in case the host failed to activate > > > >>> due to trust issue. > > > >>> > > > >>> the correct place to add this check would be in: > > > >>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/org > > > >>> /ovirt > > > >>> /engine/core/vdsbroker/VdsManager.java:activate() > > > >>> this is where the re-activation process begins. > > > >>> > > > >>>>> > > > >>>>> Thanks very much. > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> Best Regards, > > > >>>>> Dave Chen > > > >> _______________________________________________ > > > >> 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 > > > _______________________________________________ > 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 wei.d.chen at intel.com Wed Apr 17 07:44:05 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Wed, 17 Apr 2013 07:44:05 +0000 Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: <1308686351.886592.1366183406691.JavaMail.root@redhat.com> References: <996306366.2192571.1365595398217.JavaMail.root@redhat.com> <189243164.4209095.1366006840007.JavaMail.root@redhat.com> <516BA2E8.7090207@redhat.com> <448237996.384685.1366009557875.JavaMail.root@redhat.com> <1045509486.480916.1366023642593.JavaMail.root@redhat.com> <1308686351.886592.1366183406691.JavaMail.root@redhat.com> Message-ID: Thanks Ofri, whether Quartz job is configurable? If we can config interval time, it will do us a favor. Best Regards, Dave Chen -----Original Message----- From: Ofri Masad [mailto:omasad at redhat.com] Sent: Wednesday, April 17, 2013 3:23 PM To: Chen, Wei D Cc: Omer Frenkel; Doron Fediuck; Oved Ourfalli; engine-devel at ovirt.org Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 Hi Dave, The VdsUpdateRunTimeInfo runs every 3 seconds or so. so it not a good place to call the attestation host. Instead, like we suggested earlier, create a new Quartz job (like the one I've sent you in the QuotaManager class) which run every couple of minutes and update the hosts state. You can also add the check to InitVdsOnUpCommand, so that if a host was down for a different reason, it will be rechecked for attestation. You can add a UI to allow manual "refresh attestation". Ofri ----- Original Message ----- > From: "Wei D Chen" > To: "Omer Frenkel" , "Doron Fediuck" > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > Sent: Monday, April 15, 2013 5:53:34 PM > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > integration with oVirt in 4/9 > > Good approach, thanks all. How long it needs to invoke periodic check > in the class of VdsUpdateRunTimeInfo? Whether this time configurable? > My concern is if the initial status of each host added into trusted > cluster is non-operational, we need wait a long time for the invoking > of this periodic check, so a trusted host's with initial status of > non-operational will take a long time to flip to a trusted host. > > As I have not seen the configuration of periodic check in > VdsUpdateRunTimeInfo, would you give me some tips if you has some clue. > Thanks a lot. > > Best Regards, > Dave Chen > > -----Original Message----- > From: engine-devel-bounces at ovirt.org > [mailto:engine-devel-bounces at ovirt.org] > On Behalf Of Omer Frenkel > Sent: Monday, April 15, 2013 7:01 PM > To: Doron Fediuck > Cc: Oved Ourfalli; engine-devel at ovirt.org > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > integration with oVirt in 4/9 > > > > ----- Original Message ----- > > From: "Doron Fediuck" > > To: "Itamar Heim" > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > Sent: Monday, April 15, 2013 10:05:57 AM > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > integration with oVirt in 4/9 > > > > > > > > ----- Original Message ----- > > > From: "Itamar Heim" > > > To: "Oved Ourfalli" > > > Cc: engine-devel at ovirt.org > > > Sent: Monday, April 15, 2013 9:49:12 AM > > > Subject: Re: [Engine-devel] minutes for sync up on Open > > > Attestation integration with oVirt in 4/9 > > > > > > On 04/15/2013 09:20 AM, Oved Ourfalli wrote: > > > > > > > > > > > > ----- Original Message ----- > > > >> From: "Wei D Chen" > > > >> To: "Doron Fediuck" , "Ofri Masad" > > > >> > > > >> Cc: engine-devel at ovirt.org > > > >> Sent: Monday, April 15, 2013 8:54:18 AM > > > >> Subject: Re: [Engine-devel] minutes for sync up on Open > > > >> Attestation integration with oVirt in 4/9 > > > >> > > > >> Hi Doron and Ofri, > > > >> > > > >> Thanks for your reply, here is some other question. > > > >> > > > >> ii. When adding a host into the trusted cluster, the host will > > > >> be attested via OAT service, only trusted hosted can be added. > > > >> > > > >> Would you also kindly tell me if there is any mandatory logic > > > >> check when adding a host into a cluster, so we can also put > > > >> attestation logic with these mandatory check together? Some > > > >> example or code location is better. > > > >> Thanks a lot. > > > >> > > > > > > > > I think there are two approaches, depending on the use case. > > > > #1: > > > > If the host trusted property is static, then you can narrow the > > > > tests to two locations: > > > > * AddVdsCommand - (Vds = Host) - This command is triggered when > > > > a new host is added to the system. You can use the canDoAction > > > > method (which we have on all commands, and it determines whether > > > > an action can be run or not), and there, if cluster requires > > > > trusted hosts only, you can test whether this host is trusted or > > > > not. > > > > * ChangeVdsClusterCommand - this command is used when you change > > > > the cluster of a host. So, if the target cluster requires > > > > tursted hosts, you can do a similar test in its canDoAction method. > > > > > > > > #2: > > > > If the host trusted property can change, then I'd suggest using > > > > the NonOperational property of a host. > > > > We have a class called VdsUpdateRunTimeInfo that does periodic > > > > tests of hosts, deciding what's their status, according to > > > > specific flags. > > > > The code there is quite complex, and would require refactoring > > > > at some point, but in the meantime you can use the > > > > MonitoringStrategy interface that is being used there, and > > > > implement a new monitoring strategy for Open Attestation. > > > > > > > > There, in the processHardwareCapabilities, you can test that the > > > > host is trusted. > > > > > > > > When creating the strategy, using the MonitoringStrategyFactory, > > > > you'll need to create the appropriate strategy. > > > > Currently we support either virt strategy or gluster strategy or > > > > both. In your case you would need virt+attestation / > > > > gluster+attestation / > > > > virt+gluster+attestation, according to the services deployed on > > > > virt+gluster+the > > > > cluster. > > > > > > I'd go with the 2nd approach. i.e., not block the host from being > > > added, only from being used, based on monitoring / non-op status > > > > > +1. > > It means that the admin can add the host, but the host will not be > > operational until we get a positive indication from the attestation > > service. > > > +1 > if we want to test attestation only once, every time before host moves to up. > the right place for it, imo, is InitVdsOnUpCommand if its periodic > also after host is up, then it should be somewhere in the monitoring > code > > > > > > > > > > > > > > > > Does that make sense? > > > > Doron and Ofri, what did you have in mind for this feature? > > > > > > > > Regards, > > > > Oved > > > > > > > >> > > > >> Best Regards, > > > >> Dave Chen > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: Doron Fediuck [mailto:dfediuck at redhat.com] > > > >> Sent: Wednesday, April 10, 2013 8:03 PM > > > >> To: Ofri Masad > > > >> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan > > > >> Subject: Re: minutes for sync up on Open Attestation > > > >> integration with oVirt in 4/9 > > > >> > > > >> > > > >> > > > >> ----- Original Message ----- > > > >>> From: "Ofri Masad" > > > >>> To: "Gang Wei" > > > >>> Cc: "Wei D Chen" , "Buddy Cao" > > > >>> , "Lijuan Zhang" > > > >>> , "Doron Fediuck" > > > >>> > > > >>> Sent: Wednesday, April 10, 2013 2:23:57 PM > > > >>> Subject: Re: minutes for sync up on Open Attestation > > > >>> integration with oVirt in 4/9 > > > >>> > > > >>> Hi, > > > >>> > > > >>> answers inside the mail body. > > > >>> > > > >>> ----- Original Message ----- > > > >>>> From: "Doron Fediuck" > > > >>>> To: "Wei D Chen" > > > >>>> Cc: "Gang Wei" , "Buddy Cao" > > > >>>> , "Lijuan Zhang" > > > >>>> , "Ofri Masad" > > > >>>> Sent: Wednesday, April 10, 2013 12:12:26 PM > > > >>>> Subject: Re: minutes for sync up on Open Attestation > > > >>>> integration with oVirt in 4/9 > > > >>>> > > > >>>> Hi Dave, > > > >>>> Adding Ofri to answer your questions. > > > >>>> > > > >>>> ----- Original Message ----- > > > >>>>> From: "Wei D Chen" > > > >>>>> To: "Gang Wei" , "Doron Fediuck" > > > >>>>> , > > > >>>>> "Buddy Cao" , "Lijuan Zhang" > > > >>>>> > > > >>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM > > > >>>>> Subject: RE: minutes for sync up on Open Attestation > > > >>>>> integration with oVirt in 4/9 > > > >>>>> > > > >>>>> Hi Doron, > > > >>>>> > > > >>>>> > > > >>>>> iii. Then periodic trust check will be added into background > > > >>>>> process > > > >>>>> for > > > >>>>> all existing hosts, once becoming non-trusted, mark it as > > > >>>>> non-operational. > > > >>>>> > > > >>>>> - [Dave] Would you give me some details about the > > > >>>>> ?background > > > >>>>> process? mentioned in our sync up meeting? What?s the > > > >>>>> process and where is related code? > > > >>>>> > > > >>> > > > >>> The use Quartz Job to scheduled background processes. > > > >>> An example can be found in: > > > >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > > > >>> 222) > > > >>> > > > >>> This code calls a method that is located in: > > > >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovi > > > >>> rt /engin e/core/bll/quota/QuotaManager.java > > > >>> (Line: 1000) > > > >>> the @OnTimerMethodAnnotation annotation and the unique job > > > >>> name connects the two in runtime. > > > >>> > > > >>> The job can query the attestation server for all the host and > > > >>> then set untrusted hosts to Non-Operational. > > > >>> the best way would be to call SetNonOperationalVdsCommand with > > > >>> a new NonOperationalReason. > > > >>> This command tries to migrate all VMs from the host and then > > > >>> set it non operational. > > > >>> (We need to think about non-migrational VMs - should we close > > > >>> those VMs or keep the host running) > > > >>> > > > >> > > > >> One more thing you may want to consider; If we get a positive > > > >> response for a host which is currently non-operational, issue > > > >> an activate command to try and make it operational again. > > > >> Alternatively, you may decide not to handle it, assuming > > > >> untrusted hosts can only be activated manually (see below > > > >> Ofri's response on activating a host). > > > >> > > > >>>>> > > > >>>>> iv. If admin fixed the non-operational node and try to switch > > > >>>>> it > > > >>>>> to > > > >>>>> operational mode again, a trust check will happen to gate > > > >>>>> the switching. > > > >>>>> > > > >>>>> - [Dave] If there is a button provided from UI for > > > >>>>> checking > > > >>>>> the > > > >>>>> logic? or we need add an extra-button for attestation check only? > > > >>>>> > > > >>> > > > >>> In the UI we already have the "Activate" option. What still > > > >>> needs to be added is the check with the attestation provider > > > >>> to make sure that if the cluster is defined 'Trusted'. If so, > > > >>> only trusted host will succeed in the activate command (and, > > > >>> of course, a proper Audit Log error in case the host failed to > > > >>> activate due to trust issue. > > > >>> > > > >>> the correct place to add this check would be in: > > > >>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/o > > > >>> rg > > > >>> /ovirt > > > >>> /engine/core/vdsbroker/VdsManager.java:activate() > > > >>> this is where the re-activation process begins. > > > >>> > > > >>>>> > > > >>>>> Thanks very much. > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> Best Regards, > > > >>>>> Dave Chen > > > >> _______________________________________________ > > > >> 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 > > > _______________________________________________ > 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 ovedo at redhat.com Wed Apr 17 09:13:12 2013 From: ovedo at redhat.com (Oved Ourfalli) Date: Wed, 17 Apr 2013 05:13:12 -0400 (EDT) Subject: [Engine-devel] Proposal to make REST API more webapp-friendly In-Reply-To: <2140658645.762187.1366023864071.JavaMail.root@redhat.com> References: <2140658645.762187.1366023864071.JavaMail.root@redhat.com> Message-ID: <815104772.15680618.1366189992223.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Vojtech Szocs" > To: "engine-devel" > Sent: Monday, April 15, 2013 2:04:24 PM > Subject: [Engine-devel] Proposal to make REST API more webapp-friendly > > Hi guys, > > having worked with Engine REST API from web application (JavaScript) > perspective, there are things that could be improved to make REST API more > webapp-friendly. > > First of all, webapps are *not* traditional HTTP clients, i.e. they have > *not* full control over HTTP processing. There are some standard conventions > and behaviors built into web browsers that any REST API implementation > should be aware of. > > -- > > (1) Don't force clients to use cookies for transmitting authentication > information! (or don't use cookies at all) > > Good explanation can be found at > [http://www.berenddeboer.net/rest/cookies.html]. Cookies have many > disadvantages: > > * cookie parsing/formatting is not trivial > --> extra complexity imposed on REST clients > > * in addition to Same-Origin Policy > [http://en.wikipedia.org/wiki/Same_origin_policy], cookies can be get/set > *only* for the given path > --> JavaScript running at [http://example.com/webapp] *cannot* get/set > cookies from requests at [http://example.com/restapi] > > * cookies are the primary source of Cross-Site Request Forgery > [http://en.wikipedia.org/wiki/Cross-site_request_forgery] attacks > --> malicious websites/scripts can forge requests to REST API that will > include the cookie, compromising user session > > Alternative: clients could be given the *option* to use regular HTTP header > for transmitting authentication information. > > For example, webapp could read such (sensitive information) header, store it > securely via HTML5 Session Storage > [http://en.wikipedia.org/wiki/Web_storage] and implement related HTTP > processing on its own, e.g. pass this header for all authenticated requests > (instead of pushing this responsibility to browser). > Option #1: We currently return the JSESSIONID also using HTTP headers. We currently return the jsession id also as part of the response HTTP headers, but the client still needs to pass a cookie with the appropriate value in order for the REST session to work. Isn't that enough to cope with this issue? If not, then we might be able to do option #2: Today, we keep the engine session ID on the HTTP session attributes. So, we can support either passing the cookie with the JSESSIONID (taking the engine session ID from the http session), or passing the engine session ID as HTTP header (assuming we would also return the engine session ID upon first REST request). This approach is problematic, as it might work well now, when the only attribute we use is the engine session ID, but in the future that might not be the case. If it is important enough (i.e., you can't really work with option #1) , then we can make a decision to save the attributes on the engine session, rather than on the HTTP session. So, we would start by supporting them both together, adding new attributes only to the engine session, and in the future deprecating the use of cookies, and only supporting HTTP headers. cc-ed Juan and Michael, as they might have some input on that. > -- > > (2) Straight-forward HTTP Basic Auth has some drawbacks! > > HTTP Basic Auth [http://en.wikipedia.org/wiki/Basic_access_authentication] > over (non-secure) HTTP connection means sending user credentials > (username/password/domain) in easy-to-decode cleartext, i.e. the value is > *not* encrypted or hashed in any way. Using secure lower-level protocol > (SSL) fixes the consequence, rather than the root cause of the > confidentiality issue. > > Furthermore, browsers typically remember HTTP Basic Auth information (either > via browser-specific popup, or via XmlHttpRequest) until the browser window > is closed. This means the webapp has no control over HTTP Basic Auth header > after it has been set! This is the reason why it's hard to implement > "logout" functionality in webapps when using HTTP Basic Auth. > > Last but not least, HTTP Basic Auth is vulnerable to Replay attacks > [http://en.wikipedia.org/wiki/Replay_attack]. Someone between client and > server can intercept requests and replay them, compromising user session. > > Alternative: clients could be given the *option* to use more advanced > authentication scheme. > > I've just read an excellent article at > [http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/] > which describes easy yet secure authentication scheme inspired by Amazon Web > Services REST API authentication > [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html]. > The idea is simple: collect auth information, hash (sign) it with a private > key, and send everything to server. To guard against Replay attacks, just > provide some timestamp to enforce request expiry after some time (say, 5-15 > minutes). Easy and simple! > > -- > > (3) Support JSON for resource representations! > > I think this is pretty much obvious. XML has no real advantages over JSON. > JSON, on the other hand, has good support in webapps (JavaScript) and maps > directly to common data structures (i.e. string, number, boolean, and so > on). > > From webapp perspective, it's much easier and natural to use JSON than to > parse/format XML documents. > > Alternative: clients could be given the *option* to use JSON, in addition to > XML representation. > > -- > > Vojtech > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From alexont234 at gmail.com Wed Apr 17 09:27:41 2013 From: alexont234 at gmail.com (Alex Ont) Date: Wed, 17 Apr 2013 11:27:41 +0200 Subject: [Engine-devel] Starting a new translation Message-ID: Hi, Trying to translate the userportal ... How should one obtain the English properties file to jumpstart the translation? e.g. There are ApplicationConstants_xxx.properties for already translated locales, but there is no English version. Thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhornyak at redhat.com Wed Apr 17 09:38:29 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Wed, 17 Apr 2013 05:38:29 -0400 (EDT) Subject: [Engine-devel] Starting a new translation In-Reply-To: References: Message-ID: <466095417.1634091.1366191509801.JavaMail.root@redhat.com> Hi Alex, We are doing translations on zanata. Sign up, add your languages to your profile and please send Einav the language you would like to translate, she will add it to the ovIrt project. https://translate.zanata.org/zanata/project/view/ovirt (A translations howto in the wiki is on my todo list) Laszlo ----- Original Message ----- > From: "Alex Ont" > To: engine-devel at ovirt.org > Sent: Wednesday, April 17, 2013 11:27:41 AM > Subject: [Engine-devel] Starting a new translation > Hi, > Trying to translate the userportal ... > How should one obtain the English properties file to jumpstart the > translation? > e.g. There are ApplicationConstants_xxx.properties for already translated > locales, but there is no English version. > Thanks, > Alex > _______________________________________________ > 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: From mpastern at redhat.com Wed Apr 17 09:56:43 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 17 Apr 2013 12:56:43 +0300 Subject: [Engine-devel] Proposal to make REST API more webapp-friendly In-Reply-To: <815104772.15680618.1366189992223.JavaMail.root@redhat.com> References: <2140658645.762187.1366023864071.JavaMail.root@redhat.com> <815104772.15680618.1366189992223.JavaMail.root@redhat.com> Message-ID: <516E71DB.1010801@redhat.com> Hi Vojtech/Oved, On 04/17/2013 12:13 PM, Oved Ourfalli wrote: > > > ----- Original Message ----- >> From: "Vojtech Szocs" >> To: "engine-devel" >> Sent: Monday, April 15, 2013 2:04:24 PM >> Subject: [Engine-devel] Proposal to make REST API more webapp-friendly >> >> Hi guys, >> >> having worked with Engine REST API from web application (JavaScript) >> perspective, there are things that could be improved to make REST API more >> webapp-friendly. >> >> First of all, webapps are *not* traditional HTTP clients, i.e. they have >> *not* full control over HTTP processing. There are some standard conventions >> and behaviors built into web browsers that any REST API implementation >> should be aware of. >> >> -- >> >> (1) Don't force clients to use cookies for transmitting authentication >> information! (or don't use cookies at all) >> >> Good explanation can be found at >> [http://www.berenddeboer.net/rest/cookies.html]. Cookies have many >> disadvantages: >> >> * cookie parsing/formatting is not trivial >> --> extra complexity imposed on REST clients i wouldn't call it a cookie blocker, as in most cases (including ours) cookie contains restricted amount of records. >> >> * in addition to Same-Origin Policy >> [http://en.wikipedia.org/wiki/Same_origin_policy], cookies can be get/set >> *only* for the given path >> --> JavaScript running at [http://example.com/webapp] *cannot* get/set >> cookies from requests at [http://example.com/restapi] >> >> * cookies are the primary source of Cross-Site Request Forgery >> [http://en.wikipedia.org/wiki/Cross-site_request_forgery] attacks >> --> malicious websites/scripts can forge requests to REST API that will >> include the cookie, compromising user session same true for the authorization header, session being passed via HTTP headers >> >> Alternative: clients could be given the *option* to use regular HTTP header >> for transmitting authentication information. >> >> For example, webapp could read such (sensitive information) header, store it >> securely via HTML5 Session Storage >> [http://en.wikipedia.org/wiki/Web_storage] and implement related HTTP >> processing on its own, e.g. pass this header for all authenticated requests >> (instead of pushing this responsibility to browser). >> > > Option #1: > We currently return the JSESSIONID also using HTTP headers. We currently return the jsession id also as part of the response HTTP headers, but the client still needs to pass a cookie with the appropriate value in order for the REST session to work. Isn't that enough to cope with this issue? api, can consume JSESSIONID from the header indeed, but my problem with this approach is a persistence of the http headers in browsers. > > If not, then we might be able to do option #2: > Today, we keep the engine session ID on the HTTP session attributes. > So, we can support either passing the cookie with the JSESSIONID (taking the engine session ID from the http session), or passing the engine session ID as HTTP header (assuming we would also return the engine session ID upon first REST request). > > This approach is problematic, as it might work well now, when the only attribute we use is the engine session ID, but in the future that might not be the case. > If it is important enough (i.e., you can't really work with option #1) , then we can make a decision to save the attributes on the engine session, rather than on the HTTP session. > So, we would start by supporting them both together, adding new attributes only to the engine session, and in the future deprecating the use of cookies, and only supporting HTTP headers. > > cc-ed Juan and Michael, as they might have some input on that. > > >> -- >> >> (2) Straight-forward HTTP Basic Auth has some drawbacks! >> >> HTTP Basic Auth [http://en.wikipedia.org/wiki/Basic_access_authentication] >> over (non-secure) HTTP connection means sending user credentials >> (username/password/domain) in easy-to-decode cleartext, i.e. the value is >> *not* encrypted or hashed in any way. Using secure lower-level protocol >> (SSL) fixes the consequence, rather than the root cause of the >> confidentiality issue. same is true for any sensitive date being passed via plain text (including cookies) >> >> Furthermore, browsers typically remember HTTP Basic Auth information (either >> via browser-specific popup, or via XmlHttpRequest) until the browser window >> is closed. This means the webapp has no control over HTTP Basic Auth header >> after it has been set! This is the reason why it's hard to implement >> "logout" functionality in webapps when using HTTP Basic Auth. right, that is my concern of using headers as well, better solution may be sending JSESSION id via URI matrix parameter, e.g /api/vms;sessionid=xxx >> >> Last but not least, HTTP Basic Auth is vulnerable to Replay attacks >> [http://en.wikipedia.org/wiki/Replay_attack]. Someone between client and >> server can intercept requests and replay them, compromising user session. >> >> Alternative: clients could be given the *option* to use more advanced >> authentication scheme. >> >> I've just read an excellent article at >> [http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/] >> which describes easy yet secure authentication scheme inspired by Amazon Web >> Services REST API authentication >> [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html]. >> The idea is simple: collect auth information, hash (sign) it with a private >> key, and send everything to server. To guard against Replay attacks, just >> provide some timestamp to enforce request expiry after some time (say, 5-15 >> minutes). Easy and simple! 1. this concept has very same drawbacks as any other content encryption 2. decoding time stamp from request/s will produce fair load for the server as well and won't protect the server against DDOS, also it shouldn't as it's not api/webapp prerogative. in general what Vojtech is trying to achieve is passing session via some other container than cookie as webapp/browsers can't omit auth. header in runtime, what is only justifying my resistance of passing session id via http header, i think using matrix parameter (as mentioned above) may give you a decent solution. >> >> -- >> >> (3) Support JSON for resource representations! >> >> I think this is pretty much obvious. XML has no real advantages over JSON. >> JSON, on the other hand, has good support in webapps (JavaScript) and maps >> directly to common data structures (i.e. string, number, boolean, and so >> on). >> >> From webapp perspective, it's much easier and natural to use JSON than to >> parse/format XML documents. >> >> Alternative: clients could be given the *option* to use JSON, in addition to >> XML representation. not sure how it's related, but we plan supporting JSON in future. >> >> -- >> >> Vojtech >> _______________________________________________ >> 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 vszocs at redhat.com Wed Apr 17 10:25:06 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Wed, 17 Apr 2013 06:25:06 -0400 (EDT) Subject: [Engine-devel] Proposal to make REST API more webapp-friendly In-Reply-To: <815104772.15680618.1366189992223.JavaMail.root@redhat.com> References: <2140658645.762187.1366023864071.JavaMail.root@redhat.com> <815104772.15680618.1366189992223.JavaMail.root@redhat.com> Message-ID: <697492056.2007786.1366194306086.JavaMail.root@redhat.com> Hi Oved, thanks for your feedback! > We currently return the JSESSIONID also using HTTP headers. We currently return the jsession id also as part of the response HTTP headers, but the client still needs to pass a cookie with the appropriate value in order for the REST session to work. Isn't that enough to cope with this issue? Right, currently REST API responds with JSESSIONID cookie + separate JSESSIONID response header, both carrying session ID value. As I wrote in my original email: JavaScript running at [http://example.com/webapp] *cannot* get/set cookies from requests at [http://example.com/restapi] So WebAdmin cannot get/set REST API JSESSIONID cookie directly, which is why it uses separate JSESSIONID response header in order to *read* the session ID value. As for sending JSESSIONID cookie, WebAdmin currently relies on standard cookie-handling implemented in browsers: all cookies for location X [http://example.com/restapi] will be part of any request to location X. So it's the browser who sets JSESSIONID cookie for REST API request, not WebAdmin. To answer your question, currently it's enough to work around the cookie access limitation, but it's not good enough in my opinion (from JavaScript/webapp perspective).. > If not, then we might be able to do option #2: > Today, we keep the engine session ID on the HTTP session attributes. > So, we can support either passing the cookie with the JSESSIONID (taking the engine session ID from the http session), or passing the engine session ID as HTTP header (assuming we would also return the engine session ID upon first REST request). Well, the problem I described only relates to the way how JSESSIONID value is transmitted between client and server: currently using cookies, so REST API client has to do cookie handling. It would be really great if I could tell REST API to use plain (i.e. *not* Set-Cookie & Cookie) HTTP header, for example "JSESSIONID", for the purpose of transmitting session ID value between client and server. For example, the request to acquire session would be: GET /api HTTP/1.1 Host: www.example.org Prefer: use-jsessionid-header JSESSIONID: xxx [Feel free to replace "use-jsessionid-header" with anything you like. If client doesn't specify "use-jsessionid-header", server expects "Cookie" header by default to preserve compatibility.] And the response would be: HTTP/1.1 200 OK JSESSIONID: xxx [If client didn't specify "use-jsessionid-header", server would use "Set-Cookie" header by default to preserve compatibility.] > This approach is problematic, as it might work well now, when the only attribute we use is the engine session ID, but in the future that might not be the case. > If it is important enough (i.e., you can't really work with option #1) , then we can make a decision to save the attributes on the engine session, rather than on the HTTP session. > So, we would start by supporting them both together, adding new attributes only to the engine session, and in the future deprecating the use of cookies, and only supporting HTTP headers. I think you can keep the current implementation, i.e. use REST API HttpSession to store Engine session ID value. The only difference would be, when REST API receives the request, it looks for "Prefer:use-jsessionid-header", and if it's present, it uses "JSESSIONID" header value to look up HttpSession in some way (not sure about implementation details, though, but this should be possible to do). So, what do you think? Vojtech ----- Original Message ----- From: "Oved Ourfalli" To: "Vojtech Szocs" Cc: "engine-devel" , "Juan Hernandez" , "Michael Pasternak" Sent: Wednesday, April 17, 2013 11:13:12 AM Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly ----- Original Message ----- > From: "Vojtech Szocs" > To: "engine-devel" > Sent: Monday, April 15, 2013 2:04:24 PM > Subject: [Engine-devel] Proposal to make REST API more webapp-friendly > > Hi guys, > > having worked with Engine REST API from web application (JavaScript) > perspective, there are things that could be improved to make REST API more > webapp-friendly. > > First of all, webapps are *not* traditional HTTP clients, i.e. they have > *not* full control over HTTP processing. There are some standard conventions > and behaviors built into web browsers that any REST API implementation > should be aware of. > > -- > > (1) Don't force clients to use cookies for transmitting authentication > information! (or don't use cookies at all) > > Good explanation can be found at > [http://www.berenddeboer.net/rest/cookies.html]. Cookies have many > disadvantages: > > * cookie parsing/formatting is not trivial > --> extra complexity imposed on REST clients > > * in addition to Same-Origin Policy > [http://en.wikipedia.org/wiki/Same_origin_policy], cookies can be get/set > *only* for the given path > --> JavaScript running at [http://example.com/webapp] *cannot* get/set > cookies from requests at [http://example.com/restapi] > > * cookies are the primary source of Cross-Site Request Forgery > [http://en.wikipedia.org/wiki/Cross-site_request_forgery] attacks > --> malicious websites/scripts can forge requests to REST API that will > include the cookie, compromising user session > > Alternative: clients could be given the *option* to use regular HTTP header > for transmitting authentication information. > > For example, webapp could read such (sensitive information) header, store it > securely via HTML5 Session Storage > [http://en.wikipedia.org/wiki/Web_storage] and implement related HTTP > processing on its own, e.g. pass this header for all authenticated requests > (instead of pushing this responsibility to browser). > Option #1: We currently return the JSESSIONID also using HTTP headers. We currently return the jsession id also as part of the response HTTP headers, but the client still needs to pass a cookie with the appropriate value in order for the REST session to work. Isn't that enough to cope with this issue? If not, then we might be able to do option #2: Today, we keep the engine session ID on the HTTP session attributes. So, we can support either passing the cookie with the JSESSIONID (taking the engine session ID from the http session), or passing the engine session ID as HTTP header (assuming we would also return the engine session ID upon first REST request). This approach is problematic, as it might work well now, when the only attribute we use is the engine session ID, but in the future that might not be the case. If it is important enough (i.e., you can't really work with option #1) , then we can make a decision to save the attributes on the engine session, rather than on the HTTP session. So, we would start by supporting them both together, adding new attributes only to the engine session, and in the future deprecating the use of cookies, and only supporting HTTP headers. cc-ed Juan and Michael, as they might have some input on that. > -- > > (2) Straight-forward HTTP Basic Auth has some drawbacks! > > HTTP Basic Auth [http://en.wikipedia.org/wiki/Basic_access_authentication] > over (non-secure) HTTP connection means sending user credentials > (username/password/domain) in easy-to-decode cleartext, i.e. the value is > *not* encrypted or hashed in any way. Using secure lower-level protocol > (SSL) fixes the consequence, rather than the root cause of the > confidentiality issue. > > Furthermore, browsers typically remember HTTP Basic Auth information (either > via browser-specific popup, or via XmlHttpRequest) until the browser window > is closed. This means the webapp has no control over HTTP Basic Auth header > after it has been set! This is the reason why it's hard to implement > "logout" functionality in webapps when using HTTP Basic Auth. > > Last but not least, HTTP Basic Auth is vulnerable to Replay attacks > [http://en.wikipedia.org/wiki/Replay_attack]. Someone between client and > server can intercept requests and replay them, compromising user session. > > Alternative: clients could be given the *option* to use more advanced > authentication scheme. > > I've just read an excellent article at > [http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/] > which describes easy yet secure authentication scheme inspired by Amazon Web > Services REST API authentication > [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html]. > The idea is simple: collect auth information, hash (sign) it with a private > key, and send everything to server. To guard against Replay attacks, just > provide some timestamp to enforce request expiry after some time (say, 5-15 > minutes). Easy and simple! > > -- > > (3) Support JSON for resource representations! > > I think this is pretty much obvious. XML has no real advantages over JSON. > JSON, on the other hand, has good support in webapps (JavaScript) and maps > directly to common data structures (i.e. string, number, boolean, and so > on). > > From webapp perspective, it's much easier and natural to use JSON than to > parse/format XML documents. > > Alternative: clients could be given the *option* to use JSON, in addition to > XML representation. > > -- > > Vojtech > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From ovedo at redhat.com Wed Apr 17 10:29:09 2013 From: ovedo at redhat.com (Oved Ourfalli) Date: Wed, 17 Apr 2013 06:29:09 -0400 (EDT) Subject: [Engine-devel] Proposal to make REST API more webapp-friendly In-Reply-To: <697492056.2007786.1366194306086.JavaMail.root@redhat.com> References: <2140658645.762187.1366023864071.JavaMail.root@redhat.com> <815104772.15680618.1366189992223.JavaMail.root@redhat.com> <697492056.2007786.1366194306086.JavaMail.root@redhat.com> Message-ID: <1616192035.15952873.1366194549669.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Vojtech Szocs" > To: "Oved Ourfalli" > Cc: "Juan Hernandez" , "engine-devel" > Sent: Wednesday, April 17, 2013 1:25:06 PM > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > Hi Oved, thanks for your feedback! > > > We currently return the JSESSIONID also using HTTP headers. We currently > > return the jsession id also as part of the response HTTP headers, but the > > client still needs to pass a cookie with the appropriate value in order > > for the REST session to work. Isn't that enough to cope with this issue? > > Right, currently REST API responds with JSESSIONID cookie + separate > JSESSIONID response header, both carrying session ID value. > > As I wrote in my original email: JavaScript running at > [http://example.com/webapp] *cannot* get/set cookies from requests at > [http://example.com/restapi] > > So WebAdmin cannot get/set REST API JSESSIONID cookie directly, which is why > it uses separate JSESSIONID response header in order to *read* the session > ID value. As for sending JSESSIONID cookie, WebAdmin currently relies on > standard cookie-handling implemented in browsers: all cookies for location X > [http://example.com/restapi] will be part of any request to location X. So > it's the browser who sets JSESSIONID cookie for REST API request, not > WebAdmin. > > To answer your question, currently it's enough to work around the cookie > access limitation, but it's not good enough in my opinion (from > JavaScript/webapp perspective).. > > > If not, then we might be able to do option #2: > > Today, we keep the engine session ID on the HTTP session attributes. > > So, we can support either passing the cookie with the JSESSIONID (taking > > the engine session ID from the http session), or passing the engine > > session ID as HTTP header (assuming we would also return the engine > > session ID upon first REST request). > > Well, the problem I described only relates to the way how JSESSIONID value is > transmitted between client and server: currently using cookies, so REST API > client has to do cookie handling. > > It would be really great if I could tell REST API to use plain (i.e. *not* > Set-Cookie & Cookie) HTTP header, for example "JSESSIONID", for the purpose > of transmitting session ID value between client and server. > > For example, the request to acquire session would be: > > GET /api HTTP/1.1 > Host: www.example.org > Prefer: use-jsessionid-header > JSESSIONID: xxx > > [Feel free to replace "use-jsessionid-header" with anything you like. If > client doesn't specify "use-jsessionid-header", server expects "Cookie" > header by default to preserve compatibility.] > > And the response would be: > > HTTP/1.1 200 OK > JSESSIONID: xxx > > [If client didn't specify "use-jsessionid-header", server would use > "Set-Cookie" header by default to preserve compatibility.] > > > This approach is problematic, as it might work well now, when the only > > attribute we use is the engine session ID, but in the future that might > > not be the case. > > If it is important enough (i.e., you can't really work with option #1) , > > then we can make a decision to save the attributes on the engine session, > > rather than on the HTTP session. > > So, we would start by supporting them both together, adding new attributes > > only to the engine session, and in the future deprecating the use of > > cookies, and only supporting HTTP headers. > > I think you can keep the current implementation, i.e. use REST API > HttpSession to store Engine session ID value. > > The only difference would be, when REST API receives the request, it looks > for "Prefer:use-jsessionid-header", and if it's present, it uses > "JSESSIONID" header value to look up HttpSession in some way (not sure about > implementation details, though, but this should be possible to do). > > So, what do you think? > As far as I saw, the handling of the cookie is done before the REST code, and that's why we need the cookie. Perhaps there is a way to make jboss take the JSESSIONID from the HTTP header, and not the cookie, but I didn't find a way to do that yet. > Vojtech > > > ----- Original Message ----- > From: "Oved Ourfalli" > To: "Vojtech Szocs" > Cc: "engine-devel" , "Juan Hernandez" > , "Michael Pasternak" > Sent: Wednesday, April 17, 2013 11:13:12 AM > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > ----- Original Message ----- > > From: "Vojtech Szocs" > > To: "engine-devel" > > Sent: Monday, April 15, 2013 2:04:24 PM > > Subject: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > Hi guys, > > > > having worked with Engine REST API from web application (JavaScript) > > perspective, there are things that could be improved to make REST API more > > webapp-friendly. > > > > First of all, webapps are *not* traditional HTTP clients, i.e. they have > > *not* full control over HTTP processing. There are some standard > > conventions > > and behaviors built into web browsers that any REST API implementation > > should be aware of. > > > > -- > > > > (1) Don't force clients to use cookies for transmitting authentication > > information! (or don't use cookies at all) > > > > Good explanation can be found at > > [http://www.berenddeboer.net/rest/cookies.html]. Cookies have many > > disadvantages: > > > > * cookie parsing/formatting is not trivial > > --> extra complexity imposed on REST clients > > > > * in addition to Same-Origin Policy > > [http://en.wikipedia.org/wiki/Same_origin_policy], cookies can be get/set > > *only* for the given path > > --> JavaScript running at [http://example.com/webapp] *cannot* get/set > > cookies from requests at [http://example.com/restapi] > > > > * cookies are the primary source of Cross-Site Request Forgery > > [http://en.wikipedia.org/wiki/Cross-site_request_forgery] attacks > > --> malicious websites/scripts can forge requests to REST API that will > > include the cookie, compromising user session > > > > Alternative: clients could be given the *option* to use regular HTTP header > > for transmitting authentication information. > > > > For example, webapp could read such (sensitive information) header, store > > it > > securely via HTML5 Session Storage > > [http://en.wikipedia.org/wiki/Web_storage] and implement related HTTP > > processing on its own, e.g. pass this header for all authenticated requests > > (instead of pushing this responsibility to browser). > > > > Option #1: > We currently return the JSESSIONID also using HTTP headers. We currently > return the jsession id also as part of the response HTTP headers, but the > client still needs to pass a cookie with the appropriate value in order for > the REST session to work. Isn't that enough to cope with this issue? > > If not, then we might be able to do option #2: > Today, we keep the engine session ID on the HTTP session attributes. > So, we can support either passing the cookie with the JSESSIONID (taking the > engine session ID from the http session), or passing the engine session ID > as HTTP header (assuming we would also return the engine session ID upon > first REST request). > > This approach is problematic, as it might work well now, when the only > attribute we use is the engine session ID, but in the future that might not > be the case. > If it is important enough (i.e., you can't really work with option #1) , then > we can make a decision to save the attributes on the engine session, rather > than on the HTTP session. > So, we would start by supporting them both together, adding new attributes > only to the engine session, and in the future deprecating the use of > cookies, and only supporting HTTP headers. > > cc-ed Juan and Michael, as they might have some input on that. > > > > -- > > > > (2) Straight-forward HTTP Basic Auth has some drawbacks! > > > > HTTP Basic Auth [http://en.wikipedia.org/wiki/Basic_access_authentication] > > over (non-secure) HTTP connection means sending user credentials > > (username/password/domain) in easy-to-decode cleartext, i.e. the value is > > *not* encrypted or hashed in any way. Using secure lower-level protocol > > (SSL) fixes the consequence, rather than the root cause of the > > confidentiality issue. > > > > Furthermore, browsers typically remember HTTP Basic Auth information > > (either > > via browser-specific popup, or via XmlHttpRequest) until the browser window > > is closed. This means the webapp has no control over HTTP Basic Auth header > > after it has been set! This is the reason why it's hard to implement > > "logout" functionality in webapps when using HTTP Basic Auth. > > > > Last but not least, HTTP Basic Auth is vulnerable to Replay attacks > > [http://en.wikipedia.org/wiki/Replay_attack]. Someone between client and > > server can intercept requests and replay them, compromising user session. > > > > Alternative: clients could be given the *option* to use more advanced > > authentication scheme. > > > > I've just read an excellent article at > > [http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/] > > which describes easy yet secure authentication scheme inspired by Amazon > > Web > > Services REST API authentication > > [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html]. > > The idea is simple: collect auth information, hash (sign) it with a private > > key, and send everything to server. To guard against Replay attacks, just > > provide some timestamp to enforce request expiry after some time (say, 5-15 > > minutes). Easy and simple! > > > > -- > > > > (3) Support JSON for resource representations! > > > > I think this is pretty much obvious. XML has no real advantages over JSON. > > JSON, on the other hand, has good support in webapps (JavaScript) and maps > > directly to common data structures (i.e. string, number, boolean, and so > > on). > > > > From webapp perspective, it's much easier and natural to use JSON than to > > parse/format XML documents. > > > > Alternative: clients could be given the *option* to use JSON, in addition > > to > > XML representation. > > > > -- > > > > Vojtech > > _______________________________________________ > > 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 omasad at redhat.com Wed Apr 17 12:26:21 2013 From: omasad at redhat.com (Ofri Masad) Date: Wed, 17 Apr 2013 08:26:21 -0400 (EDT) Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: References: <189243164.4209095.1366006840007.JavaMail.root@redhat.com> <516BA2E8.7090207@redhat.com> <448237996.384685.1366009557875.JavaMail.root@redhat.com> <1045509486.480916.1366023642593.JavaMail.root@redhat.com> <1308686351.886592.1366183406691.JavaMail.root@redhat.com> Message-ID: <1067196654.943539.1366201581343.JavaMail.root@redhat.com> Of course, If you create a new Quartz job is fully configurable. look at my answers in the beginning of this thread Ofri ----- Original Message ----- > From: "Wei D Chen" > To: "Ofri Masad" > Cc: "Omer Frenkel" , "Doron Fediuck" , "Oved Ourfalli" , > engine-devel at ovirt.org > Sent: Wednesday, April 17, 2013 10:44:05 AM > Subject: RE: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 > > Thanks Ofri, whether Quartz job is configurable? If we can config interval > time, it will do us a favor. > > Best Regards, > Dave Chen > > > -----Original Message----- > From: Ofri Masad [mailto:omasad at redhat.com] > Sent: Wednesday, April 17, 2013 3:23 PM > To: Chen, Wei D > Cc: Omer Frenkel; Doron Fediuck; Oved Ourfalli; engine-devel at ovirt.org > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > integration with oVirt in 4/9 > > Hi Dave, > The VdsUpdateRunTimeInfo runs every 3 seconds or so. so it not a good place > to call the attestation host. > Instead, like we suggested earlier, create a new Quartz job (like the one > I've sent you in the QuotaManager class) which run every couple of minutes > and update the hosts state. > You can also add the check to InitVdsOnUpCommand, so that if a host was down > for a different reason, it will be rechecked for attestation. > You can add a UI to allow manual "refresh attestation". > > Ofri > > ----- Original Message ----- > > From: "Wei D Chen" > > To: "Omer Frenkel" , "Doron Fediuck" > > > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > Sent: Monday, April 15, 2013 5:53:34 PM > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > integration with oVirt in 4/9 > > > > Good approach, thanks all. How long it needs to invoke periodic check > > in the class of VdsUpdateRunTimeInfo? Whether this time configurable? > > My concern is if the initial status of each host added into trusted > > cluster is non-operational, we need wait a long time for the invoking > > of this periodic check, so a trusted host's with initial status of > > non-operational will take a long time to flip to a trusted host. > > > > As I have not seen the configuration of periodic check in > > VdsUpdateRunTimeInfo, would you give me some tips if you has some clue. > > Thanks a lot. > > > > Best Regards, > > Dave Chen > > > > -----Original Message----- > > From: engine-devel-bounces at ovirt.org > > [mailto:engine-devel-bounces at ovirt.org] > > On Behalf Of Omer Frenkel > > Sent: Monday, April 15, 2013 7:01 PM > > To: Doron Fediuck > > Cc: Oved Ourfalli; engine-devel at ovirt.org > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > integration with oVirt in 4/9 > > > > > > > > ----- Original Message ----- > > > From: "Doron Fediuck" > > > To: "Itamar Heim" > > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > > Sent: Monday, April 15, 2013 10:05:57 AM > > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > > integration with oVirt in 4/9 > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Itamar Heim" > > > > To: "Oved Ourfalli" > > > > Cc: engine-devel at ovirt.org > > > > Sent: Monday, April 15, 2013 9:49:12 AM > > > > Subject: Re: [Engine-devel] minutes for sync up on Open > > > > Attestation integration with oVirt in 4/9 > > > > > > > > On 04/15/2013 09:20 AM, Oved Ourfalli wrote: > > > > > > > > > > > > > > > ----- Original Message ----- > > > > >> From: "Wei D Chen" > > > > >> To: "Doron Fediuck" , "Ofri Masad" > > > > >> > > > > >> Cc: engine-devel at ovirt.org > > > > >> Sent: Monday, April 15, 2013 8:54:18 AM > > > > >> Subject: Re: [Engine-devel] minutes for sync up on Open > > > > >> Attestation integration with oVirt in 4/9 > > > > >> > > > > >> Hi Doron and Ofri, > > > > >> > > > > >> Thanks for your reply, here is some other question. > > > > >> > > > > >> ii. When adding a host into the trusted cluster, the host will > > > > >> be attested via OAT service, only trusted hosted can be added. > > > > >> > > > > >> Would you also kindly tell me if there is any mandatory logic > > > > >> check when adding a host into a cluster, so we can also put > > > > >> attestation logic with these mandatory check together? Some > > > > >> example or code location is better. > > > > >> Thanks a lot. > > > > >> > > > > > > > > > > I think there are two approaches, depending on the use case. > > > > > #1: > > > > > If the host trusted property is static, then you can narrow the > > > > > tests to two locations: > > > > > * AddVdsCommand - (Vds = Host) - This command is triggered when > > > > > a new host is added to the system. You can use the canDoAction > > > > > method (which we have on all commands, and it determines whether > > > > > an action can be run or not), and there, if cluster requires > > > > > trusted hosts only, you can test whether this host is trusted or > > > > > not. > > > > > * ChangeVdsClusterCommand - this command is used when you change > > > > > the cluster of a host. So, if the target cluster requires > > > > > tursted hosts, you can do a similar test in its canDoAction method. > > > > > > > > > > #2: > > > > > If the host trusted property can change, then I'd suggest using > > > > > the NonOperational property of a host. > > > > > We have a class called VdsUpdateRunTimeInfo that does periodic > > > > > tests of hosts, deciding what's their status, according to > > > > > specific flags. > > > > > The code there is quite complex, and would require refactoring > > > > > at some point, but in the meantime you can use the > > > > > MonitoringStrategy interface that is being used there, and > > > > > implement a new monitoring strategy for Open Attestation. > > > > > > > > > > There, in the processHardwareCapabilities, you can test that the > > > > > host is trusted. > > > > > > > > > > When creating the strategy, using the MonitoringStrategyFactory, > > > > > you'll need to create the appropriate strategy. > > > > > Currently we support either virt strategy or gluster strategy or > > > > > both. In your case you would need virt+attestation / > > > > > gluster+attestation / > > > > > virt+gluster+attestation, according to the services deployed on > > > > > virt+gluster+the > > > > > cluster. > > > > > > > > I'd go with the 2nd approach. i.e., not block the host from being > > > > added, only from being used, based on monitoring / non-op status > > > > > > > +1. > > > It means that the admin can add the host, but the host will not be > > > operational until we get a positive indication from the attestation > > > service. > > > > > +1 > > if we want to test attestation only once, every time before host moves to > > up. > > the right place for it, imo, is InitVdsOnUpCommand if its periodic > > also after host is up, then it should be somewhere in the monitoring > > code > > > > > > > > > > > > > > > > > > > > > Does that make sense? > > > > > Doron and Ofri, what did you have in mind for this feature? > > > > > > > > > > Regards, > > > > > Oved > > > > > > > > > >> > > > > >> Best Regards, > > > > >> Dave Chen > > > > >> > > > > >> > > > > >> -----Original Message----- > > > > >> From: Doron Fediuck [mailto:dfediuck at redhat.com] > > > > >> Sent: Wednesday, April 10, 2013 8:03 PM > > > > >> To: Ofri Masad > > > > >> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan > > > > >> Subject: Re: minutes for sync up on Open Attestation > > > > >> integration with oVirt in 4/9 > > > > >> > > > > >> > > > > >> > > > > >> ----- Original Message ----- > > > > >>> From: "Ofri Masad" > > > > >>> To: "Gang Wei" > > > > >>> Cc: "Wei D Chen" , "Buddy Cao" > > > > >>> , "Lijuan Zhang" > > > > >>> , "Doron Fediuck" > > > > >>> > > > > >>> Sent: Wednesday, April 10, 2013 2:23:57 PM > > > > >>> Subject: Re: minutes for sync up on Open Attestation > > > > >>> integration with oVirt in 4/9 > > > > >>> > > > > >>> Hi, > > > > >>> > > > > >>> answers inside the mail body. > > > > >>> > > > > >>> ----- Original Message ----- > > > > >>>> From: "Doron Fediuck" > > > > >>>> To: "Wei D Chen" > > > > >>>> Cc: "Gang Wei" , "Buddy Cao" > > > > >>>> , "Lijuan Zhang" > > > > >>>> , "Ofri Masad" > > > > >>>> Sent: Wednesday, April 10, 2013 12:12:26 PM > > > > >>>> Subject: Re: minutes for sync up on Open Attestation > > > > >>>> integration with oVirt in 4/9 > > > > >>>> > > > > >>>> Hi Dave, > > > > >>>> Adding Ofri to answer your questions. > > > > >>>> > > > > >>>> ----- Original Message ----- > > > > >>>>> From: "Wei D Chen" > > > > >>>>> To: "Gang Wei" , "Doron Fediuck" > > > > >>>>> , > > > > >>>>> "Buddy Cao" , "Lijuan Zhang" > > > > >>>>> > > > > >>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM > > > > >>>>> Subject: RE: minutes for sync up on Open Attestation > > > > >>>>> integration with oVirt in 4/9 > > > > >>>>> > > > > >>>>> Hi Doron, > > > > >>>>> > > > > >>>>> > > > > >>>>> iii. Then periodic trust check will be added into background > > > > >>>>> process > > > > >>>>> for > > > > >>>>> all existing hosts, once becoming non-trusted, mark it as > > > > >>>>> non-operational. > > > > >>>>> > > > > >>>>> - [Dave] Would you give me some details about the > > > > >>>>> ?background > > > > >>>>> process? mentioned in our sync up meeting? What?s the > > > > >>>>> process and where is related code? > > > > >>>>> > > > > >>> > > > > >>> The use Quartz Job to scheduled background processes. > > > > >>> An example can be found in: > > > > >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > > > > >>> 222) > > > > >>> > > > > >>> This code calls a method that is located in: > > > > >>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovi > > > > >>> rt /engin e/core/bll/quota/QuotaManager.java > > > > >>> (Line: 1000) > > > > >>> the @OnTimerMethodAnnotation annotation and the unique job > > > > >>> name connects the two in runtime. > > > > >>> > > > > >>> The job can query the attestation server for all the host and > > > > >>> then set untrusted hosts to Non-Operational. > > > > >>> the best way would be to call SetNonOperationalVdsCommand with > > > > >>> a new NonOperationalReason. > > > > >>> This command tries to migrate all VMs from the host and then > > > > >>> set it non operational. > > > > >>> (We need to think about non-migrational VMs - should we close > > > > >>> those VMs or keep the host running) > > > > >>> > > > > >> > > > > >> One more thing you may want to consider; If we get a positive > > > > >> response for a host which is currently non-operational, issue > > > > >> an activate command to try and make it operational again. > > > > >> Alternatively, you may decide not to handle it, assuming > > > > >> untrusted hosts can only be activated manually (see below > > > > >> Ofri's response on activating a host). > > > > >> > > > > >>>>> > > > > >>>>> iv. If admin fixed the non-operational node and try to switch > > > > >>>>> it > > > > >>>>> to > > > > >>>>> operational mode again, a trust check will happen to gate > > > > >>>>> the switching. > > > > >>>>> > > > > >>>>> - [Dave] If there is a button provided from UI for > > > > >>>>> checking > > > > >>>>> the > > > > >>>>> logic? or we need add an extra-button for attestation check only? > > > > >>>>> > > > > >>> > > > > >>> In the UI we already have the "Activate" option. What still > > > > >>> needs to be added is the check with the attestation provider > > > > >>> to make sure that if the cluster is defined 'Trusted'. If so, > > > > >>> only trusted host will succeed in the activate command (and, > > > > >>> of course, a proper Audit Log error in case the host failed to > > > > >>> activate due to trust issue. > > > > >>> > > > > >>> the correct place to add this check would be in: > > > > >>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/o > > > > >>> rg > > > > >>> /ovirt > > > > >>> /engine/core/vdsbroker/VdsManager.java:activate() > > > > >>> this is where the re-activation process begins. > > > > >>> > > > > >>>>> > > > > >>>>> Thanks very much. > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> Best Regards, > > > > >>>>> Dave Chen > > > > >> _______________________________________________ > > > > >> 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 > > > > > _______________________________________________ > > 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 Wed Apr 17 12:31:20 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 17 Apr 2013 15:31:20 +0300 Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: <1308686351.886592.1366183406691.JavaMail.root@redhat.com> References: <996306366.2192571.1365595398217.JavaMail.root@redhat.com> <189243164.4209095.1366006840007.JavaMail.root@redhat.com> <516BA2E8.7090207@redhat.com> <448237996.384685.1366009557875.JavaMail.root@redhat.com> <1045509486.480916.1366023642593.JavaMail.root@redhat.com> <1308686351.886592.1366183406691.JavaMail.root@redhat.com> Message-ID: <516E9618.7010406@redhat.com> On 04/17/2013 10:23 AM, Ofri Masad wrote: > Hi Dave, > The VdsUpdateRunTimeInfo runs every 3 seconds or so. so it not a good place to call the attestation host. > Instead, like we suggested earlier, create a new Quartz job (like the one I've sent you in the QuotaManager class) which run every couple of minutes and update the hosts state. > You can also add the check to InitVdsOnUpCommand, so that if a host was down for a different reason, it will be rechecked for attestation. > You can add a UI to allow manual "refresh attestation". > so the new thread will poll all for all hosts and update the db, then during the normal monitoring "detect" the issue? > Ofri > > ----- Original Message ----- >> From: "Wei D Chen" >> To: "Omer Frenkel" , "Doron Fediuck" >> Cc: "Oved Ourfalli" , engine-devel at ovirt.org >> Sent: Monday, April 15, 2013 5:53:34 PM >> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 >> >> Good approach, thanks all. How long it needs to invoke periodic check in the >> class of VdsUpdateRunTimeInfo? Whether this time configurable? My concern is >> if the initial status of each host added into trusted cluster is >> non-operational, we need wait a long time for the invoking of this periodic >> check, so a trusted host's with initial status of non-operational will take >> a long time to flip to a trusted host. >> >> As I have not seen the configuration of periodic check in >> VdsUpdateRunTimeInfo, would you give me some tips if you has some clue. >> Thanks a lot. >> >> Best Regards, >> Dave Chen >> >> -----Original Message----- >> From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] >> On Behalf Of Omer Frenkel >> Sent: Monday, April 15, 2013 7:01 PM >> To: Doron Fediuck >> Cc: Oved Ourfalli; engine-devel at ovirt.org >> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation >> integration with oVirt in 4/9 >> >> >> >> ----- Original Message ----- >>> From: "Doron Fediuck" >>> To: "Itamar Heim" >>> Cc: "Oved Ourfalli" , engine-devel at ovirt.org >>> Sent: Monday, April 15, 2013 10:05:57 AM >>> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation >>> integration with oVirt in 4/9 >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Itamar Heim" >>>> To: "Oved Ourfalli" >>>> Cc: engine-devel at ovirt.org >>>> Sent: Monday, April 15, 2013 9:49:12 AM >>>> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation >>>> integration with oVirt in 4/9 >>>> >>>> On 04/15/2013 09:20 AM, Oved Ourfalli wrote: >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Wei D Chen" >>>>>> To: "Doron Fediuck" , "Ofri Masad" >>>>>> >>>>>> Cc: engine-devel at ovirt.org >>>>>> Sent: Monday, April 15, 2013 8:54:18 AM >>>>>> Subject: Re: [Engine-devel] minutes for sync up on Open >>>>>> Attestation integration with oVirt in 4/9 >>>>>> >>>>>> Hi Doron and Ofri, >>>>>> >>>>>> Thanks for your reply, here is some other question. >>>>>> >>>>>> ii. When adding a host into the trusted cluster, the host will >>>>>> be attested via OAT service, only trusted hosted can be added. >>>>>> >>>>>> Would you also kindly tell me if there is any mandatory logic >>>>>> check when adding a host into a cluster, so we can also put >>>>>> attestation logic with these mandatory check together? Some example or >>>>>> code location is better. >>>>>> Thanks a lot. >>>>>> >>>>> >>>>> I think there are two approaches, depending on the use case. >>>>> #1: >>>>> If the host trusted property is static, then you can narrow the >>>>> tests to two locations: >>>>> * AddVdsCommand - (Vds = Host) - This command is triggered when a >>>>> new host is added to the system. You can use the canDoAction >>>>> method (which we have on all commands, and it determines whether >>>>> an action can be run or not), and there, if cluster requires >>>>> trusted hosts only, you can test whether this host is trusted or >>>>> not. >>>>> * ChangeVdsClusterCommand - this command is used when you change >>>>> the cluster of a host. So, if the target cluster requires tursted >>>>> hosts, you can do a similar test in its canDoAction method. >>>>> >>>>> #2: >>>>> If the host trusted property can change, then I'd suggest using >>>>> the NonOperational property of a host. >>>>> We have a class called VdsUpdateRunTimeInfo that does periodic >>>>> tests of hosts, deciding what's their status, according to specific >>>>> flags. >>>>> The code there is quite complex, and would require refactoring at >>>>> some point, but in the meantime you can use the MonitoringStrategy >>>>> interface that is being used there, and implement a new monitoring >>>>> strategy for Open Attestation. >>>>> >>>>> There, in the processHardwareCapabilities, you can test that the >>>>> host is trusted. >>>>> >>>>> When creating the strategy, using the MonitoringStrategyFactory, >>>>> you'll need to create the appropriate strategy. >>>>> Currently we support either virt strategy or gluster strategy or >>>>> both. In your case you would need virt+attestation / >>>>> gluster+attestation / >>>>> virt+gluster+attestation, according to the services deployed on >>>>> virt+gluster+the >>>>> cluster. >>>> >>>> I'd go with the 2nd approach. i.e., not block the host from being >>>> added, only from being used, based on monitoring / non-op status >>>> >>> +1. >>> It means that the admin can add the host, but the host will not be >>> operational until we get a positive indication from the attestation >>> service. >>> >> +1 >> if we want to test attestation only once, every time before host moves to up. >> the right place for it, imo, is InitVdsOnUpCommand if its periodic also after >> host is up, then it should be somewhere in the monitoring code >> >>>> >>>>> >>>>> >>>>> Does that make sense? >>>>> Doron and Ofri, what did you have in mind for this feature? >>>>> >>>>> Regards, >>>>> Oved >>>>> >>>>>> >>>>>> Best Regards, >>>>>> Dave Chen >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Doron Fediuck [mailto:dfediuck at redhat.com] >>>>>> Sent: Wednesday, April 10, 2013 8:03 PM >>>>>> To: Ofri Masad >>>>>> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan >>>>>> Subject: Re: minutes for sync up on Open Attestation integration >>>>>> with oVirt in 4/9 >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Ofri Masad" >>>>>>> To: "Gang Wei" >>>>>>> Cc: "Wei D Chen" , "Buddy Cao" >>>>>>> , "Lijuan Zhang" , >>>>>>> "Doron Fediuck" >>>>>>> Sent: Wednesday, April 10, 2013 2:23:57 PM >>>>>>> Subject: Re: minutes for sync up on Open Attestation integration >>>>>>> with oVirt in 4/9 >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> answers inside the mail body. >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Doron Fediuck" >>>>>>>> To: "Wei D Chen" >>>>>>>> Cc: "Gang Wei" , "Buddy Cao" >>>>>>>> , "Lijuan Zhang" , >>>>>>>> "Ofri Masad" >>>>>>>> Sent: Wednesday, April 10, 2013 12:12:26 PM >>>>>>>> Subject: Re: minutes for sync up on Open Attestation >>>>>>>> integration with oVirt in 4/9 >>>>>>>> >>>>>>>> Hi Dave, >>>>>>>> Adding Ofri to answer your questions. >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Wei D Chen" >>>>>>>>> To: "Gang Wei" , "Doron Fediuck" >>>>>>>>> , >>>>>>>>> "Buddy Cao" , "Lijuan Zhang" >>>>>>>>> >>>>>>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM >>>>>>>>> Subject: RE: minutes for sync up on Open Attestation >>>>>>>>> integration with oVirt in 4/9 >>>>>>>>> >>>>>>>>> Hi Doron, >>>>>>>>> >>>>>>>>> >>>>>>>>> iii. Then periodic trust check will be added into background >>>>>>>>> process >>>>>>>>> for >>>>>>>>> all existing hosts, once becoming non-trusted, mark it as >>>>>>>>> non-operational. >>>>>>>>> >>>>>>>>> - [Dave] Would you give me some details about the >>>>>>>>> ?background >>>>>>>>> process? mentioned in our sync up meeting? What?s the process >>>>>>>>> and where is related code? >>>>>>>>> >>>>>>> >>>>>>> The use Quartz Job to scheduled background processes. >>>>>>> An example can be found in: >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: >>>>>>> 222) >>>>>>> >>>>>>> This code calls a method that is located in: >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt >>>>>>> /engin e/core/bll/quota/QuotaManager.java >>>>>>> (Line: 1000) >>>>>>> the @OnTimerMethodAnnotation annotation and the unique job name >>>>>>> connects the two in runtime. >>>>>>> >>>>>>> The job can query the attestation server for all the host and >>>>>>> then set untrusted hosts to Non-Operational. >>>>>>> the best way would be to call SetNonOperationalVdsCommand with a >>>>>>> new NonOperationalReason. >>>>>>> This command tries to migrate all VMs from the host and then set >>>>>>> it non operational. >>>>>>> (We need to think about non-migrational VMs - should we close >>>>>>> those VMs or keep the host running) >>>>>>> >>>>>> >>>>>> One more thing you may want to consider; If we get a positive >>>>>> response for a host which is currently non-operational, issue an >>>>>> activate command to try and make it operational again. >>>>>> Alternatively, you may decide not to handle it, assuming >>>>>> untrusted hosts can only be activated manually (see below Ofri's >>>>>> response on activating a host). >>>>>> >>>>>>>>> >>>>>>>>> iv. If admin fixed the non-operational node and try to switch >>>>>>>>> it >>>>>>>>> to >>>>>>>>> operational mode again, a trust check will happen to gate the >>>>>>>>> switching. >>>>>>>>> >>>>>>>>> - [Dave] If there is a button provided from UI for >>>>>>>>> checking >>>>>>>>> the >>>>>>>>> logic? or we need add an extra-button for attestation check only? >>>>>>>>> >>>>>>> >>>>>>> In the UI we already have the "Activate" option. What still >>>>>>> needs to be added is the check with the attestation provider to >>>>>>> make sure that if the cluster is defined 'Trusted'. If so, only >>>>>>> trusted host will succeed in the activate command (and, of >>>>>>> course, a proper Audit Log error in case the host failed to activate >>>>>>> due to trust issue. >>>>>>> >>>>>>> the correct place to add this check would be in: >>>>>>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/org >>>>>>> /ovirt >>>>>>> /engine/core/vdsbroker/VdsManager.java:activate() >>>>>>> this is where the re-activation process begins. >>>>>>> >>>>>>>>> >>>>>>>>> Thanks very much. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Dave Chen >>>>>> _______________________________________________ >>>>>> 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 >>> >> _______________________________________________ >> 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 cfergeau at redhat.com Wed Apr 17 12:45:45 2013 From: cfergeau at redhat.com (Christophe Fergeau) Date: Wed, 17 Apr 2013 14:45:45 +0200 Subject: [Engine-devel] spice-xpi(firefox) plugin for Windows Message-ID: <20130417124545.GB13447@teriyaki.redhat.com> Hi everyone, Lately I've been hacking on getting the spice-xpi plugin to work on Windows. This is the Firefox plugin that is used on Linux to implement the portal SPICE console. This work has now been merged upstream ( http://cgit.freedesktop.org/spice/spice-xpi/ ), and I've pushed a scratch build using mingw available from http://koji.fedoraproject.org/koji/taskinfo?taskID=5265107 (this will go away in several days). Copying this dll + its dependencies to the C:\Program Files\Mozilla Firefox\plugins directory are enough to get a spice-xpi plugin to show up in about:plugins, and to then be able to start a SPICE client from the spice-xpi test page ( http://teuf.fedorapeople.org/plugins/test.html ). The dependencies I had to copy are: gspawn-win32-helper-console.exe gspawn-win32-helper.exe iconv.dll libffi-6.dll libgcc_s_sjlj-1.dll libgio-2.0-0.dll libglib-2.0-0.dll libgmodule-2.0-0.dll libgobject-2.0-0.dll libgthread-2.0-0.dll libintl-8.dll libstdc++-6.dll pthreadGC2.dll zlib1.dll (I picked them from the various mingw-* fedora packages). The reason for this email is that to be usable from oVirt, some portal changes are needed as it currently only tries to use the spice-xpi plugin on Linux platforms. Another fuzzy bit is how to get this plugin to the users' machines... And that's about all I had to say in that email ;) Let me know if that's useful to oVirt, how you want to integrate this, ... Cheers, Christophe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From vszocs at redhat.com Wed Apr 17 12:46:35 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Wed, 17 Apr 2013 08:46:35 -0400 (EDT) Subject: [Engine-devel] Proposal to make REST API more webapp-friendly In-Reply-To: <516E71DB.1010801@redhat.com> References: <2140658645.762187.1366023864071.JavaMail.root@redhat.com> <815104772.15680618.1366189992223.JavaMail.root@redhat.com> <516E71DB.1010801@redhat.com> Message-ID: <203480990.2046113.1366202795540.JavaMail.root@redhat.com> Hi Michael, thanks for your feedback. >>> * cookie parsing/formatting is not trivial >>> --> extra complexity imposed on REST clients > > i wouldn't call it a cookie blocker, as in most cases (including ours) cookie contains > restricted amount of records. I agree, this isn't strictly a blocker issue. It's the other issues (Cross-Site Request Forgery vulnerability, limited cookie access from JavaScript) that make cookies hard to work with. >>> * cookies are the primary source of Cross-Site Request Forgery >>> [http://en.wikipedia.org/wiki/Cross-site_request_forgery] attacks >>> --> malicious websites/scripts can forge requests to REST API that will >>> include the cookie, compromising user session > > same true for the authorization header, session being passed via HTTP headers That's correct. Once set (either via browser-specific popup, or via JavaScript AJAX request) the browser will always include HTTP Authorization header for all requests to given location, AFAIK. The only way to prevent browser from including HTTP Authorization header for all requests to given location, is to simply close the browser window. Important thing is that HTTP Basic Auth is vulnerable to CSRF mainly because of an easy way to "replay" attacks. This is why I think REST API authentication should be protected against "replay" attacks. >> We currently return the JSESSIONID also using HTTP headers. We currently return the jsession id also as part of the response HTTP headers, but the client still needs to pass a cookie with the appropriate value in order for the REST session to work. Isn't that enough to cope with this issue? > > api, can consume JSESSIONID from the header indeed, but my problem with this approach > is a persistence of the http headers in browsers. Persistence of such JSESSIONID information isn't really a problem :) we can use HTML5 web storage API, e.g. session storage, to securely persist such information on client (or we can use a special cookie for this, scoped to WebAdmin path, *not* REST API path). WebAdmin can simply mimic the cookie-handling behavior in browsers, i.e. send JSESSIONID header (instead of cookie) for each REST API request. >>> HTTP Basic Auth [http://en.wikipedia.org/wiki/Basic_access_authentication] >>> over (non-secure) HTTP connection means sending user credentials >>> (username/password/domain) in easy-to-decode cleartext, i.e. the value is >>> *not* encrypted or hashed in any way. Using secure lower-level protocol >>> (SSL) fixes the consequence, rather than the root cause of the >>> confidentiality issue. > > same is true for any sensitive date being passed via plain text (including cookies) That's correct. The solution mentioned in my original email was to hash sensitive data with some sort of private key (password?) to make it harder to sniff sensitive data. >>> Furthermore, browsers typically remember HTTP Basic Auth information (either >>> via browser-specific popup, or via XmlHttpRequest) until the browser window >>> is closed. This means the webapp has no control over HTTP Basic Auth header >>> after it has been set! This is the reason why it's hard to implement >>> "logout" functionality in webapps when using HTTP Basic Auth. > > right, that is my concern of using headers as well, better solution may be sending > JSESSION id via URI matrix parameter, e.g /api/vms;sessionid=xxx Yes, this is possible. But maybe from REST API design perspective, isn't using some (custom) authentication header more clean approach? >>> I've just read an excellent article at >>> [http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/] >>> which describes easy yet secure authentication scheme inspired by Amazon Web >>> Services REST API authentication >>> [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html]. >>> The idea is simple: collect auth information, hash (sign) it with a private >>> key, and send everything to server. To guard against Replay attacks, just >>> provide some timestamp to enforce request expiry after some time (say, 5-15 >>> minutes). Easy and simple! > > 1. this concept has very same drawbacks as any other content encryption I assume their goal was to implement easy yet secure-enough authentication scheme for public API (secure from malicious exploit perspective, not necessarily content encryption perspective). The point was to use private key that's only known to client and server, and nobody else. You hash sensitive data with private key and provide this hash as extra request attribute. The server just does the same thing as client and compares the hash. > 2. decoding time stamp from request/s will produce fair load for the server as well > and won't protect the server against DDOS, also it shouldn't as it's not api/webapp > prerogative. Timestamp processing depends on implementation efficiency, but yeah you are right, it will increase the processing load in general. Regarding DDOS, well, this is another story :) > in general what Vojtech is trying to achieve is passing session via some other > container than cookie as webapp/browsers can't omit auth. header in runtime, Exactly. > what is only justifying my resistance of passing session id via http header, > i think using matrix parameter (as mentioned above) may give you a decent solution. The matrix parameter proposal is also OK for me, even though personaly I'm more in favor of using custom HTTP request/response (e.g. "JSESSIONID") header for this purpose. But it doesn't really matter, for the purpose of transmitting session ID value, anything other than cookie is always better than cookie, from JavaScript perspective. Vojtech ----- Original Message ----- From: "Michael Pasternak" To: "Oved Ourfalli" Cc: "Vojtech Szocs" , "engine-devel" , "Juan Hernandez" Sent: Wednesday, April 17, 2013 11:56:43 AM Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly Hi Vojtech/Oved, On 04/17/2013 12:13 PM, Oved Ourfalli wrote: > > > ----- Original Message ----- >> From: "Vojtech Szocs" >> To: "engine-devel" >> Sent: Monday, April 15, 2013 2:04:24 PM >> Subject: [Engine-devel] Proposal to make REST API more webapp-friendly >> >> Hi guys, >> >> having worked with Engine REST API from web application (JavaScript) >> perspective, there are things that could be improved to make REST API more >> webapp-friendly. >> >> First of all, webapps are *not* traditional HTTP clients, i.e. they have >> *not* full control over HTTP processing. There are some standard conventions >> and behaviors built into web browsers that any REST API implementation >> should be aware of. >> >> -- >> >> (1) Don't force clients to use cookies for transmitting authentication >> information! (or don't use cookies at all) >> >> Good explanation can be found at >> [http://www.berenddeboer.net/rest/cookies.html]. Cookies have many >> disadvantages: >> >> * cookie parsing/formatting is not trivial >> --> extra complexity imposed on REST clients i wouldn't call it a cookie blocker, as in most cases (including ours) cookie contains restricted amount of records. >> >> * in addition to Same-Origin Policy >> [http://en.wikipedia.org/wiki/Same_origin_policy], cookies can be get/set >> *only* for the given path >> --> JavaScript running at [http://example.com/webapp] *cannot* get/set >> cookies from requests at [http://example.com/restapi] >> >> * cookies are the primary source of Cross-Site Request Forgery >> [http://en.wikipedia.org/wiki/Cross-site_request_forgery] attacks >> --> malicious websites/scripts can forge requests to REST API that will >> include the cookie, compromising user session same true for the authorization header, session being passed via HTTP headers >> >> Alternative: clients could be given the *option* to use regular HTTP header >> for transmitting authentication information. >> >> For example, webapp could read such (sensitive information) header, store it >> securely via HTML5 Session Storage >> [http://en.wikipedia.org/wiki/Web_storage] and implement related HTTP >> processing on its own, e.g. pass this header for all authenticated requests >> (instead of pushing this responsibility to browser). >> > > Option #1: > We currently return the JSESSIONID also using HTTP headers. We currently return the jsession id also as part of the response HTTP headers, but the client still needs to pass a cookie with the appropriate value in order for the REST session to work. Isn't that enough to cope with this issue? api, can consume JSESSIONID from the header indeed, but my problem with this approach is a persistence of the http headers in browsers. > > If not, then we might be able to do option #2: > Today, we keep the engine session ID on the HTTP session attributes. > So, we can support either passing the cookie with the JSESSIONID (taking the engine session ID from the http session), or passing the engine session ID as HTTP header (assuming we would also return the engine session ID upon first REST request). > > This approach is problematic, as it might work well now, when the only attribute we use is the engine session ID, but in the future that might not be the case. > If it is important enough (i.e., you can't really work with option #1) , then we can make a decision to save the attributes on the engine session, rather than on the HTTP session. > So, we would start by supporting them both together, adding new attributes only to the engine session, and in the future deprecating the use of cookies, and only supporting HTTP headers. > > cc-ed Juan and Michael, as they might have some input on that. > > >> -- >> >> (2) Straight-forward HTTP Basic Auth has some drawbacks! >> >> HTTP Basic Auth [http://en.wikipedia.org/wiki/Basic_access_authentication] >> over (non-secure) HTTP connection means sending user credentials >> (username/password/domain) in easy-to-decode cleartext, i.e. the value is >> *not* encrypted or hashed in any way. Using secure lower-level protocol >> (SSL) fixes the consequence, rather than the root cause of the >> confidentiality issue. same is true for any sensitive date being passed via plain text (including cookies) >> >> Furthermore, browsers typically remember HTTP Basic Auth information (either >> via browser-specific popup, or via XmlHttpRequest) until the browser window >> is closed. This means the webapp has no control over HTTP Basic Auth header >> after it has been set! This is the reason why it's hard to implement >> "logout" functionality in webapps when using HTTP Basic Auth. right, that is my concern of using headers as well, better solution may be sending JSESSION id via URI matrix parameter, e.g /api/vms;sessionid=xxx >> >> Last but not least, HTTP Basic Auth is vulnerable to Replay attacks >> [http://en.wikipedia.org/wiki/Replay_attack]. Someone between client and >> server can intercept requests and replay them, compromising user session. >> >> Alternative: clients could be given the *option* to use more advanced >> authentication scheme. >> >> I've just read an excellent article at >> [http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/] >> which describes easy yet secure authentication scheme inspired by Amazon Web >> Services REST API authentication >> [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html]. >> The idea is simple: collect auth information, hash (sign) it with a private >> key, and send everything to server. To guard against Replay attacks, just >> provide some timestamp to enforce request expiry after some time (say, 5-15 >> minutes). Easy and simple! 1. this concept has very same drawbacks as any other content encryption 2. decoding time stamp from request/s will produce fair load for the server as well and won't protect the server against DDOS, also it shouldn't as it's not api/webapp prerogative. in general what Vojtech is trying to achieve is passing session via some other container than cookie as webapp/browsers can't omit auth. header in runtime, what is only justifying my resistance of passing session id via http header, i think using matrix parameter (as mentioned above) may give you a decent solution. >> >> -- >> >> (3) Support JSON for resource representations! >> >> I think this is pretty much obvious. XML has no real advantages over JSON. >> JSON, on the other hand, has good support in webapps (JavaScript) and maps >> directly to common data structures (i.e. string, number, boolean, and so >> on). >> >> From webapp perspective, it's much easier and natural to use JSON than to >> parse/format XML documents. >> >> Alternative: clients could be given the *option* to use JSON, in addition to >> XML representation. not sure how it's related, but we plan supporting JSON in future. >> >> -- >> >> Vojtech >> _______________________________________________ >> 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 avishwan at redhat.com Wed Apr 17 12:49:13 2013 From: avishwan at redhat.com (Aravinda) Date: Wed, 17 Apr 2013 18:19:13 +0530 Subject: [Engine-devel] [vdsm] Adding vdsm_api support for gluster vdsm verbs In-Reply-To: <516D0F2D.8000100@redhat.com> References: <516BDA06.5080101@redhat.com> <516D0E85.1070407@redhat.com> <516D0F2D.8000100@redhat.com> Message-ID: <516E9A49.8070406@redhat.com> [Adding Saggi, Adam, Dan, Sahina] On 04/16/2013 02:13 PM, Aravinda wrote: > [Adding engine-devel] > > On 04/16/2013 02:10 PM, Aravinda wrote: >> >> vdsm/gluster is vdsm plugin for gluster related functionality. These >> functionalities are available only when vdsm-gluster package is >> installed. So the schema JSON of vdsm-gluster cannot be added to the >> same file(vdsm_api/vdsmapi-schema.json) >> >> Looks like vdsm_api is not providing plugin support. This patch adds >> functionality to vdsm_api to read vdsmapi-gluster-schema.json if >> available. But with this approach we need to edit the core vdsmapi.py >> file. >> >> http://gerrit.ovirt.org/#/c/13921/ >> >> Alternate approach: >> We can have "vdsm_api/plugins" or "vdsm_api/schema" directory inside >> vdsm_api, so that we can modify vdsmapi.py to read all schema files >> from that dir. When vdsm-gluster package installed, it copies >> vdsmapi-gluster-schema.json into schema directory. >> >> >> -- >> regards >> Aravinda >> >> >> On 04/15/2013 04:14 PM, Aravinda wrote: >>> Hi, >>> >>> We are trying to add json rpc support for vdsm gluster verbs. I >>> submitted a patch to read gluster verbs schema from vdsm/gluster >>> directory. >>> http://gerrit.ovirt.org/#/c/13921/ >>> >>> Let me know if the approach is fine. >>> >>> -- >>> regards >>> Aravinda >>> _______________________________________________ >>> vdsm-devel mailing list >>> vdsm-devel at lists.fedorahosted.org >>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel >> >> _______________________________________________ >> vdsm-devel mailing list >> vdsm-devel at lists.fedorahosted.org >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From vszocs at redhat.com Wed Apr 17 13:08:31 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Wed, 17 Apr 2013 09:08:31 -0400 (EDT) Subject: [Engine-devel] Proposal to make REST API more webapp-friendly In-Reply-To: <1616192035.15952873.1366194549669.JavaMail.root@redhat.com> References: <2140658645.762187.1366023864071.JavaMail.root@redhat.com> <815104772.15680618.1366189992223.JavaMail.root@redhat.com> <697492056.2007786.1366194306086.JavaMail.root@redhat.com> <1616192035.15952873.1366194549669.JavaMail.root@redhat.com> Message-ID: <431498683.2053791.1366204111100.JavaMail.root@redhat.com> Hi Oved, >> The only difference would be, when REST API receives the request, it looks >> for "Prefer:use-jsessionid-header", and if it's present, it uses >> "JSESSIONID" header value to look up HttpSession in some way (not sure about >> implementation details, though, but this should be possible to do). >> >> So, what do you think? >> > As far as I saw, the handling of the cookie is done before the REST code, and that's why we need the cookie. > Perhaps there is a way to make jboss take the JSESSIONID from the HTTP header, and not the cookie, but I didn't find a way to do that yet. I'm also not sure about this, so far I've only found: http://stackoverflow.com/questions/5807664/tomcat-how-to-access-session-manager-from-servlet It seems that the solution is to either provide custom session manager implementation in JBoss, or to obtain standard session manager early when processing request and create session manually there. Vojtech ----- Original Message ----- From: "Oved Ourfalli" To: "Vojtech Szocs" Cc: "Juan Hernandez" , "engine-devel" Sent: Wednesday, April 17, 2013 12:29:09 PM Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly ----- Original Message ----- > From: "Vojtech Szocs" > To: "Oved Ourfalli" > Cc: "Juan Hernandez" , "engine-devel" > Sent: Wednesday, April 17, 2013 1:25:06 PM > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > Hi Oved, thanks for your feedback! > > > We currently return the JSESSIONID also using HTTP headers. We currently > > return the jsession id also as part of the response HTTP headers, but the > > client still needs to pass a cookie with the appropriate value in order > > for the REST session to work. Isn't that enough to cope with this issue? > > Right, currently REST API responds with JSESSIONID cookie + separate > JSESSIONID response header, both carrying session ID value. > > As I wrote in my original email: JavaScript running at > [http://example.com/webapp] *cannot* get/set cookies from requests at > [http://example.com/restapi] > > So WebAdmin cannot get/set REST API JSESSIONID cookie directly, which is why > it uses separate JSESSIONID response header in order to *read* the session > ID value. As for sending JSESSIONID cookie, WebAdmin currently relies on > standard cookie-handling implemented in browsers: all cookies for location X > [http://example.com/restapi] will be part of any request to location X. So > it's the browser who sets JSESSIONID cookie for REST API request, not > WebAdmin. > > To answer your question, currently it's enough to work around the cookie > access limitation, but it's not good enough in my opinion (from > JavaScript/webapp perspective).. > > > If not, then we might be able to do option #2: > > Today, we keep the engine session ID on the HTTP session attributes. > > So, we can support either passing the cookie with the JSESSIONID (taking > > the engine session ID from the http session), or passing the engine > > session ID as HTTP header (assuming we would also return the engine > > session ID upon first REST request). > > Well, the problem I described only relates to the way how JSESSIONID value is > transmitted between client and server: currently using cookies, so REST API > client has to do cookie handling. > > It would be really great if I could tell REST API to use plain (i.e. *not* > Set-Cookie & Cookie) HTTP header, for example "JSESSIONID", for the purpose > of transmitting session ID value between client and server. > > For example, the request to acquire session would be: > > GET /api HTTP/1.1 > Host: www.example.org > Prefer: use-jsessionid-header > JSESSIONID: xxx > > [Feel free to replace "use-jsessionid-header" with anything you like. If > client doesn't specify "use-jsessionid-header", server expects "Cookie" > header by default to preserve compatibility.] > > And the response would be: > > HTTP/1.1 200 OK > JSESSIONID: xxx > > [If client didn't specify "use-jsessionid-header", server would use > "Set-Cookie" header by default to preserve compatibility.] > > > This approach is problematic, as it might work well now, when the only > > attribute we use is the engine session ID, but in the future that might > > not be the case. > > If it is important enough (i.e., you can't really work with option #1) , > > then we can make a decision to save the attributes on the engine session, > > rather than on the HTTP session. > > So, we would start by supporting them both together, adding new attributes > > only to the engine session, and in the future deprecating the use of > > cookies, and only supporting HTTP headers. > > I think you can keep the current implementation, i.e. use REST API > HttpSession to store Engine session ID value. > > The only difference would be, when REST API receives the request, it looks > for "Prefer:use-jsessionid-header", and if it's present, it uses > "JSESSIONID" header value to look up HttpSession in some way (not sure about > implementation details, though, but this should be possible to do). > > So, what do you think? > As far as I saw, the handling of the cookie is done before the REST code, and that's why we need the cookie. Perhaps there is a way to make jboss take the JSESSIONID from the HTTP header, and not the cookie, but I didn't find a way to do that yet. > Vojtech > > > ----- Original Message ----- > From: "Oved Ourfalli" > To: "Vojtech Szocs" > Cc: "engine-devel" , "Juan Hernandez" > , "Michael Pasternak" > Sent: Wednesday, April 17, 2013 11:13:12 AM > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > ----- Original Message ----- > > From: "Vojtech Szocs" > > To: "engine-devel" > > Sent: Monday, April 15, 2013 2:04:24 PM > > Subject: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > Hi guys, > > > > having worked with Engine REST API from web application (JavaScript) > > perspective, there are things that could be improved to make REST API more > > webapp-friendly. > > > > First of all, webapps are *not* traditional HTTP clients, i.e. they have > > *not* full control over HTTP processing. There are some standard > > conventions > > and behaviors built into web browsers that any REST API implementation > > should be aware of. > > > > -- > > > > (1) Don't force clients to use cookies for transmitting authentication > > information! (or don't use cookies at all) > > > > Good explanation can be found at > > [http://www.berenddeboer.net/rest/cookies.html]. Cookies have many > > disadvantages: > > > > * cookie parsing/formatting is not trivial > > --> extra complexity imposed on REST clients > > > > * in addition to Same-Origin Policy > > [http://en.wikipedia.org/wiki/Same_origin_policy], cookies can be get/set > > *only* for the given path > > --> JavaScript running at [http://example.com/webapp] *cannot* get/set > > cookies from requests at [http://example.com/restapi] > > > > * cookies are the primary source of Cross-Site Request Forgery > > [http://en.wikipedia.org/wiki/Cross-site_request_forgery] attacks > > --> malicious websites/scripts can forge requests to REST API that will > > include the cookie, compromising user session > > > > Alternative: clients could be given the *option* to use regular HTTP header > > for transmitting authentication information. > > > > For example, webapp could read such (sensitive information) header, store > > it > > securely via HTML5 Session Storage > > [http://en.wikipedia.org/wiki/Web_storage] and implement related HTTP > > processing on its own, e.g. pass this header for all authenticated requests > > (instead of pushing this responsibility to browser). > > > > Option #1: > We currently return the JSESSIONID also using HTTP headers. We currently > return the jsession id also as part of the response HTTP headers, but the > client still needs to pass a cookie with the appropriate value in order for > the REST session to work. Isn't that enough to cope with this issue? > > If not, then we might be able to do option #2: > Today, we keep the engine session ID on the HTTP session attributes. > So, we can support either passing the cookie with the JSESSIONID (taking the > engine session ID from the http session), or passing the engine session ID > as HTTP header (assuming we would also return the engine session ID upon > first REST request). > > This approach is problematic, as it might work well now, when the only > attribute we use is the engine session ID, but in the future that might not > be the case. > If it is important enough (i.e., you can't really work with option #1) , then > we can make a decision to save the attributes on the engine session, rather > than on the HTTP session. > So, we would start by supporting them both together, adding new attributes > only to the engine session, and in the future deprecating the use of > cookies, and only supporting HTTP headers. > > cc-ed Juan and Michael, as they might have some input on that. > > > > -- > > > > (2) Straight-forward HTTP Basic Auth has some drawbacks! > > > > HTTP Basic Auth [http://en.wikipedia.org/wiki/Basic_access_authentication] > > over (non-secure) HTTP connection means sending user credentials > > (username/password/domain) in easy-to-decode cleartext, i.e. the value is > > *not* encrypted or hashed in any way. Using secure lower-level protocol > > (SSL) fixes the consequence, rather than the root cause of the > > confidentiality issue. > > > > Furthermore, browsers typically remember HTTP Basic Auth information > > (either > > via browser-specific popup, or via XmlHttpRequest) until the browser window > > is closed. This means the webapp has no control over HTTP Basic Auth header > > after it has been set! This is the reason why it's hard to implement > > "logout" functionality in webapps when using HTTP Basic Auth. > > > > Last but not least, HTTP Basic Auth is vulnerable to Replay attacks > > [http://en.wikipedia.org/wiki/Replay_attack]. Someone between client and > > server can intercept requests and replay them, compromising user session. > > > > Alternative: clients could be given the *option* to use more advanced > > authentication scheme. > > > > I've just read an excellent article at > > [http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/] > > which describes easy yet secure authentication scheme inspired by Amazon > > Web > > Services REST API authentication > > [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html]. > > The idea is simple: collect auth information, hash (sign) it with a private > > key, and send everything to server. To guard against Replay attacks, just > > provide some timestamp to enforce request expiry after some time (say, 5-15 > > minutes). Easy and simple! > > > > -- > > > > (3) Support JSON for resource representations! > > > > I think this is pretty much obvious. XML has no real advantages over JSON. > > JSON, on the other hand, has good support in webapps (JavaScript) and maps > > directly to common data structures (i.e. string, number, boolean, and so > > on). > > > > From webapp perspective, it's much easier and natural to use JSON than to > > parse/format XML documents. > > > > Alternative: clients could be given the *option* to use JSON, in addition > > to > > XML representation. > > > > -- > > > > Vojtech > > _______________________________________________ > > 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 smizrahi at redhat.com Wed Apr 17 13:15:28 2013 From: smizrahi at redhat.com (Saggi Mizrahi) Date: Wed, 17 Apr 2013 09:15:28 -0400 (EDT) Subject: [Engine-devel] [vdsm] Adding vdsm_api support for gluster vdsm verbs In-Reply-To: <516E9A49.8070406@redhat.com> References: <516BDA06.5080101@redhat.com> <516D0E85.1070407@redhat.com> <516D0F2D.8000100@redhat.com> <516E9A49.8070406@redhat.com> Message-ID: <667812921.2055958.1366204528641.JavaMail.root@redhat.com> This is very Gluster specific but I guess it's OK until I get some time to make things a bit more generic over there. ----- Original Message ----- > From: "Aravinda" > To: vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org, "Saggi Mizrahi" , agl at us.ibm.com > Cc: "Dan Kenigsberg" , "Sahina Bose" > Sent: Wednesday, April 17, 2013 3:49:13 PM > Subject: Re: [Engine-devel] [vdsm] Adding vdsm_api support for gluster vdsm verbs > > [Adding Saggi, Adam, Dan, Sahina] > > On 04/16/2013 02:13 PM, Aravinda wrote: > > [Adding engine-devel] > > > > On 04/16/2013 02:10 PM, Aravinda wrote: > >> > >> vdsm/gluster is vdsm plugin for gluster related functionality. These > >> functionalities are available only when vdsm-gluster package is > >> installed. So the schema JSON of vdsm-gluster cannot be added to the > >> same file(vdsm_api/vdsmapi-schema.json) > >> > >> Looks like vdsm_api is not providing plugin support. This patch adds > >> functionality to vdsm_api to read vdsmapi-gluster-schema.json if > >> available. But with this approach we need to edit the core vdsmapi.py > >> file. > >> > >> http://gerrit.ovirt.org/#/c/13921/ > >> > >> Alternate approach: > >> We can have "vdsm_api/plugins" or "vdsm_api/schema" directory inside > >> vdsm_api, so that we can modify vdsmapi.py to read all schema files > >> from that dir. When vdsm-gluster package installed, it copies > >> vdsmapi-gluster-schema.json into schema directory. > >> > >> > >> -- > >> regards > >> Aravinda > >> > >> > >> On 04/15/2013 04:14 PM, Aravinda wrote: > >>> Hi, > >>> > >>> We are trying to add json rpc support for vdsm gluster verbs. I > >>> submitted a patch to read gluster verbs schema from vdsm/gluster > >>> directory. > >>> http://gerrit.ovirt.org/#/c/13921/ > >>> > >>> Let me know if the approach is fine. > >>> > >>> -- > >>> regards > >>> Aravinda > >>> _______________________________________________ > >>> vdsm-devel mailing list > >>> vdsm-devel at lists.fedorahosted.org > >>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > >> > >> _______________________________________________ > >> vdsm-devel mailing list > >> vdsm-devel at lists.fedorahosted.org > >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From liqiang.net at gmail.com Wed Apr 17 13:27:25 2013 From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=) Date: Wed, 17 Apr 2013 21:27:25 +0800 Subject: [Engine-devel] How get all language WebAdm ? Message-ID: HI?All I install ovirt engine and open IE9 to manage. But I select Chinese language UI to display and failed. The UI's language always is Englisth and covers to Other language failed. OS:federa 18. Ovirt-Engine:3.2 MEM Size:4G DIsk:60G CPU:intel i7 Manage OS:Win7 Sp1 Manage IE:9 Can you help me? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From omasad at redhat.com Wed Apr 17 14:08:27 2013 From: omasad at redhat.com (Ofri Masad) Date: Wed, 17 Apr 2013 10:08:27 -0400 (EDT) Subject: [Engine-devel] How get all language WebAdm ? In-Reply-To: References: Message-ID: <2136897199.979258.1366207707972.JavaMail.root@redhat.com> Hi, are you talking about the rpm or a compiled version? Ofri ----- Original Message ----- > From: "??" > To: engine-devel at ovirt.org > Sent: Wednesday, April 17, 2013 4:27:25 PM > Subject: [Engine-devel] How get all language WebAdm ? > > > HI?All > > I install ovirt engine and open IE9 to manage. > But I select Chinese language UI to display and failed. > The UI's language always is Englisth and covers to Other language failed. > > OS:federa 18. > Ovirt-Engine:3.2 > MEM Size:4G > DIsk:60G > CPU:intel i7 > > Manage OS:Win7 Sp1 > Manage IE:9 > > Can you help me? > Thanks, > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From awels at redhat.com Wed Apr 17 13:40:09 2013 From: awels at redhat.com (Alexander Wels) Date: Wed, 17 Apr 2013 09:40:09 -0400 Subject: [Engine-devel] How get all language WebAdm ? In-Reply-To: References: Message-ID: <4952460.MNzll7zG6g@awels> You need to compile GWT with the appropriate language profile. If you want to compile with all languages make sure to include the all-langs profile in your maven build command. for instance: mvn clean install -Pdep,gwt-user,gwt-admin,all-langs Be aware that compiling all languages will take a long time ~30 minutes on my machine. You can specify particular languages to cut down on compile time. Alexander On Wednesday, April 17, 2013 09:27:25 PM ?? wrote: HI?All I install ovirt engine and open IE9 to manage. But I select Chinese language UI to display and failed. The UI's language always is Englisth and covers to Other language failed. OS:federa 18. Ovirt-Engine:3.2 MEM Size:4G DIsk:60G CPU:intel i7 Manage OS:Win7 Sp1 Manage IE:9 Can you help me? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From liqiang.net at gmail.com Wed Apr 17 15:26:54 2013 From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=) Date: Wed, 17 Apr 2013 23:26:54 +0800 Subject: [Engine-devel] How get all language WebAdm ? In-Reply-To: <4952460.MNzll7zG6g@awels> References: <4952460.MNzll7zG6g@awels> Message-ID: Thanks your answer,thanks. I install it from link: http://wiki.ovirt.org/Quick_Start_Guide I am compiling the source and USE COMMAND:mvn clean install -Pdep,gwt-user,gwt-admin,all-langs But if have not "-Dskiptest=true" and complie failed. The KEY error info: org.apache.maven.plugin.MojoFailureException: There are test failures. How can I repair the error? Now I complie COMMAND: mvn clean install -Pdep,gwt-user,gwt-admin,all-langs -Dskipte=true that OK? HI?All ????? --- ??????????? ?? ------------------------------------------------------------------------------ + ????????????????(????1:1) + ------------------------------------------------------------------------------ 2013/4/17 Alexander Wels > ** > > You need to compile GWT with the appropriate language profile. If you want > to compile with all languages make sure to include the all-langs profile in > your maven build command. for instance: > > > > mvn clean install -Pdep,gwt-user,gwt-admin,all-langs > > > > Be aware that compiling all languages will take a long time ~30 minutes on > my machine. You can specify particular languages to cut down on compile > time. > > > > Alexander > > > > On Wednesday, April 17, 2013 09:27:25 PM ?? wrote: > > > HI?All > > I install ovirt engine and open IE9 to manage. > > But I select Chinese language UI to display and failed. > > The UI's language always is Englisth and covers to Other language failed. > > > OS:federa 18. > > Ovirt-Engine:3.2 > > MEM Size:4G > > DIsk:60G > > CPU:intel i7 > > > Manage OS:Win7 Sp1 > > Manage IE:9 > > > Can you help me? > > Thanks, > > > > > > > _______________________________________________ > 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: From liqiang.net at gmail.com Wed Apr 17 15:44:04 2013 From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=) Date: Wed, 17 Apr 2013 23:44:04 +0800 Subject: [Engine-devel] How get all language WebAdm ? In-Reply-To: References: <4952460.MNzll7zG6g@awels> Message-ID: HI:All This is my logs, thanks, ========================================================== ------------------------------------------------------- T E S T S ------------------------------------------------------- Forking command line: /bin/sh -c cd /home/liqiang/ovirt-engine/backend/manager/modules/dal && /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/bin/java -jar /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefirebooter4261523418572089603.jar /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefire7472834543455719312tmp /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefire5281802986683589703tmp Running org.ovirt.engine.core.dao.DaoFactoryTest Tests run: 24, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.262 sec Running org.ovirt.engine.core.dal.job.ExecutionMessageDirectorTest 23:39:49,030 INFO [ExecutionMessageDirector] Start initializing ExecutionMessageDirector 23:39:49,032 ERROR [ExecutionMessageDirector] Message key job.AddDiskToVm is not valid for enum VdcActionType 23:39:49,033 INFO [ExecutionMessageDirector] Finished initializing ExecutionMessageDirector 23:39:49,033 INFO [ExecutionMessageDirector] Start initializing ExecutionMessageDirector 23:39:49,034 ERROR [ExecutionMessageDirector] Message key job.AddDiskToVm is not valid for enum VdcActionType 23:39:49,034 INFO [ExecutionMessageDirector] Finished initializing ExecutionMessageDirector 23:39:49,034 WARN [ExecutionMessageDirector] The message key Unknown is missing from bundles/ExecutionMessages 23:39:49,035 INFO [ExecutionMessageDirector] Start initializing ExecutionMessageDirector 23:39:49,036 ERROR [ExecutionMessageDirector] The message key XXX cannot be categorized since not started with job. nor step. 23:39:49,037 INFO [ExecutionMessageDirector] Finished initializing ExecutionMessageDirector 23:39:49,037 INFO [ExecutionMessageDirector] Start initializing ExecutionMessageDirector 23:39:49,039 ERROR [ExecutionMessageDirector] Message key job.ABC is not valid for enum VdcActionType 23:39:49,040 INFO [ExecutionMessageDirector] Finished initializing ExecutionMessageDirector 23:39:49,042 INFO [ExecutionMessageDirector] Start initializing ExecutionMessageDirector 23:39:49,044 ERROR [ExecutionMessageDirector] Message key step.XYZ is not valid for enum StepEnum 23:39:49,044 INFO [ExecutionMessageDirector] Finished initializing ExecutionMessageDirector Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec Running org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtilsTest 23:39:49,431 WARN [LocalConfig] The file "/usr/share/ovirt-engine/conf/engine.conf.defaults" doesn't exist or isn't readable. Will return an empty set of properties. 23:39:49,431 WARN [LocalConfig] The file "/etc/ovirt-engine/engine.conf" doesn't exist or isn't readable. Will return an empty set of properties. 23:39:49,432 ERROR [LocalConfig] The property "ENGINE_DB_CONNECTION_TIMEOUT" doesn't have a value. 23:39:49,433 WARN [DbFacadeLocator] Can't load connection checking parameters of DB facade, will continue using the default values. java.lang.IllegalArgumentException: The property "ENGINE_DB_CONNECTION_TIMEOUT" doesn't have a value. at org.ovirt.engine.core.utils.LocalConfig.getProperty(LocalConfig.java:234) at org.ovirt.engine.core.utils.LocalConfig.getInteger(LocalConfig.java:293) at org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.loadDbFacadeConfig(DbFacadeLocator.java:177) at org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.createDbFacade(DbFacadeLocator.java:62) at org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.getDbFacade(DbFacadeLocator.java:47) at org.ovirt.engine.core.dao.BaseDAOTestCase.initTestCase(BaseDAOTestCase.java:66) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71) at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) 23:39:49,830 WARN [SQLErrorCodesFactory] Error while extracting database product name - falling back to empty error codes org.springframework.jdbc.support.MetaDataAccessException: Could not get Connection for extracting meta data; nested exception is org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is org.postgresql.util.PSQLException: FATAL: database "engine_test" does not exist at org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:293) at org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:320) at org.springframework.jdbc.support.SQLErrorCodesFactory.getErrorCodes(SQLErrorCodesFactory.java:214) at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.setDataSource(SQLErrorCodeSQLExceptionTranslator.java:141) at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.(SQLErrorCodeSQLExceptionTranslator.java:104) at org.ovirt.engine.core.dal.dbbroker.CustomSQLErrorCodeSQLExceptionTranslator.(CustomSQLErrorCodeSQLExceptionTranslator.java:10) at org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.createDbFacade(DbFacadeLocator.java:79) at org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.getDbFacade(DbFacadeLocator.java:47) at org.ovirt.engine.core.dao.BaseDAOTestCase.initTestCase(BaseDAOTestCase.java:66) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71) at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is org.postgresql.util.PSQLException: FATAL: database "engine_test" does not exist at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:80) at org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:280) ... 34 more Caused by: org.postgresql.util.PSQLException: FATAL: database "engine_test" does not exist at org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:471) at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:112) at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66) at org.postgresql.jdbc2.AbstractJdbc2Connection.(AbstractJdbc2Connection.java:125) at org.postgresql.jdbc3.AbstractJdbc3Connection.(AbstractJdbc3Connection.java:30) at org.postgresql.jdbc3g.AbstractJdbc3gConnection.(AbstractJdbc3gConnection.java:22) at org.postgresql.jdbc4.AbstractJdbc4Connection.(AbstractJdbc4Connection.java:32) at org.postgresql.jdbc4.Jdbc4Connection.(Jdbc4Connection.java:24) at org.postgresql.Driver.makeConnection(Driver.java:393) at org.postgresql.Driver.connect(Driver.java:267) at java.sql.DriverManager.getConnection(DriverManager.java:579) at java.sql.DriverManager.getConnection(DriverManager.java:190) at org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriverManager(DriverManagerDataSource.java:173) at org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriver(DriverManagerDataSource.java:164) at org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getConnectionFromDriver(AbstractDriverBasedDataSource.java:149) at org.springframework.jdbc.datasource.SingleConnectionDataSource.initConnection(SingleConnectionDataSource.java:244) at org.springframework.jdbc.datasource.SingleConnectionDataSource.getConnection(SingleConnectionDataSource.java:186) at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111) at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77) ... 35 more Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.804 sec <<< FAILURE! Running org.ovirt.engine.core.dal.dbbroker.generic.DomainsPasswordMapTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.219 sec Running org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBaseTest Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirectorTest 23:39:50,102 INFO [AuditLogDirector] AuditLogType: UNASSIGNED not exist in string table 23:39:50,103 INFO [AuditLogDirector] AuditLogType: USER_RUN_UNLOCK_ENTITY_SCRIPT not exist in string table 23:39:50,103 INFO [AuditLogDirector] AuditLogType: VDS_NETWORK_MTU_DIFFER_FROM_LOGICAL_NETWORK not exist in string table 23:39:50,103 INFO [AuditLogDirector] AuditLogType: STORAGE_ACTIVATE_ASYNC not exist in string table 23:39:50,103 INFO [AuditLogDirector] AuditLogType: DWH_STOPPED not exist in string table 23:39:50,104 INFO [AuditLogDirector] AuditLogType: DWH_STARTED not exist in string table 23:39:50,104 INFO [AuditLogDirector] AuditLogType: DWH_ERROR not exist in string table 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_NORMAL not exist in string table 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_WARNING not exist in string table 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_ERROR not exist in string table 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_ALERT not exist in string table 23:39:50,109 WARN [AuditLogDirector] AuditLogType: USER_ATTACH_DISK_TO_VM not have severity. Assumed Normal 23:39:50,109 WARN [AuditLogDirector] AuditLogType: USER_DETACH_DISK_FROM_VM not have severity. Assumed Normal 23:39:50,109 WARN [AuditLogDirector] AuditLogType: USER_FAILED_DETACH_DISK_FROM_VM not have severity. Assumed Normal 23:39:50,109 WARN [AuditLogDirector] AuditLogType: USER_RUN_UNLOCK_ENTITY_SCRIPT not have severity. Assumed Normal 23:39:50,110 WARN [AuditLogDirector] AuditLogType: GLUSTER_VOLUME_OPTION_CHANGED_FROM_CLI not have severity. Assumed Normal 23:39:50,110 WARN [AuditLogDirector] AuditLogType: VM_MIGRATION_START_SYSTEM_INITIATED not have severity. Assumed Normal 23:39:50,110 WARN [AuditLogDirector] AuditLogType: VDS_NETWORK_MTU_DIFFER_FROM_LOGICAL_NETWORK not have severity. Assumed Normal 23:39:50,110 WARN [AuditLogDirector] AuditLogType: NETWORK_UPDATE_VM_INTERFACE_LINK_UP not have severity. Assumed Normal 23:39:50,111 WARN [AuditLogDirector] AuditLogType: NETWORK_UPDATE_VM_INTERFACE_LINK_DOWN not have severity. Assumed Normal Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.103 sec Running org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBaseTest 23:39:50,289 INFO [AuditLogableBase] Failed to get vds 11111111-1111-1111-1111-111111111113 null 23:39:50,293 INFO [AuditLogableBase] Failed to get vds 11111111-1111-1111-1111-111111111113 null 23:39:50,311 INFO [AuditLogableBase] Failed to get vm 11111111-1111-1111-1111-111111111113 Tests run: 113, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.145 sec Running org.ovirt.engine.core.dal.dbbroker.CustomMapSqlParameterSourceTest Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec Running org.ovirt.engine.core.DuplicateKeysTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec Results : Tests in error: org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtilsTest: FATAL: database "engine_test" does not exist Tests run: 168, Failures: 0, Errors: 1, Skipped: 0 [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] ovirt-root ........................................ SUCCESS [0.672s] [INFO] oVirt Build Tools root ............................ SUCCESS [0.062s] [INFO] oVirt checkstyle .................................. SUCCESS [2.132s] [INFO] oVirt JBoss Modules Maven Plugin .................. SUCCESS [51.899s] [INFO] oVirt Checkstyle Checks ........................... SUCCESS [1.420s] [INFO] oVirt Modules - backend ........................... SUCCESS [0.019s] [INFO] oVirt Manager ..................................... SUCCESS [0.015s] [INFO] oVirt DB Scripts .................................. SUCCESS [0.316s] [INFO] oVirt Engine dependencies ......................... SUCCESS [4.173s] [INFO] oVirt Modules - manager ........................... SUCCESS [1.352s] [INFO] CSharp Compatibility .............................. SUCCESS [3.588s] [INFO] Common Code ....................................... SUCCESS [13.706s] [INFO] Common utilities .................................. SUCCESS [17.133s] [INFO] Data Access Layer ................................. FAILURE [8.885s] [INFO] engine scheduler bean ............................. SKIPPED [INFO] Vds broker ........................................ SKIPPED [INFO] Search Backend .................................... SKIPPED [INFO] Backend Logic @Service bean ....................... SKIPPED [INFO] oVirt RESTful API Backend Integration ............. SKIPPED [INFO] oVirt RESTful API interface ....................... SKIPPED [INFO] oVirt Engine API Definition ....................... SKIPPED [INFO] oVirt Engine API Commom Parent POM ................ SKIPPED [INFO] oVirt Engine API Common JAX-RS .................... SKIPPED [INFO] oVirt RESTful API Backend Integration Type Mappers SKIPPED [INFO] oVirt RESTful API Backend Integration JAX-RS Resources SKIPPED [INFO] oVirt RESTful API Backend Integration Webapp ...... SKIPPED [INFO] oVirt Engine Web Root ............................. SKIPPED [INFO] oVirt Engine Tools ................................ SKIPPED [INFO] oVirt Modules :: Frontend ......................... SKIPPED [INFO] oVirt Modules :: Webadmin ......................... SKIPPED [INFO] oVirt Modules - ui ................................ SKIPPED [INFO] Extensions for GWT ................................ SKIPPED [INFO] UI Utils Compatibility (for UICommon) ............. SKIPPED [INFO] Frontend for GWT UI Projects ...................... SKIPPED [INFO] UICommonWeb ....................................... SKIPPED [INFO] oVirt GWT UI common infrastructure ................ SKIPPED [INFO] WebAdmin .......................................... SKIPPED [INFO] UserPortal ........................................ SKIPPED [INFO] oVirt Server EAR .................................. SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1:47.204s [INFO] Finished at: Wed Apr 17 23:39:50 CST 2013 [INFO] Final Memory: 70M/291M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.10:test (default-test) on project dal: There are test failures. [ERROR] [ERROR] Please refer to /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports for the individual test results. [ERROR] -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.10:test (default-test) on project dal: There are test failures. Please refer to /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports for the individual test results. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:158) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoFailureException: There are test failures. Please refer to /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports for the individual test results. at org.apache.maven.plugin.surefire.SurefireHelper.reportExecution(SurefireHelper.java:87) at org.apache.maven.plugin.surefire.SurefirePlugin.writeSummary(SurefirePlugin.java:641) at org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:615) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:137) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:98) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more [ERROR] [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :dal [liqiang at localhost ovirt-engine]$ ========================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From liqiang.net at gmail.com Wed Apr 17 15:53:20 2013 From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=) Date: Wed, 17 Apr 2013 23:53:20 +0800 Subject: [Engine-devel] How get all language WebAdm ? In-Reply-To: References: <4952460.MNzll7zG6g@awels> Message-ID: HI:All But my db config from link: http://wiki.ovirt.org/Installing_PostgreSQL_DB and this title: Connecting to the database I follow this and edit the file:/var/lib/pgsql/data/pg_hba.conf local all all trust host all all 127.0.0.1/32 trust host all all ::1/128 trust HI?All ????? --- ??????????? ?? ------------------------------------------------------------------------------ + ????????????????(????1:1) + ------------------------------------------------------------------------------ 2013/4/17 ?? > HI:All > > This is my logs, thanks, > > ========================================================== > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Forking command line: /bin/sh -c cd > /home/liqiang/ovirt-engine/backend/manager/modules/dal && > /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/bin/java -jar > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefirebooter4261523418572089603.jar > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefire7472834543455719312tmp > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefire5281802986683589703tmp > Running org.ovirt.engine.core.dao.DaoFactoryTest > Tests run: 24, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.262 sec > Running org.ovirt.engine.core.dal.job.ExecutionMessageDirectorTest > 23:39:49,030 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > 23:39:49,032 ERROR [ExecutionMessageDirector] Message key job.AddDiskToVm > is not valid for enum VdcActionType > 23:39:49,033 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > 23:39:49,033 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > 23:39:49,034 ERROR [ExecutionMessageDirector] Message key job.AddDiskToVm > is not valid for enum VdcActionType > 23:39:49,034 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > 23:39:49,034 WARN [ExecutionMessageDirector] The message key Unknown is > missing from bundles/ExecutionMessages > 23:39:49,035 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > 23:39:49,036 ERROR [ExecutionMessageDirector] The message key XXX cannot > be categorized since not started with job. nor step. > 23:39:49,037 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > 23:39:49,037 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > 23:39:49,039 ERROR [ExecutionMessageDirector] Message key job.ABC is not > valid for enum VdcActionType > 23:39:49,040 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > 23:39:49,042 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > 23:39:49,044 ERROR [ExecutionMessageDirector] Message key step.XYZ is not > valid for enum StepEnum > 23:39:49,044 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec > Running org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtilsTest > 23:39:49,431 WARN [LocalConfig] The file > "/usr/share/ovirt-engine/conf/engine.conf.defaults" doesn't exist or isn't > readable. Will return an empty set of properties. > 23:39:49,431 WARN [LocalConfig] The file "/etc/ovirt-engine/engine.conf" > doesn't exist or isn't readable. Will return an empty set of properties. > 23:39:49,432 ERROR [LocalConfig] The property > "ENGINE_DB_CONNECTION_TIMEOUT" doesn't have a value. > 23:39:49,433 WARN [DbFacadeLocator] Can't load connection checking > parameters of DB facade, will continue using the default values. > java.lang.IllegalArgumentException: The property > "ENGINE_DB_CONNECTION_TIMEOUT" doesn't have a value. > at > org.ovirt.engine.core.utils.LocalConfig.getProperty(LocalConfig.java:234) > at > org.ovirt.engine.core.utils.LocalConfig.getInteger(LocalConfig.java:293) > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.loadDbFacadeConfig(DbFacadeLocator.java:177) > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.createDbFacade(DbFacadeLocator.java:62) > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.getDbFacade(DbFacadeLocator.java:47) > at > org.ovirt.engine.core.dao.BaseDAOTestCase.initTestCase(BaseDAOTestCase.java:66) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > at > org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > at > org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) > at org.junit.rules.RunRules.evaluate(RunRules.java:18) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at > org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > 23:39:49,830 WARN [SQLErrorCodesFactory] Error while extracting database > product name - falling back to empty error codes > org.springframework.jdbc.support.MetaDataAccessException: Could not get > Connection for extracting meta data; nested exception is > org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get > JDBC Connection; nested exception is org.postgresql.util.PSQLException: > FATAL: database "engine_test" does not exist > at > org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:293) > at > org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:320) > at > org.springframework.jdbc.support.SQLErrorCodesFactory.getErrorCodes(SQLErrorCodesFactory.java:214) > at > org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.setDataSource(SQLErrorCodeSQLExceptionTranslator.java:141) > at > org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.(SQLErrorCodeSQLExceptionTranslator.java:104) > at > org.ovirt.engine.core.dal.dbbroker.CustomSQLErrorCodeSQLExceptionTranslator.(CustomSQLErrorCodeSQLExceptionTranslator.java:10) > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.createDbFacade(DbFacadeLocator.java:79) > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.getDbFacade(DbFacadeLocator.java:47) > at > org.ovirt.engine.core.dao.BaseDAOTestCase.initTestCase(BaseDAOTestCase.java:66) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > at > org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > at > org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) > at org.junit.rules.RunRules.evaluate(RunRules.java:18) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at > org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: > Could not get JDBC Connection; nested exception is > org.postgresql.util.PSQLException: FATAL: database "engine_test" does not > exist > at > org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:80) > at > org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:280) > ... 34 more > Caused by: org.postgresql.util.PSQLException: FATAL: database > "engine_test" does not exist > at > org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:471) > at > org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:112) > at > org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66) > at > org.postgresql.jdbc2.AbstractJdbc2Connection.(AbstractJdbc2Connection.java:125) > at > org.postgresql.jdbc3.AbstractJdbc3Connection.(AbstractJdbc3Connection.java:30) > at > org.postgresql.jdbc3g.AbstractJdbc3gConnection.(AbstractJdbc3gConnection.java:22) > at > org.postgresql.jdbc4.AbstractJdbc4Connection.(AbstractJdbc4Connection.java:32) > at > org.postgresql.jdbc4.Jdbc4Connection.(Jdbc4Connection.java:24) > at org.postgresql.Driver.makeConnection(Driver.java:393) > at org.postgresql.Driver.connect(Driver.java:267) > at java.sql.DriverManager.getConnection(DriverManager.java:579) > at java.sql.DriverManager.getConnection(DriverManager.java:190) > at > org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriverManager(DriverManagerDataSource.java:173) > at > org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriver(DriverManagerDataSource.java:164) > at > org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getConnectionFromDriver(AbstractDriverBasedDataSource.java:149) > at > org.springframework.jdbc.datasource.SingleConnectionDataSource.initConnection(SingleConnectionDataSource.java:244) > at > org.springframework.jdbc.datasource.SingleConnectionDataSource.getConnection(SingleConnectionDataSource.java:186) > at > org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111) > at > org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77) > ... 35 more > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.804 sec > <<< FAILURE! > Running org.ovirt.engine.core.dal.dbbroker.generic.DomainsPasswordMapTest > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.219 sec > Running org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBaseTest > Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec > Running > org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirectorTest > 23:39:50,102 INFO [AuditLogDirector] AuditLogType: UNASSIGNED not exist > in string table > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: > USER_RUN_UNLOCK_ENTITY_SCRIPT not exist in string table > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: > VDS_NETWORK_MTU_DIFFER_FROM_LOGICAL_NETWORK not exist in string table > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: STORAGE_ACTIVATE_ASYNC > not exist in string table > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: DWH_STOPPED not exist > in string table > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: DWH_STARTED not exist > in string table > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: DWH_ERROR not exist in > string table > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_NORMAL > not exist in string table > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_WARNING > not exist in string table > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_ERROR > not exist in string table > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_ALERT not > exist in string table > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: USER_ATTACH_DISK_TO_VM > not have severity. Assumed Normal > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: > USER_DETACH_DISK_FROM_VM not have severity. Assumed Normal > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: > USER_FAILED_DETACH_DISK_FROM_VM not have severity. Assumed Normal > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: > USER_RUN_UNLOCK_ENTITY_SCRIPT not have severity. Assumed Normal > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > GLUSTER_VOLUME_OPTION_CHANGED_FROM_CLI not have severity. Assumed Normal > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > VM_MIGRATION_START_SYSTEM_INITIATED not have severity. Assumed Normal > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > VDS_NETWORK_MTU_DIFFER_FROM_LOGICAL_NETWORK not have severity. Assumed > Normal > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > NETWORK_UPDATE_VM_INTERFACE_LINK_UP not have severity. Assumed Normal > 23:39:50,111 WARN [AuditLogDirector] AuditLogType: > NETWORK_UPDATE_VM_INTERFACE_LINK_DOWN not have severity. Assumed Normal > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.103 sec > Running > org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBaseTest > 23:39:50,289 INFO [AuditLogableBase] Failed to get vds > 11111111-1111-1111-1111-111111111113 > null > 23:39:50,293 INFO [AuditLogableBase] Failed to get vds > 11111111-1111-1111-1111-111111111113 > null > 23:39:50,311 INFO [AuditLogableBase] Failed to get vm > 11111111-1111-1111-1111-111111111113 > Tests run: 113, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.145 sec > Running org.ovirt.engine.core.dal.dbbroker.CustomMapSqlParameterSourceTest > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec > Running org.ovirt.engine.core.DuplicateKeysTest > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec > > Results : > > Tests in error: > org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtilsTest: FATAL: > database "engine_test" does not exist > > Tests run: 168, Failures: 0, Errors: 1, Skipped: 0 > > [INFO] > ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] ovirt-root ........................................ SUCCESS [0.672s] > [INFO] oVirt Build Tools root ............................ SUCCESS [0.062s] > [INFO] oVirt checkstyle .................................. SUCCESS [2.132s] > [INFO] oVirt JBoss Modules Maven Plugin .................. SUCCESS > [51.899s] > [INFO] oVirt Checkstyle Checks ........................... SUCCESS [1.420s] > [INFO] oVirt Modules - backend ........................... SUCCESS [0.019s] > [INFO] oVirt Manager ..................................... SUCCESS [0.015s] > [INFO] oVirt DB Scripts .................................. SUCCESS [0.316s] > [INFO] oVirt Engine dependencies ......................... SUCCESS [4.173s] > [INFO] oVirt Modules - manager ........................... SUCCESS [1.352s] > [INFO] CSharp Compatibility .............................. SUCCESS [3.588s] > [INFO] Common Code ....................................... SUCCESS > [13.706s] > [INFO] Common utilities .................................. SUCCESS > [17.133s] > [INFO] Data Access Layer ................................. FAILURE [8.885s] > [INFO] engine scheduler bean ............................. SKIPPED > [INFO] Vds broker ........................................ SKIPPED > [INFO] Search Backend .................................... SKIPPED > [INFO] Backend Logic @Service bean ....................... SKIPPED > [INFO] oVirt RESTful API Backend Integration ............. SKIPPED > [INFO] oVirt RESTful API interface ....................... SKIPPED > [INFO] oVirt Engine API Definition ....................... SKIPPED > [INFO] oVirt Engine API Commom Parent POM ................ SKIPPED > [INFO] oVirt Engine API Common JAX-RS .................... SKIPPED > [INFO] oVirt RESTful API Backend Integration Type Mappers SKIPPED > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources SKIPPED > [INFO] oVirt RESTful API Backend Integration Webapp ...... SKIPPED > [INFO] oVirt Engine Web Root ............................. SKIPPED > [INFO] oVirt Engine Tools ................................ SKIPPED > [INFO] oVirt Modules :: Frontend ......................... SKIPPED > [INFO] oVirt Modules :: Webadmin ......................... SKIPPED > [INFO] oVirt Modules - ui ................................ SKIPPED > [INFO] Extensions for GWT ................................ SKIPPED > [INFO] UI Utils Compatibility (for UICommon) ............. SKIPPED > [INFO] Frontend for GWT UI Projects ...................... SKIPPED > [INFO] UICommonWeb ....................................... SKIPPED > [INFO] oVirt GWT UI common infrastructure ................ SKIPPED > [INFO] WebAdmin .......................................... SKIPPED > [INFO] UserPortal ........................................ SKIPPED > [INFO] oVirt Server EAR .................................. SKIPPED > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 1:47.204s > [INFO] Finished at: Wed Apr 17 23:39:50 CST 2013 > [INFO] Final Memory: 70M/291M > [INFO] > ------------------------------------------------------------------------ > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.10:test (default-test) on > project dal: There are test failures. > [ERROR] > [ERROR] Please refer to > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports > for the individual test results. > [ERROR] -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-surefire-plugin:2.10:test > (default-test) on project dal: There are test failures. > > Please refer to > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports > for the individual test results. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:158) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoFailureException: There are test > failures. > > Please refer to > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports > for the individual test results. > at > org.apache.maven.plugin.surefire.SurefireHelper.reportExecution(SurefireHelper.java:87) > at > org.apache.maven.plugin.surefire.SurefirePlugin.writeSummary(SurefirePlugin.java:641) > at > org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:615) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:137) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:98) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 19 more > [ERROR] > [ERROR] > [ERROR] For more information about the errors and possible solutions, > please read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the > command > [ERROR] mvn -rf :dal > [liqiang at localhost ovirt-engine]$ > ========================================================== > -------------- next part -------------- An HTML attachment was scrubbed... URL: From awels at redhat.com Wed Apr 17 15:53:46 2013 From: awels at redhat.com (Alexander Wels) Date: Wed, 17 Apr 2013 11:53:46 -0400 Subject: [Engine-devel] How get all language WebAdm ? In-Reply-To: References: Message-ID: <15900704.TebiEUGJZG@awels> I am having the same error locally right now. Someone broke the unit tests, they should get fixed sooner or later. For now just skip the tests when building with - DskipTests On Wednesday, April 17, 2013 11:44:04 PM ?? wrote: HI:All This is my logs, thanks, ================================================== ======== ------------------------------------------------------- T E S T S ------------------------------------------------------- Forking command line: /bin/sh -c cd /home/liqiang/ovirt- engine/backend/manager/modules/dal && /usr/lib/jvm/java-1.7.0- openjdk-1.7.0.17.x86_64/jre/bin/java -jar /home/liqiang/ovirt- engine/backend/manager/modules/dal/target/surefire/surefirebooter42615234185720 89603.jar /home/liqiang/ovirt- engine/backend/manager/modules/dal/target/surefire/surefire7472834543455719312t mp /home/liqiang/ovirt- engine/backend/manager/modules/dal/target/surefire/surefire5281802986683589703t mp Running org.ovirt.engine.core.dao.DaoFactoryTest Tests run: 24, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.262 sec Running org.ovirt.engine.core.dal.job.ExecutionMessageDirectorTest 23:39:49,030 INFO [ExecutionMessageDirector] Start initializing ExecutionMessageDirector 23:39:49,032 ERROR [ExecutionMessageDirector] Message key job.AddDiskToVm is not valid for enum VdcActionType 23:39:49,033 INFO [ExecutionMessageDirector] Finished initializing ExecutionMessageDirector 23:39:49,033 INFO [ExecutionMessageDirector] Start initializing ExecutionMessageDirector 23:39:49,034 ERROR [ExecutionMessageDirector] Message key job.AddDiskToVm is not valid for enum VdcActionType 23:39:49,034 INFO [ExecutionMessageDirector] Finished initializing ExecutionMessageDirector 23:39:49,034 WARN [ExecutionMessageDirector] The message key Unknown is missing from bundles/ExecutionMessages 23:39:49,035 INFO [ExecutionMessageDirector] Start initializing ExecutionMessageDirector 23:39:49,036 ERROR [ExecutionMessageDirector] The message key XXX cannot be categorized since not started with job. nor step. 23:39:49,037 INFO [ExecutionMessageDirector] Finished initializing ExecutionMessageDirector 23:39:49,037 INFO [ExecutionMessageDirector] Start initializing ExecutionMessageDirector 23:39:49,039 ERROR [ExecutionMessageDirector] Message key job.ABC is not valid for enum VdcActionType 23:39:49,040 INFO [ExecutionMessageDirector] Finished initializing ExecutionMessageDirector 23:39:49,042 INFO [ExecutionMessageDirector] Start initializing ExecutionMessageDirector 23:39:49,044 ERROR [ExecutionMessageDirector] Message key step.XYZ is not valid for enum StepEnum 23:39:49,044 INFO [ExecutionMessageDirector] Finished initializing ExecutionMessageDirector Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec Running org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtilsTest 23:39:49,431 WARN [LocalConfig] The file "/usr/share/ovirt- engine/conf/engine.conf.defaults" doesn't exist or isn't readable. Will return an empty set of properties. 23:39:49,431 WARN [LocalConfig] The file "/etc/ovirt-engine/engine.conf" doesn't exist or isn't readable. Will return an empty set of properties. 23:39:49,432 ERROR [LocalConfig] The property "ENGINE_DB_CONNECTION_TIMEOUT" doesn't have a value. 23:39:49,433 WARN [DbFacadeLocator] Can't load connection checking parameters of DB facade, will continue using the default values. java.lang.IllegalArgumentException: The property "ENGINE_DB_CONNECTION_TIMEOUT" doesn't have a value. at org.ovirt.engine.core.utils.LocalConfig.getProperty(LocalConfig.java:234) at org.ovirt.engine.core.utils.LocalConfig.getInteger(LocalConfig.java:293) at org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.loadDbFacadeConfig(DbFacadeLo cator.java:177) at org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.createDbFacade(DbFacadeLocato r.java:62) at org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.getDbFacade(DbFacadeLocator.ja va:47) at org.ovirt.engine.core.dao.BaseDAOTestCase.initTestCase(BaseDAOTestCase.java:66) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav a:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java: 45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:4 2) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.eval uate(RunBeforeTestClassCallbacks.java:61) at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evalua te(RunAfterTestClassCallbacks.java:71) at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4Clas sRunner.java:174) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:12 3) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav a:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.ja va:164) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFacto ry.java:110) -------------- next part -------------- An HTML attachment was scrubbed... URL: From liqiang.net at gmail.com Wed Apr 17 15:57:36 2013 From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=) Date: Wed, 17 Apr 2013 23:57:36 +0800 Subject: [Engine-devel] How get all language WebAdm ? In-Reply-To: <15900704.TebiEUGJZG@awels> References: <15900704.TebiEUGJZG@awels> Message-ID: We should submit the bug to ovirt ? I think that maybe is config file error but I not be sure. HI?All ????? --- ??????????? ?? ------------------------------------------------------------------------------ + ????????????????(????1:1) + ------------------------------------------------------------------------------ 2013/4/17 Alexander Wels > ** > > I am having the same error locally right now. Someone broke the unit > tests, they should get fixed sooner or later. For now just skip the tests > when building with -DskipTests > > > > On Wednesday, April 17, 2013 11:44:04 PM ?? wrote: > > HI:All > > > This is my logs, thanks, > > > ========================================================== > > ------------------------------------------------------- > > T E S T S > > ------------------------------------------------------- > > Forking command line: /bin/sh -c cd > /home/liqiang/ovirt-engine/backend/manager/modules/dal && > /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/bin/java -jar > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefirebooter4261523418572089603.jar > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefire7472834543455719312tmp > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefire5281802986683589703tmp > > > Running org.ovirt.engine.core.dao.DaoFactoryTest > > Tests run: 24, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.262 sec > > Running org.ovirt.engine.core.dal.job.ExecutionMessageDirectorTest > > 23:39:49,030 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > > 23:39:49,032 ERROR [ExecutionMessageDirector] Message key job.AddDiskToVm > is not valid for enum VdcActionType > > 23:39:49,033 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > > 23:39:49,033 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > > 23:39:49,034 ERROR [ExecutionMessageDirector] Message key job.AddDiskToVm > is not valid for enum VdcActionType > > 23:39:49,034 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > > 23:39:49,034 WARN [ExecutionMessageDirector] The message key Unknown is > missing from bundles/ExecutionMessages > > 23:39:49,035 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > > 23:39:49,036 ERROR [ExecutionMessageDirector] The message key XXX cannot > be categorized since not started with job. nor step. > > 23:39:49,037 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > > 23:39:49,037 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > > 23:39:49,039 ERROR [ExecutionMessageDirector] Message key job.ABC is not > valid for enum VdcActionType > > 23:39:49,040 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > > 23:39:49,042 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > > 23:39:49,044 ERROR [ExecutionMessageDirector] Message key step.XYZ is not > valid for enum StepEnum > > 23:39:49,044 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec > > Running org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtilsTest > > 23:39:49,431 WARN [LocalConfig] The file > "/usr/share/ovirt-engine/conf/engine.conf.defaults" doesn't exist or isn't > readable. Will return an empty set of properties. > > 23:39:49,431 WARN [LocalConfig] The file "/etc/ovirt-engine/engine.conf" > doesn't exist or isn't readable. Will return an empty set of properties. > > 23:39:49,432 ERROR [LocalConfig] The property > "ENGINE_DB_CONNECTION_TIMEOUT" doesn't have a value. > > 23:39:49,433 WARN [DbFacadeLocator] Can't load connection checking > parameters of DB facade, will continue using the default values. > > java.lang.IllegalArgumentException: The property > "ENGINE_DB_CONNECTION_TIMEOUT" doesn't have a value. > > at > org.ovirt.engine.core.utils.LocalConfig.getProperty(LocalConfig.java:234) > > at > org.ovirt.engine.core.utils.LocalConfig.getInteger(LocalConfig.java:293) > > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.loadDbFacadeConfig(DbFacadeLocator.java:177) > > > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.createDbFacade(DbFacadeLocator.java:62) > > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.getDbFacade(DbFacadeLocator.java:47) > > > at > org.ovirt.engine.core.dao.BaseDAOTestCase.initTestCase(BaseDAOTestCase.java:66) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(Method.java:601) > > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > > > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > > at > org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > > > at > org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71) > > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) > > at org.junit.rules.RunRules.evaluate(RunRules.java:18) > > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > > at > org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174) > > > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > > > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(Method.java:601) > > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > > > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > > > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > > 23:39:49,830 WARN [SQLErrorCodesFactory] Error while extracting database > product name - falling back to empty error codes > > org.springframework.jdbc.support.MetaDataAccessException: Could not get > Connection for extracting meta data; nested exception is > org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get > JDBC Connection; nested exception is org.postgresql.util.PSQLException: > FATAL: database "engine_test" does not exist > > at > org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:293) > > at > org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:320) > > > at > org.springframework.jdbc.support.SQLErrorCodesFactory.getErrorCodes(SQLErrorCodesFactory.java:214) > > at > org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.setDataSource(SQLErrorCodeSQLExceptionTranslator.java:141) > > > at > org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.(SQLErrorCodeSQLExceptionTranslator.java:104) > > at > org.ovirt.engine.core.dal.dbbroker.CustomSQLErrorCodeSQLExceptionTranslator.(CustomSQLErrorCodeSQLExceptionTranslator.java:10) > > > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.createDbFacade(DbFacadeLocator.java:79) > > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.getDbFacade(DbFacadeLocator.java:47) > > > at > org.ovirt.engine.core.dao.BaseDAOTestCase.initTestCase(BaseDAOTestCase.java:66) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(Method.java:601) > > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > > > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > > at > org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > > > at > org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71) > > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) > > at org.junit.rules.RunRules.evaluate(RunRules.java:18) > > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > > at > org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174) > > > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > > > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(Method.java:601) > > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > > > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > > > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > > Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: > Could not get JDBC Connection; nested exception is > org.postgresql.util.PSQLException: FATAL: database "engine_test" does not > exist > > at > org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:80) > > at > org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:280) > > > ... 34 more > > Caused by: org.postgresql.util.PSQLException: FATAL: database > "engine_test" does not exist > > at > org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:471) > > > at > org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:112) > > at > org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66) > > > at > org.postgresql.jdbc2.AbstractJdbc2Connection.(AbstractJdbc2Connection.java:125) > > at > org.postgresql.jdbc3.AbstractJdbc3Connection.(AbstractJdbc3Connection.java:30) > > > at > org.postgresql.jdbc3g.AbstractJdbc3gConnection.(AbstractJdbc3gConnection.java:22) > > at > org.postgresql.jdbc4.AbstractJdbc4Connection.(AbstractJdbc4Connection.java:32) > > > at > org.postgresql.jdbc4.Jdbc4Connection.(Jdbc4Connection.java:24) > > at org.postgresql.Driver.makeConnection(Driver.java:393) > > at org.postgresql.Driver.connect(Driver.java:267) > > at java.sql.DriverManager.getConnection(DriverManager.java:579) > > at java.sql.DriverManager.getConnection(DriverManager.java:190) > > at > org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriverManager(DriverManagerDataSource.java:173) > > at > org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriver(DriverManagerDataSource.java:164) > > > at > org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getConnectionFromDriver(AbstractDriverBasedDataSource.java:149) > > at > org.springframework.jdbc.datasource.SingleConnectionDataSource.initConnection(SingleConnectionDataSource.java:244) > > > at > org.springframework.jdbc.datasource.SingleConnectionDataSource.getConnection(SingleConnectionDataSource.java:186) > > at > org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111) > > > at > org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77) > > ... 35 more > > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.804 sec > <<< FAILURE! > > Running org.ovirt.engine.core.dal.dbbroker.generic.DomainsPasswordMapTest > > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.219 sec > > Running org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBaseTest > > Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec > > Running > org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirectorTest > > 23:39:50,102 INFO [AuditLogDirector] AuditLogType: UNASSIGNED not exist > in string table > > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: > USER_RUN_UNLOCK_ENTITY_SCRIPT not exist in string table > > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: > VDS_NETWORK_MTU_DIFFER_FROM_LOGICAL_NETWORK not exist in string table > > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: STORAGE_ACTIVATE_ASYNC > not exist in string table > > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: DWH_STOPPED not exist > in string table > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: DWH_STARTED not exist > in string table > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: DWH_ERROR not exist in > string table > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_NORMAL > not exist in string table > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_WARNING > not exist in string table > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_ERROR > not exist in string table > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_ALERT not > exist in string table > > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: USER_ATTACH_DISK_TO_VM > not have severity. Assumed Normal > > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: > USER_DETACH_DISK_FROM_VM not have severity. Assumed Normal > > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: > USER_FAILED_DETACH_DISK_FROM_VM not have severity. Assumed Normal > > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: > USER_RUN_UNLOCK_ENTITY_SCRIPT not have severity. Assumed Normal > > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > GLUSTER_VOLUME_OPTION_CHANGED_FROM_CLI not have severity. Assumed Normal > > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > VM_MIGRATION_START_SYSTEM_INITIATED not have severity. Assumed Normal > > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > VDS_NETWORK_MTU_DIFFER_FROM_LOGICAL_NETWORK not have severity. Assumed > Normal > > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > NETWORK_UPDATE_VM_INTERFACE_LINK_UP not have severity. Assumed Normal > > 23:39:50,111 WARN [AuditLogDirector] AuditLogType: > NETWORK_UPDATE_VM_INTERFACE_LINK_DOWN not have severity. Assumed Normal > > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.103 sec > > Running > org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBaseTest > > 23:39:50,289 INFO [AuditLogableBase] Failed to get vds > 11111111-1111-1111-1111-111111111113 > > null > > 23:39:50,293 INFO [AuditLogableBase] Failed to get vds > 11111111-1111-1111-1111-111111111113 > > null > > 23:39:50,311 INFO [AuditLogableBase] Failed to get vm > 11111111-1111-1111-1111-111111111113 > > Tests run: 113, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.145 > sec > > Running org.ovirt.engine.core.dal.dbbroker.CustomMapSqlParameterSourceTest > > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec > > Running org.ovirt.engine.core.DuplicateKeysTest > > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec > > > Results : > > > Tests in error: > > org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtilsTest: FATAL: > database "engine_test" does not exist > > > Tests run: 168, Failures: 0, Errors: 1, Skipped: 0 > > > [INFO] > ------------------------------------------------------------------------ > > [INFO] Reactor Summary: > > [INFO] > > [INFO] ovirt-root ........................................ SUCCESS [0.672s] > > [INFO] oVirt Build Tools root ............................ SUCCESS [0.062s] > > [INFO] oVirt checkstyle .................................. SUCCESS [2.132s] > > [INFO] oVirt JBoss Modules Maven Plugin .................. SUCCESS > [51.899s] > > [INFO] oVirt Checkstyle Checks ........................... SUCCESS [1.420s] > > [INFO] oVirt Modules - backend ........................... SUCCESS [0.019s] > > [INFO] oVirt Manager ..................................... SUCCESS [0.015s] > > [INFO] oVirt DB Scripts .................................. SUCCESS [0.316s] > > [INFO] oVirt Engine dependencies ......................... SUCCESS > [4.173s] > > [INFO] oVirt Modules - manager ........................... SUCCESS [1.352s] > > [INFO] CSharp Compatibility .............................. SUCCESS [3.588s] > > [INFO] Common Code ....................................... SUCCESS > [13.706s] > > [INFO] Common utilities .................................. SUCCESS > [17.133s] > > [INFO] Data Access Layer ................................. FAILURE > [8.885s] > > [INFO] engine scheduler bean ............................. SKIPPED > > [INFO] Vds broker ........................................ SKIPPED > > [INFO] Search Backend .................................... SKIPPED > > [INFO] Backend Logic @Service bean ....................... SKIPPED > > [INFO] oVirt RESTful API Backend Integration ............. SKIPPED > > [INFO] oVirt RESTful API interface ....................... SKIPPED > > [INFO] oVirt Engine API Definition ....................... SKIPPED > > [INFO] oVirt Engine API Commom Parent POM ................ SKIPPED > > [INFO] oVirt Engine API Common JAX-RS .................... SKIPPED > > [INFO] oVirt RESTful API Backend Integration Type Mappers SKIPPED > > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources SKIPPED > > [INFO] oVirt RESTful API Backend Integration Webapp ...... SKIPPED > > [INFO] oVirt Engine Web Root ............................. SKIPPED > > [INFO] oVirt Engine Tools ................................ SKIPPED > > [INFO] oVirt Modules :: Frontend ......................... SKIPPED > > [INFO] oVirt Modules :: Webadmin ......................... SKIPPED > > [INFO] oVirt Modules - ui ................................ SKIPPED > > [INFO] Extensions for GWT ................................ SKIPPED > > [INFO] UI Utils Compatibility (for UICommon) ............. SKIPPED > > [INFO] Frontend for GWT UI Projects ...................... SKIPPED > > [INFO] UICommonWeb ....................................... SKIPPED > > [INFO] oVirt GWT UI common infrastructure ................ SKIPPED > > [INFO] WebAdmin .......................................... SKIPPED > > [INFO] UserPortal ........................................ SKIPPED > > [INFO] oVirt Server EAR .................................. SKIPPED > > [INFO] > ------------------------------------------------------------------------ > > [INFO] BUILD FAILURE > > [INFO] > ------------------------------------------------------------------------ > > [INFO] Total time: 1:47.204s > > [INFO] Finished at: Wed Apr 17 23:39:50 CST 2013 > > [INFO] Final Memory: 70M/291M > > [INFO] > ------------------------------------------------------------------------ > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.10:test (default-test) on > project dal: There are test failures. > > [ERROR] > > [ERROR] Please refer to > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports > for the individual test results. > > [ERROR] -> [Help 1] > > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-surefire-plugin:2.10:test > (default-test) on project dal: There are test failures. > > > Please refer to > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports > for the individual test results. > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) > > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:158) > > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:601) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > > > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > > Caused by: org.apache.maven.plugin.MojoFailureException: There are test > failures. > > > Please refer to > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports > for the individual test results. > > at > org.apache.maven.plugin.surefire.SurefireHelper.reportExecution(SurefireHelper.java:87) > > > at > org.apache.maven.plugin.surefire.SurefirePlugin.writeSummary(SurefirePlugin.java:641) > > at > org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:615) > > > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:137) > > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:98) > > > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > > > ... 19 more > > [ERROR] > > [ERROR] > > [ERROR] For more information about the errors and possible solutions, > please read the following articles: > > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > > [ERROR] > > [ERROR] After correcting the problems, you can resume the build with the > command > > [ERROR] mvn -rf :dal > > [liqiang at localhost ovirt-engine]$ > > ========================================================== > > > > > _______________________________________________ > 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: From lhornyak at redhat.com Thu Apr 18 05:40:35 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Thu, 18 Apr 2013 01:40:35 -0400 (EDT) Subject: [Engine-devel] How get all language WebAdm ? In-Reply-To: References: <15900704.TebiEUGJZG@awels> Message-ID: <2144919614.2043029.1366263635770.JavaMail.root@redhat.com> ----- Original Message ----- > From: "??" > To: awels at redhat.com > Cc: engine-devel at ovirt.org > Sent: Wednesday, April 17, 2013 5:57:36 PM > Subject: Re: [Engine-devel] How get all language WebAdm ? > > We should submit the bug to ovirt ? > > I think that maybe is config file error but I not be sure. Hi, No, it is maven-related. Maven ignores tests with -DskipTests but not with "-Dskipte=true" and then you do not have a test environment set up. It looks like a typo, not a bug :) > > HI?All > > ????? > > --- > ??????????? > ?? > > ------------------------------------------------------------------------------ > > + ????????????????(????1:1) + > ------------------------------------------------------------------------------ > > > 2013/4/17 Alexander Wels < awels at redhat.com > > > > > > > I am having the same error locally right now. Someone broke the unit tests, > they should get fixed sooner or later. For now just skip the tests when > building with -DskipTests > > > > > On Wednesday, April 17, 2013 11:44:04 PM ?? wrote: > > > HI:All > > > > > This is my logs, thanks, > > > > > ========================================================== > > ------------------------------------------------------- > > T E S T S > > ------------------------------------------------------- > > Forking command line: /bin/sh -c cd > /home/liqiang/ovirt-engine/backend/manager/modules/dal && > /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/bin/java -jar > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefirebooter4261523418572089603.jar > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefire7472834543455719312tmp > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefire5281802986683589703tmp > > Running org.ovirt.engine.core.dao.DaoFactoryTest > > Tests run: 24, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.262 sec > > Running org.ovirt.engine.core.dal.job.ExecutionMessageDirectorTest > > 23:39:49,030 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > > 23:39:49,032 ERROR [ExecutionMessageDirector] Message key job.AddDiskToVm is > not valid for enum VdcActionType > > 23:39:49,033 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > > 23:39:49,033 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > > 23:39:49,034 ERROR [ExecutionMessageDirector] Message key job.AddDiskToVm is > not valid for enum VdcActionType > > 23:39:49,034 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > > 23:39:49,034 WARN [ExecutionMessageDirector] The message key Unknown is > missing from bundles/ExecutionMessages > > 23:39:49,035 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > > 23:39:49,036 ERROR [ExecutionMessageDirector] The message key XXX cannot be > categorized since not started with job. nor step. > > 23:39:49,037 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > > 23:39:49,037 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > > 23:39:49,039 ERROR [ExecutionMessageDirector] Message key job.ABC is not > valid for enum VdcActionType > > 23:39:49,040 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > > 23:39:49,042 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > > 23:39:49,044 ERROR [ExecutionMessageDirector] Message key step.XYZ is not > valid for enum StepEnum > > 23:39:49,044 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec > > Running org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtilsTest > > 23:39:49,431 WARN [LocalConfig] The file > "/usr/share/ovirt-engine/conf/engine.conf.defaults" doesn't exist or isn't > readable. Will return an empty set of properties. > > 23:39:49,431 WARN [LocalConfig] The file "/etc/ovirt-engine/engine.conf" > doesn't exist or isn't readable. Will return an empty set of properties. > > 23:39:49,432 ERROR [LocalConfig] The property "ENGINE_DB_CONNECTION_TIMEOUT" > doesn't have a value. > > 23:39:49,433 WARN [DbFacadeLocator] Can't load connection checking parameters > of DB facade, will continue using the default values. > > java.lang.IllegalArgumentException: The property > "ENGINE_DB_CONNECTION_TIMEOUT" doesn't have a value. > > at org.ovirt.engine.core.utils.LocalConfig.getProperty(LocalConfig.java:234) > > at org.ovirt.engine.core.utils.LocalConfig.getInteger(LocalConfig.java:293) > > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.loadDbFacadeConfig(DbFacadeLocator.java:177) > > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.createDbFacade(DbFacadeLocator.java:62) > > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.getDbFacade(DbFacadeLocator.java:47) > > at > org.ovirt.engine.core.dao.BaseDAOTestCase.initTestCase(BaseDAOTestCase.java:66) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:601) > > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > > at > org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > > at > org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71) > > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) > > at org.junit.rules.RunRules.evaluate(RunRules.java:18) > > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > > at > org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174) > > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:601) > > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > > 23:39:49,830 WARN [SQLErrorCodesFactory] Error while extracting database > product name - falling back to empty error codes > > org.springframework.jdbc.support.MetaDataAccessException: Could not get > Connection for extracting meta data; nested exception is > org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get > JDBC Connection; nested exception is org.postgresql.util.PSQLException: > FATAL: database "engine_test" does not exist > > at > org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:293) > > at > org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:320) > > at > org.springframework.jdbc.support.SQLErrorCodesFactory.getErrorCodes(SQLErrorCodesFactory.java:214) > > at > org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.setDataSource(SQLErrorCodeSQLExceptionTranslator.java:141) > > at > org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.(SQLErrorCodeSQLExceptionTranslator.java:104) > > at > org.ovirt.engine.core.dal.dbbroker.CustomSQLErrorCodeSQLExceptionTranslator.(CustomSQLErrorCodeSQLExceptionTranslator.java:10) > > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.createDbFacade(DbFacadeLocator.java:79) > > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.getDbFacade(DbFacadeLocator.java:47) > > at > org.ovirt.engine.core.dao.BaseDAOTestCase.initTestCase(BaseDAOTestCase.java:66) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:601) > > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > > at > org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > > at > org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71) > > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) > > at org.junit.rules.RunRules.evaluate(RunRules.java:18) > > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > > at > org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174) > > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:601) > > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > > Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: Could > not get JDBC Connection; nested exception is > org.postgresql.util.PSQLException: FATAL: database "engine_test" does not > exist > > at > org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:80) > > at > org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:280) > > ... 34 more > > Caused by: org.postgresql.util.PSQLException: FATAL: database "engine_test" > does not exist > > at > org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:471) > > at > org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:112) > > at > org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66) > > at > org.postgresql.jdbc2.AbstractJdbc2Connection.(AbstractJdbc2Connection.java:125) > > at > org.postgresql.jdbc3.AbstractJdbc3Connection.(AbstractJdbc3Connection.java:30) > > at > org.postgresql.jdbc3g.AbstractJdbc3gConnection.(AbstractJdbc3gConnection.java:22) > > at > org.postgresql.jdbc4.AbstractJdbc4Connection.(AbstractJdbc4Connection.java:32) > > at org.postgresql.jdbc4.Jdbc4Connection.(Jdbc4Connection.java:24) > > at org.postgresql.Driver.makeConnection(Driver.java:393) > > at org.postgresql.Driver.connect(Driver.java:267) > > at java.sql.DriverManager.getConnection(DriverManager.java:579) > > at java.sql.DriverManager.getConnection(DriverManager.java:190) > > at > org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriverManager(DriverManagerDataSource.java:173) > > at > org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriver(DriverManagerDataSource.java:164) > > at > org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getConnectionFromDriver(AbstractDriverBasedDataSource.java:149) > > at > org.springframework.jdbc.datasource.SingleConnectionDataSource.initConnection(SingleConnectionDataSource.java:244) > > at > org.springframework.jdbc.datasource.SingleConnectionDataSource.getConnection(SingleConnectionDataSource.java:186) > > at > org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111) > > at > org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77) > > ... 35 more > > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.804 sec <<< > FAILURE! > > Running org.ovirt.engine.core.dal.dbbroker.generic.DomainsPasswordMapTest > > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.219 sec > > Running org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBaseTest > > Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec > > Running > org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirectorTest > > 23:39:50,102 INFO [AuditLogDirector] AuditLogType: UNASSIGNED not exist in > string table > > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: > USER_RUN_UNLOCK_ENTITY_SCRIPT not exist in string table > > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: > VDS_NETWORK_MTU_DIFFER_FROM_LOGICAL_NETWORK not exist in string table > > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: STORAGE_ACTIVATE_ASYNC not > exist in string table > > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: DWH_STOPPED not exist in > string table > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: DWH_STARTED not exist in > string table > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: DWH_ERROR not exist in > string table > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_NORMAL not > exist in string table > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_WARNING not > exist in string table > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_ERROR not > exist in string table > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_ALERT not exist > in string table > > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: USER_ATTACH_DISK_TO_VM not > have severity. Assumed Normal > > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: USER_DETACH_DISK_FROM_VM > not have severity. Assumed Normal > > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: > USER_FAILED_DETACH_DISK_FROM_VM not have severity. Assumed Normal > > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: > USER_RUN_UNLOCK_ENTITY_SCRIPT not have severity. Assumed Normal > > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > GLUSTER_VOLUME_OPTION_CHANGED_FROM_CLI not have severity. Assumed Normal > > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > VM_MIGRATION_START_SYSTEM_INITIATED not have severity. Assumed Normal > > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > VDS_NETWORK_MTU_DIFFER_FROM_LOGICAL_NETWORK not have severity. Assumed > Normal > > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > NETWORK_UPDATE_VM_INTERFACE_LINK_UP not have severity. Assumed Normal > > 23:39:50,111 WARN [AuditLogDirector] AuditLogType: > NETWORK_UPDATE_VM_INTERFACE_LINK_DOWN not have severity. Assumed Normal > > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.103 sec > > Running > org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBaseTest > > 23:39:50,289 INFO [AuditLogableBase] Failed to get vds > 11111111-1111-1111-1111-111111111113 > > null > > 23:39:50,293 INFO [AuditLogableBase] Failed to get vds > 11111111-1111-1111-1111-111111111113 > > null > > 23:39:50,311 INFO [AuditLogableBase] Failed to get vm > 11111111-1111-1111-1111-111111111113 > > Tests run: 113, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.145 sec > > Running org.ovirt.engine.core.dal.dbbroker.CustomMapSqlParameterSourceTest > > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec > > Running org.ovirt.engine.core.DuplicateKeysTest > > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec > > > > > Results : > > > > > Tests in error: > > org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtilsTest: FATAL: database > "engine_test" does not exist > > > > > Tests run: 168, Failures: 0, Errors: 1, Skipped: 0 > > > > > [INFO] > ------------------------------------------------------------------------ > > [INFO] Reactor Summary: > > [INFO] > > [INFO] ovirt-root ........................................ SUCCESS [0.672s] > > [INFO] oVirt Build Tools root ............................ SUCCESS [0.062s] > > [INFO] oVirt checkstyle .................................. SUCCESS [2.132s] > > [INFO] oVirt JBoss Modules Maven Plugin .................. SUCCESS [51.899s] > > [INFO] oVirt Checkstyle Checks ........................... SUCCESS [1.420s] > > [INFO] oVirt Modules - backend ........................... SUCCESS [0.019s] > > [INFO] oVirt Manager ..................................... SUCCESS [0.015s] > > [INFO] oVirt DB Scripts .................................. SUCCESS [0.316s] > > [INFO] oVirt Engine dependencies ......................... SUCCESS [4.173s] > > [INFO] oVirt Modules - manager ........................... SUCCESS [1.352s] > > [INFO] CSharp Compatibility .............................. SUCCESS [3.588s] > > [INFO] Common Code ....................................... SUCCESS [13.706s] > > [INFO] Common utilities .................................. SUCCESS [17.133s] > > [INFO] Data Access Layer ................................. FAILURE [8.885s] > > [INFO] engine scheduler bean ............................. SKIPPED > > [INFO] Vds broker ........................................ SKIPPED > > [INFO] Search Backend .................................... SKIPPED > > [INFO] Backend Logic @Service bean ....................... SKIPPED > > [INFO] oVirt RESTful API Backend Integration ............. SKIPPED > > [INFO] oVirt RESTful API interface ....................... SKIPPED > > [INFO] oVirt Engine API Definition ....................... SKIPPED > > [INFO] oVirt Engine API Commom Parent POM ................ SKIPPED > > [INFO] oVirt Engine API Common JAX-RS .................... SKIPPED > > [INFO] oVirt RESTful API Backend Integration Type Mappers SKIPPED > > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources SKIPPED > > [INFO] oVirt RESTful API Backend Integration Webapp ...... SKIPPED > > [INFO] oVirt Engine Web Root ............................. SKIPPED > > [INFO] oVirt Engine Tools ................................ SKIPPED > > [INFO] oVirt Modules :: Frontend ......................... SKIPPED > > [INFO] oVirt Modules :: Webadmin ......................... SKIPPED > > [INFO] oVirt Modules - ui ................................ SKIPPED > > [INFO] Extensions for GWT ................................ SKIPPED > > [INFO] UI Utils Compatibility (for UICommon) ............. SKIPPED > > [INFO] Frontend for GWT UI Projects ...................... SKIPPED > > [INFO] UICommonWeb ....................................... SKIPPED > > [INFO] oVirt GWT UI common infrastructure ................ SKIPPED > > [INFO] WebAdmin .......................................... SKIPPED > > [INFO] UserPortal ........................................ SKIPPED > > [INFO] oVirt Server EAR .................................. SKIPPED > > [INFO] > ------------------------------------------------------------------------ > > [INFO] BUILD FAILURE > > [INFO] > ------------------------------------------------------------------------ > > [INFO] Total time: 1:47.204s > > [INFO] Finished at: Wed Apr 17 23:39:50 CST 2013 > > [INFO] Final Memory: 70M/291M > > [INFO] > ------------------------------------------------------------------------ > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.10:test (default-test) on > project dal: There are test failures. > > [ERROR] > > [ERROR] Please refer to > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports > for the individual test results. > > [ERROR] -> [Help 1] > > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-surefire-plugin:2.10:test (default-test) > on project dal: There are test failures. > > > > > Please refer to > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports > for the individual test results. > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:158) > > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:601) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > > Caused by: org.apache.maven.plugin.MojoFailureException: There are test > failures. > > > > > Please refer to > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports > for the individual test results. > > at > org.apache.maven.plugin.surefire.SurefireHelper.reportExecution(SurefireHelper.java:87) > > at > org.apache.maven.plugin.surefire.SurefirePlugin.writeSummary(SurefirePlugin.java:641) > > at > org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:615) > > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:137) > > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:98) > > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > > ... 19 more > > [ERROR] > > [ERROR] > > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > > [ERROR] > > [ERROR] After correcting the problems, you can resume the build with the > command > > [ERROR] mvn -rf :dal > > [liqiang at localhost ovirt-engine]$ > > ========================================================== > > > > > _______________________________________________ > 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 liqiang.net at gmail.com Thu Apr 18 06:07:51 2013 From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=) Date: Thu, 18 Apr 2013 14:07:51 +0800 Subject: [Engine-devel] How get all language WebAdm ? In-Reply-To: <2144919614.2043029.1366263635770.JavaMail.root@redhat.com> References: <15900704.TebiEUGJZG@awels> <2144919614.2043029.1366263635770.JavaMail.root@redhat.com> Message-ID: HI:All I am Sorry that "-Dskipte=true" is my input error, Sorry to all. Thank to Alexander Wels. I git fetch and I have complie the source and success. thanks to all, thank, liqiang HI?All ????? --- ??????????? ?? ------------------------------------------------------------------------------ + ????????????????(????1:1) + ------------------------------------------------------------------------------ 2013/4/18 Laszlo Hornyak > > > ----- Original Message ----- > > From: "??" > > To: awels at redhat.com > > Cc: engine-devel at ovirt.org > > Sent: Wednesday, April 17, 2013 5:57:36 PM > > Subject: Re: [Engine-devel] How get all language WebAdm ? > > > > We should submit the bug to ovirt ? > > > > I think that maybe is config file error but I not be sure. > > Hi, > > No, it is maven-related. Maven ignores tests with -DskipTests but not with > "-Dskipte=true" and then you do not have a test environment set up. > It looks like a typo, not a bug :) > > > > > HI?All > > > > ????? > > > > --- > > ??????????? > > ?? > > > > > ------------------------------------------------------------------------------ > > > > + ????????????????(????1:1) + > > > ------------------------------------------------------------------------------ > > > > > > 2013/4/17 Alexander Wels < awels at redhat.com > > > > > > > > > > > > > I am having the same error locally right now. Someone broke the unit > tests, > > they should get fixed sooner or later. For now just skip the tests when > > building with -DskipTests > > > > > > > > > > On Wednesday, April 17, 2013 11:44:04 PM ?? wrote: > > > > > > HI:All > > > > > > > > > > This is my logs, thanks, > > > > > > > > > > ========================================================== > > > > ------------------------------------------------------- > > > > T E S T S > > > > ------------------------------------------------------- > > > > Forking command line: /bin/sh -c cd > > /home/liqiang/ovirt-engine/backend/manager/modules/dal && > > /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/bin/java -jar > > > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefirebooter4261523418572089603.jar > > > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefire7472834543455719312tmp > > > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefire5281802986683589703tmp > > > > Running org.ovirt.engine.core.dao.DaoFactoryTest > > > > Tests run: 24, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.262 > sec > > > > Running org.ovirt.engine.core.dal.job.ExecutionMessageDirectorTest > > > > 23:39:49,030 INFO [ExecutionMessageDirector] Start initializing > > ExecutionMessageDirector > > > > 23:39:49,032 ERROR [ExecutionMessageDirector] Message key > job.AddDiskToVm is > > not valid for enum VdcActionType > > > > 23:39:49,033 INFO [ExecutionMessageDirector] Finished initializing > > ExecutionMessageDirector > > > > 23:39:49,033 INFO [ExecutionMessageDirector] Start initializing > > ExecutionMessageDirector > > > > 23:39:49,034 ERROR [ExecutionMessageDirector] Message key > job.AddDiskToVm is > > not valid for enum VdcActionType > > > > 23:39:49,034 INFO [ExecutionMessageDirector] Finished initializing > > ExecutionMessageDirector > > > > 23:39:49,034 WARN [ExecutionMessageDirector] The message key Unknown is > > missing from bundles/ExecutionMessages > > > > 23:39:49,035 INFO [ExecutionMessageDirector] Start initializing > > ExecutionMessageDirector > > > > 23:39:49,036 ERROR [ExecutionMessageDirector] The message key XXX cannot > be > > categorized since not started with job. nor step. > > > > 23:39:49,037 INFO [ExecutionMessageDirector] Finished initializing > > ExecutionMessageDirector > > > > 23:39:49,037 INFO [ExecutionMessageDirector] Start initializing > > ExecutionMessageDirector > > > > 23:39:49,039 ERROR [ExecutionMessageDirector] Message key job.ABC is not > > valid for enum VdcActionType > > > > 23:39:49,040 INFO [ExecutionMessageDirector] Finished initializing > > ExecutionMessageDirector > > > > 23:39:49,042 INFO [ExecutionMessageDirector] Start initializing > > ExecutionMessageDirector > > > > 23:39:49,044 ERROR [ExecutionMessageDirector] Message key step.XYZ is not > > valid for enum StepEnum > > > > 23:39:49,044 INFO [ExecutionMessageDirector] Finished initializing > > ExecutionMessageDirector > > > > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec > > > > Running org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtilsTest > > > > 23:39:49,431 WARN [LocalConfig] The file > > "/usr/share/ovirt-engine/conf/engine.conf.defaults" doesn't exist or > isn't > > readable. Will return an empty set of properties. > > > > 23:39:49,431 WARN [LocalConfig] The file "/etc/ovirt-engine/engine.conf" > > doesn't exist or isn't readable. Will return an empty set of properties. > > > > 23:39:49,432 ERROR [LocalConfig] The property > "ENGINE_DB_CONNECTION_TIMEOUT" > > doesn't have a value. > > > > 23:39:49,433 WARN [DbFacadeLocator] Can't load connection checking > parameters > > of DB facade, will continue using the default values. > > > > java.lang.IllegalArgumentException: The property > > "ENGINE_DB_CONNECTION_TIMEOUT" doesn't have a value. > > > > at > org.ovirt.engine.core.utils.LocalConfig.getProperty(LocalConfig.java:234) > > > > at > org.ovirt.engine.core.utils.LocalConfig.getInteger(LocalConfig.java:293) > > > > at > > > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.loadDbFacadeConfig(DbFacadeLocator.java:177) > > > > at > > > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.createDbFacade(DbFacadeLocator.java:62) > > > > at > > > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.getDbFacade(DbFacadeLocator.java:47) > > > > at > > > org.ovirt.engine.core.dao.BaseDAOTestCase.initTestCase(BaseDAOTestCase.java:66) > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(Method.java:601) > > > > at > > > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > > > > at > > > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > > > > at > > > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > > > > at > > > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > > > > at > > > org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > > > > at > > > org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71) > > > > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) > > > > at org.junit.rules.RunRules.evaluate(RunRules.java:18) > > > > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > > > > at > > > org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174) > > > > at > > > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > > > > at > > > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > > > > at > > > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(Method.java:601) > > > > at > > > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > > > > at > > > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > > > > at > > > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > > > > at > > > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > > > > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > > > > 23:39:49,830 WARN [SQLErrorCodesFactory] Error while extracting database > > product name - falling back to empty error codes > > > > org.springframework.jdbc.support.MetaDataAccessException: Could not get > > Connection for extracting meta data; nested exception is > > org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get > > JDBC Connection; nested exception is org.postgresql.util.PSQLException: > > FATAL: database "engine_test" does not exist > > > > at > > > org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:293) > > > > at > > > org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:320) > > > > at > > > org.springframework.jdbc.support.SQLErrorCodesFactory.getErrorCodes(SQLErrorCodesFactory.java:214) > > > > at > > > org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.setDataSource(SQLErrorCodeSQLExceptionTranslator.java:141) > > > > at > > > org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.(SQLErrorCodeSQLExceptionTranslator.java:104) > > > > at > > > org.ovirt.engine.core.dal.dbbroker.CustomSQLErrorCodeSQLExceptionTranslator.(CustomSQLErrorCodeSQLExceptionTranslator.java:10) > > > > at > > > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.createDbFacade(DbFacadeLocator.java:79) > > > > at > > > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.getDbFacade(DbFacadeLocator.java:47) > > > > at > > > org.ovirt.engine.core.dao.BaseDAOTestCase.initTestCase(BaseDAOTestCase.java:66) > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(Method.java:601) > > > > at > > > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > > > > at > > > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > > > > at > > > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > > > > at > > > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > > > > at > > > org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > > > > at > > > org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71) > > > > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) > > > > at org.junit.rules.RunRules.evaluate(RunRules.java:18) > > > > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > > > > at > > > org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174) > > > > at > > > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > > > > at > > > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > > > > at > > > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(Method.java:601) > > > > at > > > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > > > > at > > > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > > > > at > > > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > > > > at > > > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > > > > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > > > > Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: > Could > > not get JDBC Connection; nested exception is > > org.postgresql.util.PSQLException: FATAL: database "engine_test" does not > > exist > > > > at > > > org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:80) > > > > at > > > org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:280) > > > > ... 34 more > > > > Caused by: org.postgresql.util.PSQLException: FATAL: database > "engine_test" > > does not exist > > > > at > > > org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:471) > > > > at > > > org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:112) > > > > at > > > org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66) > > > > at > > > org.postgresql.jdbc2.AbstractJdbc2Connection.(AbstractJdbc2Connection.java:125) > > > > at > > > org.postgresql.jdbc3.AbstractJdbc3Connection.(AbstractJdbc3Connection.java:30) > > > > at > > > org.postgresql.jdbc3g.AbstractJdbc3gConnection.(AbstractJdbc3gConnection.java:22) > > > > at > > > org.postgresql.jdbc4.AbstractJdbc4Connection.(AbstractJdbc4Connection.java:32) > > > > at org.postgresql.jdbc4.Jdbc4Connection.(Jdbc4Connection.java:24) > > > > at org.postgresql.Driver.makeConnection(Driver.java:393) > > > > at org.postgresql.Driver.connect(Driver.java:267) > > > > at java.sql.DriverManager.getConnection(DriverManager.java:579) > > > > at java.sql.DriverManager.getConnection(DriverManager.java:190) > > > > at > > > org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriverManager(DriverManagerDataSource.java:173) > > > > at > > > org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriver(DriverManagerDataSource.java:164) > > > > at > > > org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getConnectionFromDriver(AbstractDriverBasedDataSource.java:149) > > > > at > > > org.springframework.jdbc.datasource.SingleConnectionDataSource.initConnection(SingleConnectionDataSource.java:244) > > > > at > > > org.springframework.jdbc.datasource.SingleConnectionDataSource.getConnection(SingleConnectionDataSource.java:186) > > > > at > > > org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111) > > > > at > > > org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77) > > > > ... 35 more > > > > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.804 > sec <<< > > FAILURE! > > > > Running org.ovirt.engine.core.dal.dbbroker.generic.DomainsPasswordMapTest > > > > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.219 sec > > > > Running > org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBaseTest > > > > Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 > sec > > > > Running > > org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirectorTest > > > > 23:39:50,102 INFO [AuditLogDirector] AuditLogType: UNASSIGNED not exist > in > > string table > > > > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: > > USER_RUN_UNLOCK_ENTITY_SCRIPT not exist in string table > > > > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: > > VDS_NETWORK_MTU_DIFFER_FROM_LOGICAL_NETWORK not exist in string table > > > > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: > STORAGE_ACTIVATE_ASYNC not > > exist in string table > > > > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: DWH_STOPPED not exist > in > > string table > > > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: DWH_STARTED not exist > in > > string table > > > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: DWH_ERROR not exist in > > string table > > > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_NORMAL > not > > exist in string table > > > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: > EXTERNAL_EVENT_WARNING not > > exist in string table > > > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_ERROR > not > > exist in string table > > > > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_ALERT not > exist > > in string table > > > > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: > USER_ATTACH_DISK_TO_VM not > > have severity. Assumed Normal > > > > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: > USER_DETACH_DISK_FROM_VM > > not have severity. Assumed Normal > > > > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: > > USER_FAILED_DETACH_DISK_FROM_VM not have severity. Assumed Normal > > > > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: > > USER_RUN_UNLOCK_ENTITY_SCRIPT not have severity. Assumed Normal > > > > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > > GLUSTER_VOLUME_OPTION_CHANGED_FROM_CLI not have severity. Assumed Normal > > > > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > > VM_MIGRATION_START_SYSTEM_INITIATED not have severity. Assumed Normal > > > > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > > VDS_NETWORK_MTU_DIFFER_FROM_LOGICAL_NETWORK not have severity. Assumed > > Normal > > > > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > > NETWORK_UPDATE_VM_INTERFACE_LINK_UP not have severity. Assumed Normal > > > > 23:39:50,111 WARN [AuditLogDirector] AuditLogType: > > NETWORK_UPDATE_VM_INTERFACE_LINK_DOWN not have severity. Assumed Normal > > > > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.103 sec > > > > Running > > org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBaseTest > > > > 23:39:50,289 INFO [AuditLogableBase] Failed to get vds > > 11111111-1111-1111-1111-111111111113 > > > > null > > > > 23:39:50,293 INFO [AuditLogableBase] Failed to get vds > > 11111111-1111-1111-1111-111111111113 > > > > null > > > > 23:39:50,311 INFO [AuditLogableBase] Failed to get vm > > 11111111-1111-1111-1111-111111111113 > > > > Tests run: 113, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.145 > sec > > > > Running > org.ovirt.engine.core.dal.dbbroker.CustomMapSqlParameterSourceTest > > > > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec > > > > Running org.ovirt.engine.core.DuplicateKeysTest > > > > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec > > > > > > > > > > Results : > > > > > > > > > > Tests in error: > > > > org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtilsTest: FATAL: > database > > "engine_test" does not exist > > > > > > > > > > Tests run: 168, Failures: 0, Errors: 1, Skipped: 0 > > > > > > > > > > [INFO] > > ------------------------------------------------------------------------ > > > > [INFO] Reactor Summary: > > > > [INFO] > > > > [INFO] ovirt-root ........................................ SUCCESS > [0.672s] > > > > [INFO] oVirt Build Tools root ............................ SUCCESS > [0.062s] > > > > [INFO] oVirt checkstyle .................................. SUCCESS > [2.132s] > > > > [INFO] oVirt JBoss Modules Maven Plugin .................. SUCCESS > [51.899s] > > > > [INFO] oVirt Checkstyle Checks ........................... SUCCESS > [1.420s] > > > > [INFO] oVirt Modules - backend ........................... SUCCESS > [0.019s] > > > > [INFO] oVirt Manager ..................................... SUCCESS > [0.015s] > > > > [INFO] oVirt DB Scripts .................................. SUCCESS > [0.316s] > > > > [INFO] oVirt Engine dependencies ......................... SUCCESS > [4.173s] > > > > [INFO] oVirt Modules - manager ........................... SUCCESS > [1.352s] > > > > [INFO] CSharp Compatibility .............................. SUCCESS > [3.588s] > > > > [INFO] Common Code ....................................... SUCCESS > [13.706s] > > > > [INFO] Common utilities .................................. SUCCESS > [17.133s] > > > > [INFO] Data Access Layer ................................. FAILURE > [8.885s] > > > > [INFO] engine scheduler bean ............................. SKIPPED > > > > [INFO] Vds broker ........................................ SKIPPED > > > > [INFO] Search Backend .................................... SKIPPED > > > > [INFO] Backend Logic @Service bean ....................... SKIPPED > > > > [INFO] oVirt RESTful API Backend Integration ............. SKIPPED > > > > [INFO] oVirt RESTful API interface ....................... SKIPPED > > > > [INFO] oVirt Engine API Definition ....................... SKIPPED > > > > [INFO] oVirt Engine API Commom Parent POM ................ SKIPPED > > > > [INFO] oVirt Engine API Common JAX-RS .................... SKIPPED > > > > [INFO] oVirt RESTful API Backend Integration Type Mappers SKIPPED > > > > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources SKIPPED > > > > [INFO] oVirt RESTful API Backend Integration Webapp ...... SKIPPED > > > > [INFO] oVirt Engine Web Root ............................. SKIPPED > > > > [INFO] oVirt Engine Tools ................................ SKIPPED > > > > [INFO] oVirt Modules :: Frontend ......................... SKIPPED > > > > [INFO] oVirt Modules :: Webadmin ......................... SKIPPED > > > > [INFO] oVirt Modules - ui ................................ SKIPPED > > > > [INFO] Extensions for GWT ................................ SKIPPED > > > > [INFO] UI Utils Compatibility (for UICommon) ............. SKIPPED > > > > [INFO] Frontend for GWT UI Projects ...................... SKIPPED > > > > [INFO] UICommonWeb ....................................... SKIPPED > > > > [INFO] oVirt GWT UI common infrastructure ................ SKIPPED > > > > [INFO] WebAdmin .......................................... SKIPPED > > > > [INFO] UserPortal ........................................ SKIPPED > > > > [INFO] oVirt Server EAR .................................. SKIPPED > > > > [INFO] > > ------------------------------------------------------------------------ > > > > [INFO] BUILD FAILURE > > > > [INFO] > > ------------------------------------------------------------------------ > > > > [INFO] Total time: 1:47.204s > > > > [INFO] Finished at: Wed Apr 17 23:39:50 CST 2013 > > > > [INFO] Final Memory: 70M/291M > > > > [INFO] > > ------------------------------------------------------------------------ > > > > [ERROR] Failed to execute goal > > org.apache.maven.plugins:maven-surefire-plugin:2.10:test (default-test) > on > > project dal: There are test failures. > > > > [ERROR] > > > > [ERROR] Please refer to > > > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports > > for the individual test results. > > > > [ERROR] -> [Help 1] > > > > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > > goal org.apache.maven.plugins:maven-surefire-plugin:2.10:test > (default-test) > > on project dal: There are test failures. > > > > > > > > > > Please refer to > > > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports > > for the individual test results. > > > > at > > > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) > > > > at > > > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > > > > at > > > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > > > > at > > > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > > > > at > > > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > > > > at > > > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > > > > at > > > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > > > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > > > > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:158) > > > > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > > > > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > > > > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(Method.java:601) > > > > at > > > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > > > > at > > > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > > > > at > > > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > > > > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > > > > Caused by: org.apache.maven.plugin.MojoFailureException: There are test > > failures. > > > > > > > > > > Please refer to > > > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports > > for the individual test results. > > > > at > > > org.apache.maven.plugin.surefire.SurefireHelper.reportExecution(SurefireHelper.java:87) > > > > at > > > org.apache.maven.plugin.surefire.SurefirePlugin.writeSummary(SurefirePlugin.java:641) > > > > at > > > org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:615) > > > > at > > > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:137) > > > > at > > > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:98) > > > > at > > > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > > > > at > > > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > > > > ... 19 more > > > > [ERROR] > > > > [ERROR] > > > > [ERROR] For more information about the errors and possible solutions, > please > > read the following articles: > > > > [ERROR] [Help 1] > > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > > > > [ERROR] > > > > [ERROR] After correcting the problems, you can resume the build with the > > command > > > > [ERROR] mvn -rf :dal > > > > [liqiang at localhost ovirt-engine]$ > > > > ========================================================== > > > > > > > > > > _______________________________________________ > > 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: From wei.d.chen at intel.com Thu Apr 18 06:19:03 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Thu, 18 Apr 2013 06:19:03 +0000 Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: <516E9618.7010406@redhat.com> References: <996306366.2192571.1365595398217.JavaMail.root@redhat.com> <189243164.4209095.1366006840007.JavaMail.root@redhat.com> <516BA2E8.7090207@redhat.com> <448237996.384685.1366009557875.JavaMail.root@redhat.com> <1045509486.480916.1366023642593.JavaMail.root@redhat.com> <1308686351.886592.1366183406691.JavaMail.root@redhat.com> <516E9618.7010406@redhat.com> Message-ID: I think it's more sensible, the initial status should be the real status for this host (trusted / untrusted) only the untrusted host will be set to non-operational. we just need poll this host instead of all of the hosts in the cluster if this can be done in "InitVdsOnUpCommand", and we suppose this is the first time when this host add into the cluster. Follow these steps (conclusion based on your suggestion). - The first time when one host is added into a trust cluster then poll this host, the host will be in "up" status if get "trusted" result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - When host is down for a different reason and up again, we suppose "InitVdsOnUpCommand" will be triggered again (right?), so we will poll this host again to get the real status(trusted / untrusted). Then mark the host as up or non-operational. As a trusted host flip to untrusted and take effective only under the condition of this host has been hacked and rebooted, so we proposal no need to add periodic check if any host's reboot will invoke "InitVdsOnUpCommand" and we add attestation logic in "InitVdsOnUpCommand" is enough. My proposal would be like this (no periodic check is needed, will simply our integration) - The first time when one host is added into a trust cluster then poll this host, the host will be in "up" status if get "trusted" result from attestation server, or else, set this host as non-operational status. - The periodic check will poll all of the hosts only once as this will cut down a lot of time needed instead of poll each host one by one, this conclusion is based on our experiments because most of time consumed is in parallel. - (up -> nonoperationl / trusted -> untrusted)When host is down for a different reason and up again, we suppose "InitVdsOnUpCommand" will be triggered again (right?) and we also suppose the host will be non-operational if host is down for some reason (right), so we will poll this host again to get the real status(trusted / untrusted) after host's rebooting. - (nonoperationl -> up / untrusted -> trusted) Admin will activate this host manually after admin fix the issue of this host. Attestation logic will be added into "VdsManager:activate ()" as the clue you give me before. Any suggestion? Best Regards, Dave Chen -----Original Message----- From: Itamar Heim [mailto:iheim at redhat.com] Sent: Wednesday, April 17, 2013 8:31 PM To: Ofri Masad Cc: Chen, Wei D; Oved Ourfalli; engine-devel at ovirt.org Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 On 04/17/2013 10:23 AM, Ofri Masad wrote: > Hi Dave, > The VdsUpdateRunTimeInfo runs every 3 seconds or so. so it not a good place to call the attestation host. > Instead, like we suggested earlier, create a new Quartz job (like the one I've sent you in the QuotaManager class) which run every couple of minutes and update the hosts state. > You can also add the check to InitVdsOnUpCommand, so that if a host was down for a different reason, it will be rechecked for attestation. > You can add a UI to allow manual "refresh attestation". > so the new thread will poll all for all hosts and update the db, then during the normal monitoring "detect" the issue? > Ofri > > ----- Original Message ----- >> From: "Wei D Chen" >> To: "Omer Frenkel" , "Doron Fediuck" >> >> Cc: "Oved Ourfalli" , engine-devel at ovirt.org >> Sent: Monday, April 15, 2013 5:53:34 PM >> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation >> integration with oVirt in 4/9 >> >> Good approach, thanks all. How long it needs to invoke periodic check >> in the class of VdsUpdateRunTimeInfo? Whether this time configurable? >> My concern is if the initial status of each host added into trusted >> cluster is non-operational, we need wait a long time for the invoking >> of this periodic check, so a trusted host's with initial status of >> non-operational will take a long time to flip to a trusted host. >> >> As I have not seen the configuration of periodic check in >> VdsUpdateRunTimeInfo, would you give me some tips if you has some clue. >> Thanks a lot. >> >> Best Regards, >> Dave Chen >> >> -----Original Message----- >> From: engine-devel-bounces at ovirt.org >> [mailto:engine-devel-bounces at ovirt.org] >> On Behalf Of Omer Frenkel >> Sent: Monday, April 15, 2013 7:01 PM >> To: Doron Fediuck >> Cc: Oved Ourfalli; engine-devel at ovirt.org >> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation >> integration with oVirt in 4/9 >> >> >> >> ----- Original Message ----- >>> From: "Doron Fediuck" >>> To: "Itamar Heim" >>> Cc: "Oved Ourfalli" , engine-devel at ovirt.org >>> Sent: Monday, April 15, 2013 10:05:57 AM >>> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation >>> integration with oVirt in 4/9 >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Itamar Heim" >>>> To: "Oved Ourfalli" >>>> Cc: engine-devel at ovirt.org >>>> Sent: Monday, April 15, 2013 9:49:12 AM >>>> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation >>>> integration with oVirt in 4/9 >>>> >>>> On 04/15/2013 09:20 AM, Oved Ourfalli wrote: >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Wei D Chen" >>>>>> To: "Doron Fediuck" , "Ofri Masad" >>>>>> >>>>>> Cc: engine-devel at ovirt.org >>>>>> Sent: Monday, April 15, 2013 8:54:18 AM >>>>>> Subject: Re: [Engine-devel] minutes for sync up on Open >>>>>> Attestation integration with oVirt in 4/9 >>>>>> >>>>>> Hi Doron and Ofri, >>>>>> >>>>>> Thanks for your reply, here is some other question. >>>>>> >>>>>> ii. When adding a host into the trusted cluster, the host will >>>>>> be attested via OAT service, only trusted hosted can be added. >>>>>> >>>>>> Would you also kindly tell me if there is any mandatory logic >>>>>> check when adding a host into a cluster, so we can also put >>>>>> attestation logic with these mandatory check together? Some >>>>>> example or code location is better. >>>>>> Thanks a lot. >>>>>> >>>>> >>>>> I think there are two approaches, depending on the use case. >>>>> #1: >>>>> If the host trusted property is static, then you can narrow the >>>>> tests to two locations: >>>>> * AddVdsCommand - (Vds = Host) - This command is triggered when a >>>>> new host is added to the system. You can use the canDoAction >>>>> method (which we have on all commands, and it determines whether >>>>> an action can be run or not), and there, if cluster requires >>>>> trusted hosts only, you can test whether this host is trusted or >>>>> not. >>>>> * ChangeVdsClusterCommand - this command is used when you change >>>>> the cluster of a host. So, if the target cluster requires tursted >>>>> hosts, you can do a similar test in its canDoAction method. >>>>> >>>>> #2: >>>>> If the host trusted property can change, then I'd suggest using >>>>> the NonOperational property of a host. >>>>> We have a class called VdsUpdateRunTimeInfo that does periodic >>>>> tests of hosts, deciding what's their status, according to >>>>> specific flags. >>>>> The code there is quite complex, and would require refactoring at >>>>> some point, but in the meantime you can use the MonitoringStrategy >>>>> interface that is being used there, and implement a new monitoring >>>>> strategy for Open Attestation. >>>>> >>>>> There, in the processHardwareCapabilities, you can test that the >>>>> host is trusted. >>>>> >>>>> When creating the strategy, using the MonitoringStrategyFactory, >>>>> you'll need to create the appropriate strategy. >>>>> Currently we support either virt strategy or gluster strategy or >>>>> both. In your case you would need virt+attestation / >>>>> gluster+attestation / >>>>> virt+gluster+attestation, according to the services deployed on >>>>> virt+gluster+the >>>>> cluster. >>>> >>>> I'd go with the 2nd approach. i.e., not block the host from being >>>> added, only from being used, based on monitoring / non-op status >>>> >>> +1. >>> It means that the admin can add the host, but the host will not be >>> operational until we get a positive indication from the attestation >>> service. >>> >> +1 >> if we want to test attestation only once, every time before host moves to up. >> the right place for it, imo, is InitVdsOnUpCommand if its periodic >> also after host is up, then it should be somewhere in the monitoring >> code >> >>>> >>>>> >>>>> >>>>> Does that make sense? >>>>> Doron and Ofri, what did you have in mind for this feature? >>>>> >>>>> Regards, >>>>> Oved >>>>> >>>>>> >>>>>> Best Regards, >>>>>> Dave Chen >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Doron Fediuck [mailto:dfediuck at redhat.com] >>>>>> Sent: Wednesday, April 10, 2013 8:03 PM >>>>>> To: Ofri Masad >>>>>> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan >>>>>> Subject: Re: minutes for sync up on Open Attestation integration >>>>>> with oVirt in 4/9 >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Ofri Masad" >>>>>>> To: "Gang Wei" >>>>>>> Cc: "Wei D Chen" , "Buddy Cao" >>>>>>> , "Lijuan Zhang" , >>>>>>> "Doron Fediuck" >>>>>>> Sent: Wednesday, April 10, 2013 2:23:57 PM >>>>>>> Subject: Re: minutes for sync up on Open Attestation integration >>>>>>> with oVirt in 4/9 >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> answers inside the mail body. >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Doron Fediuck" >>>>>>>> To: "Wei D Chen" >>>>>>>> Cc: "Gang Wei" , "Buddy Cao" >>>>>>>> , "Lijuan Zhang" , >>>>>>>> "Ofri Masad" >>>>>>>> Sent: Wednesday, April 10, 2013 12:12:26 PM >>>>>>>> Subject: Re: minutes for sync up on Open Attestation >>>>>>>> integration with oVirt in 4/9 >>>>>>>> >>>>>>>> Hi Dave, >>>>>>>> Adding Ofri to answer your questions. >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Wei D Chen" >>>>>>>>> To: "Gang Wei" , "Doron Fediuck" >>>>>>>>> , >>>>>>>>> "Buddy Cao" , "Lijuan Zhang" >>>>>>>>> >>>>>>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM >>>>>>>>> Subject: RE: minutes for sync up on Open Attestation >>>>>>>>> integration with oVirt in 4/9 >>>>>>>>> >>>>>>>>> Hi Doron, >>>>>>>>> >>>>>>>>> >>>>>>>>> iii. Then periodic trust check will be added into background >>>>>>>>> process >>>>>>>>> for >>>>>>>>> all existing hosts, once becoming non-trusted, mark it as >>>>>>>>> non-operational. >>>>>>>>> >>>>>>>>> - [Dave] Would you give me some details about the >>>>>>>>> ?background >>>>>>>>> process? mentioned in our sync up meeting? What?s the process >>>>>>>>> and where is related code? >>>>>>>>> >>>>>>> >>>>>>> The use Quartz Job to scheduled background processes. >>>>>>> An example can be found in: >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: >>>>>>> 222) >>>>>>> >>>>>>> This code calls a method that is located in: >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt >>>>>>> /engin e/core/bll/quota/QuotaManager.java >>>>>>> (Line: 1000) >>>>>>> the @OnTimerMethodAnnotation annotation and the unique job name >>>>>>> connects the two in runtime. >>>>>>> >>>>>>> The job can query the attestation server for all the host and >>>>>>> then set untrusted hosts to Non-Operational. >>>>>>> the best way would be to call SetNonOperationalVdsCommand with a >>>>>>> new NonOperationalReason. >>>>>>> This command tries to migrate all VMs from the host and then set >>>>>>> it non operational. >>>>>>> (We need to think about non-migrational VMs - should we close >>>>>>> those VMs or keep the host running) >>>>>>> >>>>>> >>>>>> One more thing you may want to consider; If we get a positive >>>>>> response for a host which is currently non-operational, issue an >>>>>> activate command to try and make it operational again. >>>>>> Alternatively, you may decide not to handle it, assuming >>>>>> untrusted hosts can only be activated manually (see below Ofri's >>>>>> response on activating a host). >>>>>> >>>>>>>>> >>>>>>>>> iv. If admin fixed the non-operational node and try to switch >>>>>>>>> it >>>>>>>>> to >>>>>>>>> operational mode again, a trust check will happen to gate the >>>>>>>>> switching. >>>>>>>>> >>>>>>>>> - [Dave] If there is a button provided from UI for >>>>>>>>> checking >>>>>>>>> the >>>>>>>>> logic? or we need add an extra-button for attestation check only? >>>>>>>>> >>>>>>> >>>>>>> In the UI we already have the "Activate" option. What still >>>>>>> needs to be added is the check with the attestation provider to >>>>>>> make sure that if the cluster is defined 'Trusted'. If so, only >>>>>>> trusted host will succeed in the activate command (and, of >>>>>>> course, a proper Audit Log error in case the host failed to >>>>>>> activate due to trust issue. >>>>>>> >>>>>>> the correct place to add this check would be in: >>>>>>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/org >>>>>>> /ovirt >>>>>>> /engine/core/vdsbroker/VdsManager.java:activate() >>>>>>> this is where the re-activation process begins. >>>>>>> >>>>>>>>> >>>>>>>>> Thanks very much. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Dave Chen >>>>>> _______________________________________________ >>>>>> 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 >>> >> _______________________________________________ >> 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 omasad at redhat.com Thu Apr 18 06:38:26 2013 From: omasad at redhat.com (Ofri Masad) Date: Thu, 18 Apr 2013 02:38:26 -0400 (EDT) Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: References: <516BA2E8.7090207@redhat.com> <448237996.384685.1366009557875.JavaMail.root@redhat.com> <1045509486.480916.1366023642593.JavaMail.root@redhat.com> <1308686351.886592.1366183406691.JavaMail.root@redhat.com> <516E9618.7010406@redhat.com> Message-ID: <746655980.1215862.1366267106372.JavaMail.root@redhat.com> Hi Dave, Can't a host become untrusted without being rebooted? If that is really the case, there is no need for a periodic check - the trigger for the check would be the host rebooting (which is visible to the engine). Thanks, Ofri ----- Original Message ----- > From: "Wei D Chen" > To: "Itamar Heim" , "Ofri Masad" > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > Sent: Thursday, April 18, 2013 9:19:03 AM > Subject: RE: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 > > I think it's more sensible, the initial status should be the real status for > this host (trusted / untrusted) only the untrusted host will be set to > non-operational. > we just need poll this host instead of all of the hosts in the cluster if > this can be done in "InitVdsOnUpCommand", and we suppose this is the first > time when this host add into the cluster. > Follow these steps (conclusion based on your suggestion). > > - The first time when one host is added into a trust cluster then poll this > host, the host will be in "up" status if get "trusted" result from > attestation server, or else, set this host as non-operational status. > - The periodic check will poll all of the hosts only once as this will cut > down a lot of time needed instead of poll each host one by one, this > conclusion is based on our experiments because most of time consumed is in > parallel. > - When host is down for a different reason and up again, we suppose > "InitVdsOnUpCommand" will be triggered again (right?), so we will poll this > host again to get the real status(trusted / untrusted). Then mark the host > as up or non-operational. > > As a trusted host flip to untrusted and take effective only under the > condition of this host has been hacked and rebooted, so we proposal no need > to add periodic check if any host's reboot will invoke "InitVdsOnUpCommand" > and we add attestation logic in "InitVdsOnUpCommand" is enough. > > My proposal would be like this (no periodic check is needed, will simply our > integration) > > - The first time when one host is added into a trust cluster then poll this > host, the host will be in "up" status if get "trusted" result from > attestation server, or else, set this host as non-operational status. > - The periodic check will poll all of the hosts only once as this will cut > down a lot of time needed instead of poll each host one by one, this > conclusion is based on our experiments because most of time consumed is in > parallel. > - (up -> nonoperationl / trusted -> untrusted)When host is down for a > different reason and up again, we suppose "InitVdsOnUpCommand" will be > triggered again (right?) and we also suppose the host will be > non-operational if host is down for some reason (right), so we will poll > this host again to get the real status(trusted / untrusted) after host's > rebooting. > - (nonoperationl -> up / untrusted -> trusted) Admin will activate this host > manually after admin fix the issue of this host. Attestation logic will be > added into "VdsManager:activate ()" as the clue you give me before. > > Any suggestion? > > Best Regards, > Dave Chen > > > -----Original Message----- > From: Itamar Heim [mailto:iheim at redhat.com] > Sent: Wednesday, April 17, 2013 8:31 PM > To: Ofri Masad > Cc: Chen, Wei D; Oved Ourfalli; engine-devel at ovirt.org > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > integration with oVirt in 4/9 > > On 04/17/2013 10:23 AM, Ofri Masad wrote: > > Hi Dave, > > The VdsUpdateRunTimeInfo runs every 3 seconds or so. so it not a good place > > to call the attestation host. > > Instead, like we suggested earlier, create a new Quartz job (like the one > > I've sent you in the QuotaManager class) which run every couple of minutes > > and update the hosts state. > > You can also add the check to InitVdsOnUpCommand, so that if a host was > > down for a different reason, it will be rechecked for attestation. > > You can add a UI to allow manual "refresh attestation". > > > > so the new thread will poll all for all hosts and update the db, then during > the normal monitoring "detect" the issue? > > > Ofri > > > > ----- Original Message ----- > >> From: "Wei D Chen" > >> To: "Omer Frenkel" , "Doron Fediuck" > >> > >> Cc: "Oved Ourfalli" , engine-devel at ovirt.org > >> Sent: Monday, April 15, 2013 5:53:34 PM > >> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > >> integration with oVirt in 4/9 > >> > >> Good approach, thanks all. How long it needs to invoke periodic check > >> in the class of VdsUpdateRunTimeInfo? Whether this time configurable? > >> My concern is if the initial status of each host added into trusted > >> cluster is non-operational, we need wait a long time for the invoking > >> of this periodic check, so a trusted host's with initial status of > >> non-operational will take a long time to flip to a trusted host. > >> > >> As I have not seen the configuration of periodic check in > >> VdsUpdateRunTimeInfo, would you give me some tips if you has some clue. > >> Thanks a lot. > >> > >> Best Regards, > >> Dave Chen > >> > >> -----Original Message----- > >> From: engine-devel-bounces at ovirt.org > >> [mailto:engine-devel-bounces at ovirt.org] > >> On Behalf Of Omer Frenkel > >> Sent: Monday, April 15, 2013 7:01 PM > >> To: Doron Fediuck > >> Cc: Oved Ourfalli; engine-devel at ovirt.org > >> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > >> integration with oVirt in 4/9 > >> > >> > >> > >> ----- Original Message ----- > >>> From: "Doron Fediuck" > >>> To: "Itamar Heim" > >>> Cc: "Oved Ourfalli" , engine-devel at ovirt.org > >>> Sent: Monday, April 15, 2013 10:05:57 AM > >>> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > >>> integration with oVirt in 4/9 > >>> > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Itamar Heim" > >>>> To: "Oved Ourfalli" > >>>> Cc: engine-devel at ovirt.org > >>>> Sent: Monday, April 15, 2013 9:49:12 AM > >>>> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > >>>> integration with oVirt in 4/9 > >>>> > >>>> On 04/15/2013 09:20 AM, Oved Ourfalli wrote: > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Wei D Chen" > >>>>>> To: "Doron Fediuck" , "Ofri Masad" > >>>>>> > >>>>>> Cc: engine-devel at ovirt.org > >>>>>> Sent: Monday, April 15, 2013 8:54:18 AM > >>>>>> Subject: Re: [Engine-devel] minutes for sync up on Open > >>>>>> Attestation integration with oVirt in 4/9 > >>>>>> > >>>>>> Hi Doron and Ofri, > >>>>>> > >>>>>> Thanks for your reply, here is some other question. > >>>>>> > >>>>>> ii. When adding a host into the trusted cluster, the host will > >>>>>> be attested via OAT service, only trusted hosted can be added. > >>>>>> > >>>>>> Would you also kindly tell me if there is any mandatory logic > >>>>>> check when adding a host into a cluster, so we can also put > >>>>>> attestation logic with these mandatory check together? Some > >>>>>> example or code location is better. > >>>>>> Thanks a lot. > >>>>>> > >>>>> > >>>>> I think there are two approaches, depending on the use case. > >>>>> #1: > >>>>> If the host trusted property is static, then you can narrow the > >>>>> tests to two locations: > >>>>> * AddVdsCommand - (Vds = Host) - This command is triggered when a > >>>>> new host is added to the system. You can use the canDoAction > >>>>> method (which we have on all commands, and it determines whether > >>>>> an action can be run or not), and there, if cluster requires > >>>>> trusted hosts only, you can test whether this host is trusted or > >>>>> not. > >>>>> * ChangeVdsClusterCommand - this command is used when you change > >>>>> the cluster of a host. So, if the target cluster requires tursted > >>>>> hosts, you can do a similar test in its canDoAction method. > >>>>> > >>>>> #2: > >>>>> If the host trusted property can change, then I'd suggest using > >>>>> the NonOperational property of a host. > >>>>> We have a class called VdsUpdateRunTimeInfo that does periodic > >>>>> tests of hosts, deciding what's their status, according to > >>>>> specific flags. > >>>>> The code there is quite complex, and would require refactoring at > >>>>> some point, but in the meantime you can use the MonitoringStrategy > >>>>> interface that is being used there, and implement a new monitoring > >>>>> strategy for Open Attestation. > >>>>> > >>>>> There, in the processHardwareCapabilities, you can test that the > >>>>> host is trusted. > >>>>> > >>>>> When creating the strategy, using the MonitoringStrategyFactory, > >>>>> you'll need to create the appropriate strategy. > >>>>> Currently we support either virt strategy or gluster strategy or > >>>>> both. In your case you would need virt+attestation / > >>>>> gluster+attestation / > >>>>> virt+gluster+attestation, according to the services deployed on > >>>>> virt+gluster+the > >>>>> cluster. > >>>> > >>>> I'd go with the 2nd approach. i.e., not block the host from being > >>>> added, only from being used, based on monitoring / non-op status > >>>> > >>> +1. > >>> It means that the admin can add the host, but the host will not be > >>> operational until we get a positive indication from the attestation > >>> service. > >>> > >> +1 > >> if we want to test attestation only once, every time before host moves to > >> up. > >> the right place for it, imo, is InitVdsOnUpCommand if its periodic > >> also after host is up, then it should be somewhere in the monitoring > >> code > >> > >>>> > >>>>> > >>>>> > >>>>> Does that make sense? > >>>>> Doron and Ofri, what did you have in mind for this feature? > >>>>> > >>>>> Regards, > >>>>> Oved > >>>>> > >>>>>> > >>>>>> Best Regards, > >>>>>> Dave Chen > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Doron Fediuck [mailto:dfediuck at redhat.com] > >>>>>> Sent: Wednesday, April 10, 2013 8:03 PM > >>>>>> To: Ofri Masad > >>>>>> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan > >>>>>> Subject: Re: minutes for sync up on Open Attestation integration > >>>>>> with oVirt in 4/9 > >>>>>> > >>>>>> > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Ofri Masad" > >>>>>>> To: "Gang Wei" > >>>>>>> Cc: "Wei D Chen" , "Buddy Cao" > >>>>>>> , "Lijuan Zhang" , > >>>>>>> "Doron Fediuck" > >>>>>>> Sent: Wednesday, April 10, 2013 2:23:57 PM > >>>>>>> Subject: Re: minutes for sync up on Open Attestation integration > >>>>>>> with oVirt in 4/9 > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> answers inside the mail body. > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> From: "Doron Fediuck" > >>>>>>>> To: "Wei D Chen" > >>>>>>>> Cc: "Gang Wei" , "Buddy Cao" > >>>>>>>> , "Lijuan Zhang" , > >>>>>>>> "Ofri Masad" > >>>>>>>> Sent: Wednesday, April 10, 2013 12:12:26 PM > >>>>>>>> Subject: Re: minutes for sync up on Open Attestation > >>>>>>>> integration with oVirt in 4/9 > >>>>>>>> > >>>>>>>> Hi Dave, > >>>>>>>> Adding Ofri to answer your questions. > >>>>>>>> > >>>>>>>> ----- Original Message ----- > >>>>>>>>> From: "Wei D Chen" > >>>>>>>>> To: "Gang Wei" , "Doron Fediuck" > >>>>>>>>> , > >>>>>>>>> "Buddy Cao" , "Lijuan Zhang" > >>>>>>>>> > >>>>>>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM > >>>>>>>>> Subject: RE: minutes for sync up on Open Attestation > >>>>>>>>> integration with oVirt in 4/9 > >>>>>>>>> > >>>>>>>>> Hi Doron, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> iii. Then periodic trust check will be added into background > >>>>>>>>> process > >>>>>>>>> for > >>>>>>>>> all existing hosts, once becoming non-trusted, mark it as > >>>>>>>>> non-operational. > >>>>>>>>> > >>>>>>>>> - [Dave] Would you give me some details about the > >>>>>>>>> ?background > >>>>>>>>> process? mentioned in our sync up meeting? What?s the process > >>>>>>>>> and where is related code? > >>>>>>>>> > >>>>>>> > >>>>>>> The use Quartz Job to scheduled background processes. > >>>>>>> An example can be found in: > >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > >>>>>>> 222) > >>>>>>> > >>>>>>> This code calls a method that is located in: > >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt > >>>>>>> /engin e/core/bll/quota/QuotaManager.java > >>>>>>> (Line: 1000) > >>>>>>> the @OnTimerMethodAnnotation annotation and the unique job name > >>>>>>> connects the two in runtime. > >>>>>>> > >>>>>>> The job can query the attestation server for all the host and > >>>>>>> then set untrusted hosts to Non-Operational. > >>>>>>> the best way would be to call SetNonOperationalVdsCommand with a > >>>>>>> new NonOperationalReason. > >>>>>>> This command tries to migrate all VMs from the host and then set > >>>>>>> it non operational. > >>>>>>> (We need to think about non-migrational VMs - should we close > >>>>>>> those VMs or keep the host running) > >>>>>>> > >>>>>> > >>>>>> One more thing you may want to consider; If we get a positive > >>>>>> response for a host which is currently non-operational, issue an > >>>>>> activate command to try and make it operational again. > >>>>>> Alternatively, you may decide not to handle it, assuming > >>>>>> untrusted hosts can only be activated manually (see below Ofri's > >>>>>> response on activating a host). > >>>>>> > >>>>>>>>> > >>>>>>>>> iv. If admin fixed the non-operational node and try to switch > >>>>>>>>> it > >>>>>>>>> to > >>>>>>>>> operational mode again, a trust check will happen to gate the > >>>>>>>>> switching. > >>>>>>>>> > >>>>>>>>> - [Dave] If there is a button provided from UI for > >>>>>>>>> checking > >>>>>>>>> the > >>>>>>>>> logic? or we need add an extra-button for attestation check only? > >>>>>>>>> > >>>>>>> > >>>>>>> In the UI we already have the "Activate" option. What still > >>>>>>> needs to be added is the check with the attestation provider to > >>>>>>> make sure that if the cluster is defined 'Trusted'. If so, only > >>>>>>> trusted host will succeed in the activate command (and, of > >>>>>>> course, a proper Audit Log error in case the host failed to > >>>>>>> activate due to trust issue. > >>>>>>> > >>>>>>> the correct place to add this check would be in: > >>>>>>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/org > >>>>>>> /ovirt > >>>>>>> /engine/core/vdsbroker/VdsManager.java:activate() > >>>>>>> this is where the re-activation process begins. > >>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks very much. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Best Regards, > >>>>>>>>> Dave Chen > >>>>>> _______________________________________________ > >>>>>> 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 > >>> > >> _______________________________________________ > >> 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 ofrenkel at redhat.com Thu Apr 18 07:19:49 2013 From: ofrenkel at redhat.com (Omer Frenkel) Date: Thu, 18 Apr 2013 03:19:49 -0400 (EDT) Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: <746655980.1215862.1366267106372.JavaMail.root@redhat.com> References: <448237996.384685.1366009557875.JavaMail.root@redhat.com> <1045509486.480916.1366023642593.JavaMail.root@redhat.com> <1308686351.886592.1366183406691.JavaMail.root@redhat.com> <516E9618.7010406@redhat.com> <746655980.1215862.1366267106372.JavaMail.root@redhat.com> Message-ID: <1673217119.2659279.1366269589775.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Ofri Masad" > To: "Wei D Chen" > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > Sent: Thursday, April 18, 2013 9:38:26 AM > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 > > Hi Dave, > > Can't a host become untrusted without being rebooted? > If that is really the case, there is no need for a periodic check - the > trigger for the check would be the host rebooting (which is visible to the > engine). > +1 > Thanks, > Ofri > > ----- Original Message ----- > > From: "Wei D Chen" > > To: "Itamar Heim" , "Ofri Masad" > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > Sent: Thursday, April 18, 2013 9:19:03 AM > > Subject: RE: [Engine-devel] minutes for sync up on Open Attestation > > integration with oVirt in 4/9 > > > > I think it's more sensible, the initial status should be the real status > > for > > this host (trusted / untrusted) only the untrusted host will be set to > > non-operational. > > we just need poll this host instead of all of the hosts in the cluster if > > this can be done in "InitVdsOnUpCommand", and we suppose this is the first > > time when this host add into the cluster. > > Follow these steps (conclusion based on your suggestion). > > > > - The first time when one host is added into a trust cluster then poll this > > host, the host will be in "up" status if get "trusted" result from > > attestation server, or else, set this host as non-operational status. > > - The periodic check will poll all of the hosts only once as this will cut > > down a lot of time needed instead of poll each host one by one, this > > conclusion is based on our experiments because most of time consumed is in > > parallel. > > - When host is down for a different reason and up again, we suppose > > "InitVdsOnUpCommand" will be triggered again (right?), so we will poll this > > host again to get the real status(trusted / untrusted). Then mark the host > > as up or non-operational. right > > > > As a trusted host flip to untrusted and take effective only under the > > condition of this host has been hacked and rebooted, so we proposal no need > > to add periodic check if any host's reboot will invoke "InitVdsOnUpCommand" > > and we add attestation logic in "InitVdsOnUpCommand" is enough. > > > > My proposal would be like this (no periodic check is needed, will simply > > our > > integration) > > > > - The first time when one host is added into a trust cluster then poll this > > host, the host will be in "up" status if get "trusted" result from > > attestation server, or else, set this host as non-operational status. > > - The periodic check will poll all of the hosts only once as this will cut > > down a lot of time needed instead of poll each host one by one, this > > conclusion is based on our experiments because most of time consumed is in > > parallel. > > - (up -> nonoperationl / trusted -> untrusted)When host is down for a > > different reason and up again, we suppose "InitVdsOnUpCommand" will be > > triggered again (right?) and we also suppose the host will be > > non-operational if host is down for some reason (right), so we will poll > > this host again to get the real status(trusted / untrusted) after host's > > rebooting. > > - (nonoperationl -> up / untrusted -> trusted) Admin will activate this > > host > > manually after admin fix the issue of this host. Attestation logic will be > > added into "VdsManager:activate ()" as the clue you give me before. > > > > Any suggestion? > > > > Best Regards, > > Dave Chen > > > > > > -----Original Message----- > > From: Itamar Heim [mailto:iheim at redhat.com] > > Sent: Wednesday, April 17, 2013 8:31 PM > > To: Ofri Masad > > Cc: Chen, Wei D; Oved Ourfalli; engine-devel at ovirt.org > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > integration with oVirt in 4/9 > > > > On 04/17/2013 10:23 AM, Ofri Masad wrote: > > > Hi Dave, > > > The VdsUpdateRunTimeInfo runs every 3 seconds or so. so it not a good > > > place > > > to call the attestation host. > > > Instead, like we suggested earlier, create a new Quartz job (like the one > > > I've sent you in the QuotaManager class) which run every couple of > > > minutes > > > and update the hosts state. > > > You can also add the check to InitVdsOnUpCommand, so that if a host was > > > down for a different reason, it will be rechecked for attestation. > > > You can add a UI to allow manual "refresh attestation". > > > > > > > so the new thread will poll all for all hosts and update the db, then > > during > > the normal monitoring "detect" the issue? > > > > > Ofri > > > > > > ----- Original Message ----- > > >> From: "Wei D Chen" > > >> To: "Omer Frenkel" , "Doron Fediuck" > > >> > > >> Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > >> Sent: Monday, April 15, 2013 5:53:34 PM > > >> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > >> integration with oVirt in 4/9 > > >> > > >> Good approach, thanks all. How long it needs to invoke periodic check > > >> in the class of VdsUpdateRunTimeInfo? Whether this time configurable? > > >> My concern is if the initial status of each host added into trusted > > >> cluster is non-operational, we need wait a long time for the invoking > > >> of this periodic check, so a trusted host's with initial status of > > >> non-operational will take a long time to flip to a trusted host. > > >> > > >> As I have not seen the configuration of periodic check in > > >> VdsUpdateRunTimeInfo, would you give me some tips if you has some clue. > > >> Thanks a lot. > > >> > > >> Best Regards, > > >> Dave Chen > > >> > > >> -----Original Message----- > > >> From: engine-devel-bounces at ovirt.org > > >> [mailto:engine-devel-bounces at ovirt.org] > > >> On Behalf Of Omer Frenkel > > >> Sent: Monday, April 15, 2013 7:01 PM > > >> To: Doron Fediuck > > >> Cc: Oved Ourfalli; engine-devel at ovirt.org > > >> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > >> integration with oVirt in 4/9 > > >> > > >> > > >> > > >> ----- Original Message ----- > > >>> From: "Doron Fediuck" > > >>> To: "Itamar Heim" > > >>> Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > >>> Sent: Monday, April 15, 2013 10:05:57 AM > > >>> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > >>> integration with oVirt in 4/9 > > >>> > > >>> > > >>> > > >>> ----- Original Message ----- > > >>>> From: "Itamar Heim" > > >>>> To: "Oved Ourfalli" > > >>>> Cc: engine-devel at ovirt.org > > >>>> Sent: Monday, April 15, 2013 9:49:12 AM > > >>>> Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > >>>> integration with oVirt in 4/9 > > >>>> > > >>>> On 04/15/2013 09:20 AM, Oved Ourfalli wrote: > > >>>>> > > >>>>> > > >>>>> ----- Original Message ----- > > >>>>>> From: "Wei D Chen" > > >>>>>> To: "Doron Fediuck" , "Ofri Masad" > > >>>>>> > > >>>>>> Cc: engine-devel at ovirt.org > > >>>>>> Sent: Monday, April 15, 2013 8:54:18 AM > > >>>>>> Subject: Re: [Engine-devel] minutes for sync up on Open > > >>>>>> Attestation integration with oVirt in 4/9 > > >>>>>> > > >>>>>> Hi Doron and Ofri, > > >>>>>> > > >>>>>> Thanks for your reply, here is some other question. > > >>>>>> > > >>>>>> ii. When adding a host into the trusted cluster, the host will > > >>>>>> be attested via OAT service, only trusted hosted can be added. > > >>>>>> > > >>>>>> Would you also kindly tell me if there is any mandatory logic > > >>>>>> check when adding a host into a cluster, so we can also put > > >>>>>> attestation logic with these mandatory check together? Some > > >>>>>> example or code location is better. > > >>>>>> Thanks a lot. > > >>>>>> > > >>>>> > > >>>>> I think there are two approaches, depending on the use case. > > >>>>> #1: > > >>>>> If the host trusted property is static, then you can narrow the > > >>>>> tests to two locations: > > >>>>> * AddVdsCommand - (Vds = Host) - This command is triggered when a > > >>>>> new host is added to the system. You can use the canDoAction > > >>>>> method (which we have on all commands, and it determines whether > > >>>>> an action can be run or not), and there, if cluster requires > > >>>>> trusted hosts only, you can test whether this host is trusted or > > >>>>> not. > > >>>>> * ChangeVdsClusterCommand - this command is used when you change > > >>>>> the cluster of a host. So, if the target cluster requires tursted > > >>>>> hosts, you can do a similar test in its canDoAction method. > > >>>>> > > >>>>> #2: > > >>>>> If the host trusted property can change, then I'd suggest using > > >>>>> the NonOperational property of a host. > > >>>>> We have a class called VdsUpdateRunTimeInfo that does periodic > > >>>>> tests of hosts, deciding what's their status, according to > > >>>>> specific flags. > > >>>>> The code there is quite complex, and would require refactoring at > > >>>>> some point, but in the meantime you can use the MonitoringStrategy > > >>>>> interface that is being used there, and implement a new monitoring > > >>>>> strategy for Open Attestation. > > >>>>> > > >>>>> There, in the processHardwareCapabilities, you can test that the > > >>>>> host is trusted. > > >>>>> > > >>>>> When creating the strategy, using the MonitoringStrategyFactory, > > >>>>> you'll need to create the appropriate strategy. > > >>>>> Currently we support either virt strategy or gluster strategy or > > >>>>> both. In your case you would need virt+attestation / > > >>>>> gluster+attestation / > > >>>>> virt+gluster+attestation, according to the services deployed on > > >>>>> virt+gluster+the > > >>>>> cluster. > > >>>> > > >>>> I'd go with the 2nd approach. i.e., not block the host from being > > >>>> added, only from being used, based on monitoring / non-op status > > >>>> > > >>> +1. > > >>> It means that the admin can add the host, but the host will not be > > >>> operational until we get a positive indication from the attestation > > >>> service. > > >>> > > >> +1 > > >> if we want to test attestation only once, every time before host moves > > >> to > > >> up. > > >> the right place for it, imo, is InitVdsOnUpCommand if its periodic > > >> also after host is up, then it should be somewhere in the monitoring > > >> code > > >> > > >>>> > > >>>>> > > >>>>> > > >>>>> Does that make sense? > > >>>>> Doron and Ofri, what did you have in mind for this feature? > > >>>>> > > >>>>> Regards, > > >>>>> Oved > > >>>>> > > >>>>>> > > >>>>>> Best Regards, > > >>>>>> Dave Chen > > >>>>>> > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Doron Fediuck [mailto:dfediuck at redhat.com] > > >>>>>> Sent: Wednesday, April 10, 2013 8:03 PM > > >>>>>> To: Ofri Masad > > >>>>>> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan > > >>>>>> Subject: Re: minutes for sync up on Open Attestation integration > > >>>>>> with oVirt in 4/9 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> ----- Original Message ----- > > >>>>>>> From: "Ofri Masad" > > >>>>>>> To: "Gang Wei" > > >>>>>>> Cc: "Wei D Chen" , "Buddy Cao" > > >>>>>>> , "Lijuan Zhang" , > > >>>>>>> "Doron Fediuck" > > >>>>>>> Sent: Wednesday, April 10, 2013 2:23:57 PM > > >>>>>>> Subject: Re: minutes for sync up on Open Attestation integration > > >>>>>>> with oVirt in 4/9 > > >>>>>>> > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>> answers inside the mail body. > > >>>>>>> > > >>>>>>> ----- Original Message ----- > > >>>>>>>> From: "Doron Fediuck" > > >>>>>>>> To: "Wei D Chen" > > >>>>>>>> Cc: "Gang Wei" , "Buddy Cao" > > >>>>>>>> , "Lijuan Zhang" , > > >>>>>>>> "Ofri Masad" > > >>>>>>>> Sent: Wednesday, April 10, 2013 12:12:26 PM > > >>>>>>>> Subject: Re: minutes for sync up on Open Attestation > > >>>>>>>> integration with oVirt in 4/9 > > >>>>>>>> > > >>>>>>>> Hi Dave, > > >>>>>>>> Adding Ofri to answer your questions. > > >>>>>>>> > > >>>>>>>> ----- Original Message ----- > > >>>>>>>>> From: "Wei D Chen" > > >>>>>>>>> To: "Gang Wei" , "Doron Fediuck" > > >>>>>>>>> , > > >>>>>>>>> "Buddy Cao" , "Lijuan Zhang" > > >>>>>>>>> > > >>>>>>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM > > >>>>>>>>> Subject: RE: minutes for sync up on Open Attestation > > >>>>>>>>> integration with oVirt in 4/9 > > >>>>>>>>> > > >>>>>>>>> Hi Doron, > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> iii. Then periodic trust check will be added into background > > >>>>>>>>> process > > >>>>>>>>> for > > >>>>>>>>> all existing hosts, once becoming non-trusted, mark it as > > >>>>>>>>> non-operational. > > >>>>>>>>> > > >>>>>>>>> - [Dave] Would you give me some details about the > > >>>>>>>>> ?background > > >>>>>>>>> process? mentioned in our sync up meeting? What?s the process > > >>>>>>>>> and where is related code? > > >>>>>>>>> > > >>>>>>> > > >>>>>>> The use Quartz Job to scheduled background processes. > > >>>>>>> An example can be found in: > > >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > > >>>>>>> 222) > > >>>>>>> > > >>>>>>> This code calls a method that is located in: > > >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt > > >>>>>>> /engin e/core/bll/quota/QuotaManager.java > > >>>>>>> (Line: 1000) > > >>>>>>> the @OnTimerMethodAnnotation annotation and the unique job name > > >>>>>>> connects the two in runtime. > > >>>>>>> > > >>>>>>> The job can query the attestation server for all the host and > > >>>>>>> then set untrusted hosts to Non-Operational. > > >>>>>>> the best way would be to call SetNonOperationalVdsCommand with a > > >>>>>>> new NonOperationalReason. > > >>>>>>> This command tries to migrate all VMs from the host and then set > > >>>>>>> it non operational. > > >>>>>>> (We need to think about non-migrational VMs - should we close > > >>>>>>> those VMs or keep the host running) > > >>>>>>> > > >>>>>> > > >>>>>> One more thing you may want to consider; If we get a positive > > >>>>>> response for a host which is currently non-operational, issue an > > >>>>>> activate command to try and make it operational again. > > >>>>>> Alternatively, you may decide not to handle it, assuming > > >>>>>> untrusted hosts can only be activated manually (see below Ofri's > > >>>>>> response on activating a host). > > >>>>>> > > >>>>>>>>> > > >>>>>>>>> iv. If admin fixed the non-operational node and try to switch > > >>>>>>>>> it > > >>>>>>>>> to > > >>>>>>>>> operational mode again, a trust check will happen to gate the > > >>>>>>>>> switching. > > >>>>>>>>> > > >>>>>>>>> - [Dave] If there is a button provided from UI for > > >>>>>>>>> checking > > >>>>>>>>> the > > >>>>>>>>> logic? or we need add an extra-button for attestation check only? > > >>>>>>>>> > > >>>>>>> > > >>>>>>> In the UI we already have the "Activate" option. What still > > >>>>>>> needs to be added is the check with the attestation provider to > > >>>>>>> make sure that if the cluster is defined 'Trusted'. If so, only > > >>>>>>> trusted host will succeed in the activate command (and, of > > >>>>>>> course, a proper Audit Log error in case the host failed to > > >>>>>>> activate due to trust issue. > > >>>>>>> > > >>>>>>> the correct place to add this check would be in: > > >>>>>>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java/org > > >>>>>>> /ovirt > > >>>>>>> /engine/core/vdsbroker/VdsManager.java:activate() > > >>>>>>> this is where the re-activation process begins. > > >>>>>>> > > >>>>>>>>> > > >>>>>>>>> Thanks very much. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Best Regards, > > >>>>>>>>> Dave Chen > > >>>>>> _______________________________________________ > > >>>>>> 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 > > >>> > > >> _______________________________________________ > > >> 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 wei.d.chen at intel.com Thu Apr 18 07:42:10 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Thu, 18 Apr 2013 07:42:10 +0000 Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: <1673217119.2659279.1366269589775.JavaMail.root@redhat.com> References: <448237996.384685.1366009557875.JavaMail.root@redhat.com> <1045509486.480916.1366023642593.JavaMail.root@redhat.com> <1308686351.886592.1366183406691.JavaMail.root@redhat.com> <516E9618.7010406@redhat.com> <746655980.1215862.1366267106372.JavaMail.root@redhat.com> <1673217119.2659279.1366269589775.JavaMail.root@redhat.com> Message-ID: Yes, the host must be rebooted to take effect. Doron, what do you think? Best Regards, Dave Chen -----Original Message----- From: Omer Frenkel [mailto:ofrenkel at redhat.com] Sent: Thursday, April 18, 2013 3:20 PM To: Ofri Masad Cc: Chen, Wei D; Oved Ourfalli; engine-devel at ovirt.org Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 ----- Original Message ----- > From: "Ofri Masad" > To: "Wei D Chen" > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > Sent: Thursday, April 18, 2013 9:38:26 AM > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > integration with oVirt in 4/9 > > Hi Dave, > > Can't a host become untrusted without being rebooted? > If that is really the case, there is no need for a periodic check - > the trigger for the check would be the host rebooting (which is > visible to the engine). > +1 > Thanks, > Ofri > > ----- Original Message ----- > > From: "Wei D Chen" > > To: "Itamar Heim" , "Ofri Masad" > > > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > Sent: Thursday, April 18, 2013 9:19:03 AM > > Subject: RE: [Engine-devel] minutes for sync up on Open Attestation > > integration with oVirt in 4/9 > > > > I think it's more sensible, the initial status should be the real > > status for this host (trusted / untrusted) only the untrusted host > > will be set to non-operational. > > we just need poll this host instead of all of the hosts in the > > cluster if this can be done in "InitVdsOnUpCommand", and we suppose > > this is the first time when this host add into the cluster. > > Follow these steps (conclusion based on your suggestion). > > > > - The first time when one host is added into a trust cluster then poll this > > host, the host will be in "up" status if get "trusted" result from > > attestation server, or else, set this host as non-operational status. > > - The periodic check will poll all of the hosts only once as this will cut > > down a lot of time needed instead of poll each host one by one, this > > conclusion is based on our experiments because most of time consumed > > is in parallel. > > - When host is down for a different reason and up again, we suppose > > "InitVdsOnUpCommand" will be triggered again (right?), so we will > > poll this host again to get the real status(trusted / untrusted). > > Then mark the host as up or non-operational. right > > > > As a trusted host flip to untrusted and take effective only under > > the condition of this host has been hacked and rebooted, so we > > proposal no need to add periodic check if any host's reboot will invoke "InitVdsOnUpCommand" > > and we add attestation logic in "InitVdsOnUpCommand" is enough. > > > > My proposal would be like this (no periodic check is needed, will > > simply our > > integration) > > > > - The first time when one host is added into a trust cluster then poll this > > host, the host will be in "up" status if get "trusted" result from > > attestation server, or else, set this host as non-operational status. > > - The periodic check will poll all of the hosts only once as this will cut > > down a lot of time needed instead of poll each host one by one, this > > conclusion is based on our experiments because most of time consumed > > is in parallel. > > - (up -> nonoperationl / trusted -> untrusted)When host is down for a > > different reason and up again, we suppose "InitVdsOnUpCommand" will > > be triggered again (right?) and we also suppose the host will be > > non-operational if host is down for some reason (right), so we will > > poll this host again to get the real status(trusted / untrusted) > > after host's rebooting. > > - (nonoperationl -> up / untrusted -> trusted) Admin will activate this > > host > > manually after admin fix the issue of this host. Attestation logic > > will be added into "VdsManager:activate ()" as the clue you give me before. > > > > Any suggestion? > > > > Best Regards, > > Dave Chen > > > > > > -----Original Message----- > > From: Itamar Heim [mailto:iheim at redhat.com] > > Sent: Wednesday, April 17, 2013 8:31 PM > > To: Ofri Masad > > Cc: Chen, Wei D; Oved Ourfalli; engine-devel at ovirt.org > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > integration with oVirt in 4/9 > > > > On 04/17/2013 10:23 AM, Ofri Masad wrote: > > > Hi Dave, > > > The VdsUpdateRunTimeInfo runs every 3 seconds or so. so it not a > > > good place to call the attestation host. > > > Instead, like we suggested earlier, create a new Quartz job (like > > > the one I've sent you in the QuotaManager class) which run every > > > couple of minutes and update the hosts state. > > > You can also add the check to InitVdsOnUpCommand, so that if a > > > host was down for a different reason, it will be rechecked for attestation. > > > You can add a UI to allow manual "refresh attestation". > > > > > > > so the new thread will poll all for all hosts and update the db, > > then during the normal monitoring "detect" the issue? > > > > > Ofri > > > > > > ----- Original Message ----- > > >> From: "Wei D Chen" > > >> To: "Omer Frenkel" , "Doron Fediuck" > > >> > > >> Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > >> Sent: Monday, April 15, 2013 5:53:34 PM > > >> Subject: Re: [Engine-devel] minutes for sync up on Open > > >> Attestation integration with oVirt in 4/9 > > >> > > >> Good approach, thanks all. How long it needs to invoke periodic > > >> check in the class of VdsUpdateRunTimeInfo? Whether this time configurable? > > >> My concern is if the initial status of each host added into > > >> trusted cluster is non-operational, we need wait a long time for > > >> the invoking of this periodic check, so a trusted host's with > > >> initial status of non-operational will take a long time to flip to a trusted host. > > >> > > >> As I have not seen the configuration of periodic check in > > >> VdsUpdateRunTimeInfo, would you give me some tips if you has some clue. > > >> Thanks a lot. > > >> > > >> Best Regards, > > >> Dave Chen > > >> > > >> -----Original Message----- > > >> From: engine-devel-bounces at ovirt.org > > >> [mailto:engine-devel-bounces at ovirt.org] > > >> On Behalf Of Omer Frenkel > > >> Sent: Monday, April 15, 2013 7:01 PM > > >> To: Doron Fediuck > > >> Cc: Oved Ourfalli; engine-devel at ovirt.org > > >> Subject: Re: [Engine-devel] minutes for sync up on Open > > >> Attestation integration with oVirt in 4/9 > > >> > > >> > > >> > > >> ----- Original Message ----- > > >>> From: "Doron Fediuck" > > >>> To: "Itamar Heim" > > >>> Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > >>> Sent: Monday, April 15, 2013 10:05:57 AM > > >>> Subject: Re: [Engine-devel] minutes for sync up on Open > > >>> Attestation integration with oVirt in 4/9 > > >>> > > >>> > > >>> > > >>> ----- Original Message ----- > > >>>> From: "Itamar Heim" > > >>>> To: "Oved Ourfalli" > > >>>> Cc: engine-devel at ovirt.org > > >>>> Sent: Monday, April 15, 2013 9:49:12 AM > > >>>> Subject: Re: [Engine-devel] minutes for sync up on Open > > >>>> Attestation integration with oVirt in 4/9 > > >>>> > > >>>> On 04/15/2013 09:20 AM, Oved Ourfalli wrote: > > >>>>> > > >>>>> > > >>>>> ----- Original Message ----- > > >>>>>> From: "Wei D Chen" > > >>>>>> To: "Doron Fediuck" , "Ofri Masad" > > >>>>>> > > >>>>>> Cc: engine-devel at ovirt.org > > >>>>>> Sent: Monday, April 15, 2013 8:54:18 AM > > >>>>>> Subject: Re: [Engine-devel] minutes for sync up on Open > > >>>>>> Attestation integration with oVirt in 4/9 > > >>>>>> > > >>>>>> Hi Doron and Ofri, > > >>>>>> > > >>>>>> Thanks for your reply, here is some other question. > > >>>>>> > > >>>>>> ii. When adding a host into the trusted cluster, the host > > >>>>>> will be attested via OAT service, only trusted hosted can be added. > > >>>>>> > > >>>>>> Would you also kindly tell me if there is any mandatory logic > > >>>>>> check when adding a host into a cluster, so we can also put > > >>>>>> attestation logic with these mandatory check together? Some > > >>>>>> example or code location is better. > > >>>>>> Thanks a lot. > > >>>>>> > > >>>>> > > >>>>> I think there are two approaches, depending on the use case. > > >>>>> #1: > > >>>>> If the host trusted property is static, then you can narrow > > >>>>> the tests to two locations: > > >>>>> * AddVdsCommand - (Vds = Host) - This command is triggered > > >>>>> when a new host is added to the system. You can use the > > >>>>> canDoAction method (which we have on all commands, and it > > >>>>> determines whether an action can be run or not), and there, if > > >>>>> cluster requires trusted hosts only, you can test whether this > > >>>>> host is trusted or not. > > >>>>> * ChangeVdsClusterCommand - this command is used when you > > >>>>> change the cluster of a host. So, if the target cluster > > >>>>> requires tursted hosts, you can do a similar test in its canDoAction method. > > >>>>> > > >>>>> #2: > > >>>>> If the host trusted property can change, then I'd suggest > > >>>>> using the NonOperational property of a host. > > >>>>> We have a class called VdsUpdateRunTimeInfo that does periodic > > >>>>> tests of hosts, deciding what's their status, according to > > >>>>> specific flags. > > >>>>> The code there is quite complex, and would require refactoring > > >>>>> at some point, but in the meantime you can use the > > >>>>> MonitoringStrategy interface that is being used there, and > > >>>>> implement a new monitoring strategy for Open Attestation. > > >>>>> > > >>>>> There, in the processHardwareCapabilities, you can test that > > >>>>> the host is trusted. > > >>>>> > > >>>>> When creating the strategy, using the > > >>>>> MonitoringStrategyFactory, you'll need to create the appropriate strategy. > > >>>>> Currently we support either virt strategy or gluster strategy > > >>>>> or both. In your case you would need virt+attestation / > > >>>>> gluster+attestation / > > >>>>> virt+gluster+attestation, according to the services deployed > > >>>>> virt+gluster+on the > > >>>>> cluster. > > >>>> > > >>>> I'd go with the 2nd approach. i.e., not block the host from > > >>>> being added, only from being used, based on monitoring / non-op > > >>>> status > > >>>> > > >>> +1. > > >>> It means that the admin can add the host, but the host will not > > >>> be operational until we get a positive indication from the > > >>> attestation service. > > >>> > > >> +1 > > >> if we want to test attestation only once, every time before host > > >> moves to up. > > >> the right place for it, imo, is InitVdsOnUpCommand if its > > >> periodic also after host is up, then it should be somewhere in > > >> the monitoring code > > >> > > >>>> > > >>>>> > > >>>>> > > >>>>> Does that make sense? > > >>>>> Doron and Ofri, what did you have in mind for this feature? > > >>>>> > > >>>>> Regards, > > >>>>> Oved > > >>>>> > > >>>>>> > > >>>>>> Best Regards, > > >>>>>> Dave Chen > > >>>>>> > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Doron Fediuck [mailto:dfediuck at redhat.com] > > >>>>>> Sent: Wednesday, April 10, 2013 8:03 PM > > >>>>>> To: Ofri Masad > > >>>>>> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan > > >>>>>> Subject: Re: minutes for sync up on Open Attestation > > >>>>>> integration with oVirt in 4/9 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> ----- Original Message ----- > > >>>>>>> From: "Ofri Masad" > > >>>>>>> To: "Gang Wei" > > >>>>>>> Cc: "Wei D Chen" , "Buddy Cao" > > >>>>>>> , "Lijuan Zhang" > > >>>>>>> , "Doron Fediuck" > > >>>>>>> > > >>>>>>> Sent: Wednesday, April 10, 2013 2:23:57 PM > > >>>>>>> Subject: Re: minutes for sync up on Open Attestation > > >>>>>>> integration with oVirt in 4/9 > > >>>>>>> > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>> answers inside the mail body. > > >>>>>>> > > >>>>>>> ----- Original Message ----- > > >>>>>>>> From: "Doron Fediuck" > > >>>>>>>> To: "Wei D Chen" > > >>>>>>>> Cc: "Gang Wei" , "Buddy Cao" > > >>>>>>>> , "Lijuan Zhang" > > >>>>>>>> , "Ofri Masad" > > >>>>>>>> Sent: Wednesday, April 10, 2013 12:12:26 PM > > >>>>>>>> Subject: Re: minutes for sync up on Open Attestation > > >>>>>>>> integration with oVirt in 4/9 > > >>>>>>>> > > >>>>>>>> Hi Dave, > > >>>>>>>> Adding Ofri to answer your questions. > > >>>>>>>> > > >>>>>>>> ----- Original Message ----- > > >>>>>>>>> From: "Wei D Chen" > > >>>>>>>>> To: "Gang Wei" , "Doron Fediuck" > > >>>>>>>>> , > > >>>>>>>>> "Buddy Cao" , "Lijuan Zhang" > > >>>>>>>>> > > >>>>>>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM > > >>>>>>>>> Subject: RE: minutes for sync up on Open Attestation > > >>>>>>>>> integration with oVirt in 4/9 > > >>>>>>>>> > > >>>>>>>>> Hi Doron, > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> iii. Then periodic trust check will be added into background > > >>>>>>>>> process > > >>>>>>>>> for > > >>>>>>>>> all existing hosts, once becoming non-trusted, mark it as > > >>>>>>>>> non-operational. > > >>>>>>>>> > > >>>>>>>>> - [Dave] Would you give me some details about the > > >>>>>>>>> ?background > > >>>>>>>>> process? mentioned in our sync up meeting? What?s the > > >>>>>>>>> process and where is related code? > > >>>>>>>>> > > >>>>>>> > > >>>>>>> The use Quartz Job to scheduled background processes. > > >>>>>>> An example can be found in: > > >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > > >>>>>>> 222) > > >>>>>>> > > >>>>>>> This code calls a method that is located in: > > >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/o > > >>>>>>> virt /engin e/core/bll/quota/QuotaManager.java > > >>>>>>> (Line: 1000) > > >>>>>>> the @OnTimerMethodAnnotation annotation and the unique job > > >>>>>>> name connects the two in runtime. > > >>>>>>> > > >>>>>>> The job can query the attestation server for all the host > > >>>>>>> and then set untrusted hosts to Non-Operational. > > >>>>>>> the best way would be to call SetNonOperationalVdsCommand > > >>>>>>> with a new NonOperationalReason. > > >>>>>>> This command tries to migrate all VMs from the host and then > > >>>>>>> set it non operational. > > >>>>>>> (We need to think about non-migrational VMs - should we > > >>>>>>> close those VMs or keep the host running) > > >>>>>>> > > >>>>>> > > >>>>>> One more thing you may want to consider; If we get a positive > > >>>>>> response for a host which is currently non-operational, issue > > >>>>>> an activate command to try and make it operational again. > > >>>>>> Alternatively, you may decide not to handle it, assuming > > >>>>>> untrusted hosts can only be activated manually (see below > > >>>>>> Ofri's response on activating a host). > > >>>>>> > > >>>>>>>>> > > >>>>>>>>> iv. If admin fixed the non-operational node and try to switch > > >>>>>>>>> it > > >>>>>>>>> to > > >>>>>>>>> operational mode again, a trust check will happen to gate > > >>>>>>>>> the switching. > > >>>>>>>>> > > >>>>>>>>> - [Dave] If there is a button provided from UI for > > >>>>>>>>> checking > > >>>>>>>>> the > > >>>>>>>>> logic? or we need add an extra-button for attestation check only? > > >>>>>>>>> > > >>>>>>> > > >>>>>>> In the UI we already have the "Activate" option. What still > > >>>>>>> needs to be added is the check with the attestation provider > > >>>>>>> to make sure that if the cluster is defined 'Trusted'. If > > >>>>>>> so, only trusted host will succeed in the activate command > > >>>>>>> (and, of course, a proper Audit Log error in case the host > > >>>>>>> failed to activate due to trust issue. > > >>>>>>> > > >>>>>>> the correct place to add this check would be in: > > >>>>>>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java > > >>>>>>> /org > > >>>>>>> /ovirt > > >>>>>>> /engine/core/vdsbroker/VdsManager.java:activate() > > >>>>>>> this is where the re-activation process begins. > > >>>>>>> > > >>>>>>>>> > > >>>>>>>>> Thanks very much. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Best Regards, > > >>>>>>>>> Dave Chen > > >>>>>> _______________________________________________ > > >>>>>> 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 > > >>> > > >> _______________________________________________ > > >> 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 amureini at redhat.com Thu Apr 18 08:09:42 2013 From: amureini at redhat.com (Allon Mureinik) Date: Thu, 18 Apr 2013 04:09:42 -0400 (EDT) Subject: [Engine-devel] How get all language WebAdm ? In-Reply-To: References: <4952460.MNzll7zG6g@awels> Message-ID: <1437980134.2287858.1366272582898.JavaMail.root@redhat.com> This test failure is a bug. I merged a fix yesterday ( http://gerrit.ovirt.org/#/c/14004/ ), so if you fetch and rebase you should be able to overcome it. ----- Original Message ----- > From: "??" > Cc: engine-devel at ovirt.org > Sent: Wednesday, April 17, 2013 6:44:04 PM > Subject: Re: [Engine-devel] How get all language WebAdm ? > HI:All > This is my logs, thanks, > ========================================================== > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Forking command line: /bin/sh -c cd > /home/liqiang/ovirt-engine/backend/manager/modules/dal && > /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/bin/java -jar > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefirebooter4261523418572089603.jar > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefire7472834543455719312tmp > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire/surefire5281802986683589703tmp > Running org.ovirt.engine.core.dao.DaoFactoryTest > Tests run: 24, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.262 sec > Running org.ovirt.engine.core.dal.job.ExecutionMessageDirectorTest > 23:39:49,030 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > 23:39:49,032 ERROR [ExecutionMessageDirector] Message key job.AddDiskToVm is > not valid for enum VdcActionType > 23:39:49,033 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > 23:39:49,033 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > 23:39:49,034 ERROR [ExecutionMessageDirector] Message key job.AddDiskToVm is > not valid for enum VdcActionType > 23:39:49,034 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > 23:39:49,034 WARN [ExecutionMessageDirector] The message key Unknown is > missing from bundles/ExecutionMessages > 23:39:49,035 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > 23:39:49,036 ERROR [ExecutionMessageDirector] The message key XXX cannot be > categorized since not started with job. nor step. > 23:39:49,037 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > 23:39:49,037 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > 23:39:49,039 ERROR [ExecutionMessageDirector] Message key job.ABC is not > valid for enum VdcActionType > 23:39:49,040 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > 23:39:49,042 INFO [ExecutionMessageDirector] Start initializing > ExecutionMessageDirector > 23:39:49,044 ERROR [ExecutionMessageDirector] Message key step.XYZ is not > valid for enum StepEnum > 23:39:49,044 INFO [ExecutionMessageDirector] Finished initializing > ExecutionMessageDirector > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec > Running org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtilsTest > 23:39:49,431 WARN [LocalConfig] The file > "/usr/share/ovirt-engine/conf/engine.conf.defaults" doesn't exist or isn't > readable. Will return an empty set of properties. > 23:39:49,431 WARN [LocalConfig] The file "/etc/ovirt-engine/engine.conf" > doesn't exist or isn't readable. Will return an empty set of properties. > 23:39:49,432 ERROR [LocalConfig] The property "ENGINE_DB_CONNECTION_TIMEOUT" > doesn't have a value. > 23:39:49,433 WARN [DbFacadeLocator] Can't load connection checking parameters > of DB facade, will continue using the default values. > java.lang.IllegalArgumentException: The property > "ENGINE_DB_CONNECTION_TIMEOUT" doesn't have a value. > at org.ovirt.engine.core.utils.LocalConfig.getProperty(LocalConfig.java:234) > at org.ovirt.engine.core.utils.LocalConfig.getInteger(LocalConfig.java:293) > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.loadDbFacadeConfig(DbFacadeLocator.java:177) > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.createDbFacade(DbFacadeLocator.java:62) > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.getDbFacade(DbFacadeLocator.java:47) > at > org.ovirt.engine.core.dao.BaseDAOTestCase.initTestCase(BaseDAOTestCase.java:66) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > at > org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > at > org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) > at org.junit.rules.RunRules.evaluate(RunRules.java:18) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at > org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > 23:39:49,830 WARN [SQLErrorCodesFactory] Error while extracting database > product name - falling back to empty error codes > org.springframework.jdbc.support.MetaDataAccessException: Could not get > Connection for extracting meta data; nested exception is > org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get > JDBC Connection; nested exception is org.postgresql.util.PSQLException: > FATAL: database "engine_test" does not exist > at > org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:293) > at > org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:320) > at > org.springframework.jdbc.support.SQLErrorCodesFactory.getErrorCodes(SQLErrorCodesFactory.java:214) > at > org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.setDataSource(SQLErrorCodeSQLExceptionTranslator.java:141) > at > org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.(SQLErrorCodeSQLExceptionTranslator.java:104) > at > org.ovirt.engine.core.dal.dbbroker.CustomSQLErrorCodeSQLExceptionTranslator.(CustomSQLErrorCodeSQLExceptionTranslator.java:10) > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.createDbFacade(DbFacadeLocator.java:79) > at > org.ovirt.engine.core.dal.dbbroker.DbFacadeLocator.getDbFacade(DbFacadeLocator.java:47) > at > org.ovirt.engine.core.dao.BaseDAOTestCase.initTestCase(BaseDAOTestCase.java:66) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > at > org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > at > org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) > at org.junit.rules.RunRules.evaluate(RunRules.java:18) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at > org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > Caused by: org.springframework.jdbc.CannotGetJdbcConnectionException: Could > not get JDBC Connection; nested exception is > org.postgresql.util.PSQLException: FATAL: database "engine_test" does not > exist > at > org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:80) > at > org.springframework.jdbc.support.JdbcUtils.extractDatabaseMetaData(JdbcUtils.java:280) > ... 34 more > Caused by: org.postgresql.util.PSQLException: FATAL: database "engine_test" > does not exist > at > org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:471) > at > org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:112) > at > org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66) > at > org.postgresql.jdbc2.AbstractJdbc2Connection.(AbstractJdbc2Connection.java:125) > at > org.postgresql.jdbc3.AbstractJdbc3Connection.(AbstractJdbc3Connection.java:30) > at > org.postgresql.jdbc3g.AbstractJdbc3gConnection.(AbstractJdbc3gConnection.java:22) > at > org.postgresql.jdbc4.AbstractJdbc4Connection.(AbstractJdbc4Connection.java:32) > at org.postgresql.jdbc4.Jdbc4Connection.(Jdbc4Connection.java:24) > at org.postgresql.Driver.makeConnection(Driver.java:393) > at org.postgresql.Driver.connect(Driver.java:267) > at java.sql.DriverManager.getConnection(DriverManager.java:579) > at java.sql.DriverManager.getConnection(DriverManager.java:190) > at > org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriverManager(DriverManagerDataSource.java:173) > at > org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriver(DriverManagerDataSource.java:164) > at > org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getConnectionFromDriver(AbstractDriverBasedDataSource.java:149) > at > org.springframework.jdbc.datasource.SingleConnectionDataSource.initConnection(SingleConnectionDataSource.java:244) > at > org.springframework.jdbc.datasource.SingleConnectionDataSource.getConnection(SingleConnectionDataSource.java:186) > at > org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:111) > at > org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:77) > ... 35 more > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.804 sec <<< > FAILURE! > Running org.ovirt.engine.core.dal.dbbroker.generic.DomainsPasswordMapTest > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.219 sec > Running org.ovirt.engine.core.dal.dbbroker.auditloghandling.TimeoutBaseTest > Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec > Running > org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirectorTest > 23:39:50,102 INFO [AuditLogDirector] AuditLogType: UNASSIGNED not exist in > string table > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: > USER_RUN_UNLOCK_ENTITY_SCRIPT not exist in string table > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: > VDS_NETWORK_MTU_DIFFER_FROM_LOGICAL_NETWORK not exist in string table > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: STORAGE_ACTIVATE_ASYNC not > exist in string table > 23:39:50,103 INFO [AuditLogDirector] AuditLogType: DWH_STOPPED not exist in > string table > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: DWH_STARTED not exist in > string table > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: DWH_ERROR not exist in > string table > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_NORMAL not > exist in string table > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_WARNING not > exist in string table > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_EVENT_ERROR not > exist in string table > 23:39:50,104 INFO [AuditLogDirector] AuditLogType: EXTERNAL_ALERT not exist > in string table > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: USER_ATTACH_DISK_TO_VM not > have severity. Assumed Normal > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: USER_DETACH_DISK_FROM_VM > not have severity. Assumed Normal > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: > USER_FAILED_DETACH_DISK_FROM_VM not have severity. Assumed Normal > 23:39:50,109 WARN [AuditLogDirector] AuditLogType: > USER_RUN_UNLOCK_ENTITY_SCRIPT not have severity. Assumed Normal > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > GLUSTER_VOLUME_OPTION_CHANGED_FROM_CLI not have severity. Assumed Normal > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > VM_MIGRATION_START_SYSTEM_INITIATED not have severity. Assumed Normal > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > VDS_NETWORK_MTU_DIFFER_FROM_LOGICAL_NETWORK not have severity. Assumed > Normal > 23:39:50,110 WARN [AuditLogDirector] AuditLogType: > NETWORK_UPDATE_VM_INTERFACE_LINK_UP not have severity. Assumed Normal > 23:39:50,111 WARN [AuditLogDirector] AuditLogType: > NETWORK_UPDATE_VM_INTERFACE_LINK_DOWN not have severity. Assumed Normal > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.103 sec > Running > org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBaseTest > 23:39:50,289 INFO [AuditLogableBase] Failed to get vds > 11111111-1111-1111-1111-111111111113 > null > 23:39:50,293 INFO [AuditLogableBase] Failed to get vds > 11111111-1111-1111-1111-111111111113 > null > 23:39:50,311 INFO [AuditLogableBase] Failed to get vm > 11111111-1111-1111-1111-111111111113 > Tests run: 113, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.145 sec > Running org.ovirt.engine.core.dal.dbbroker.CustomMapSqlParameterSourceTest > Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec > Running org.ovirt.engine.core.DuplicateKeysTest > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec > Results : > Tests in error: > org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtilsTest: FATAL: database > "engine_test" does not exist > Tests run: 168, Failures: 0, Errors: 1, Skipped: 0 > [INFO] > ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] ovirt-root ........................................ SUCCESS [0.672s] > [INFO] oVirt Build Tools root ............................ SUCCESS [0.062s] > [INFO] oVirt checkstyle .................................. SUCCESS [2.132s] > [INFO] oVirt JBoss Modules Maven Plugin .................. SUCCESS [51.899s] > [INFO] oVirt Checkstyle Checks ........................... SUCCESS [1.420s] > [INFO] oVirt Modules - backend ........................... SUCCESS [0.019s] > [INFO] oVirt Manager ..................................... SUCCESS [0.015s] > [INFO] oVirt DB Scripts .................................. SUCCESS [0.316s] > [INFO] oVirt Engine dependencies ......................... SUCCESS [4.173s] > [INFO] oVirt Modules - manager ........................... SUCCESS [1.352s] > [INFO] CSharp Compatibility .............................. SUCCESS [3.588s] > [INFO] Common Code ....................................... SUCCESS [13.706s] > [INFO] Common utilities .................................. SUCCESS [17.133s] > [INFO] Data Access Layer ................................. FAILURE [8.885s] > [INFO] engine scheduler bean ............................. SKIPPED > [INFO] Vds broker ........................................ SKIPPED > [INFO] Search Backend .................................... SKIPPED > [INFO] Backend Logic @Service bean ....................... SKIPPED > [INFO] oVirt RESTful API Backend Integration ............. SKIPPED > [INFO] oVirt RESTful API interface ....................... SKIPPED > [INFO] oVirt Engine API Definition ....................... SKIPPED > [INFO] oVirt Engine API Commom Parent POM ................ SKIPPED > [INFO] oVirt Engine API Common JAX-RS .................... SKIPPED > [INFO] oVirt RESTful API Backend Integration Type Mappers SKIPPED > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources SKIPPED > [INFO] oVirt RESTful API Backend Integration Webapp ...... SKIPPED > [INFO] oVirt Engine Web Root ............................. SKIPPED > [INFO] oVirt Engine Tools ................................ SKIPPED > [INFO] oVirt Modules :: Frontend ......................... SKIPPED > [INFO] oVirt Modules :: Webadmin ......................... SKIPPED > [INFO] oVirt Modules - ui ................................ SKIPPED > [INFO] Extensions for GWT ................................ SKIPPED > [INFO] UI Utils Compatibility (for UICommon) ............. SKIPPED > [INFO] Frontend for GWT UI Projects ...................... SKIPPED > [INFO] UICommonWeb ....................................... SKIPPED > [INFO] oVirt GWT UI common infrastructure ................ SKIPPED > [INFO] WebAdmin .......................................... SKIPPED > [INFO] UserPortal ........................................ SKIPPED > [INFO] oVirt Server EAR .................................. SKIPPED > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 1:47.204s > [INFO] Finished at: Wed Apr 17 23:39:50 CST 2013 > [INFO] Final Memory: 70M/291M > [INFO] > ------------------------------------------------------------------------ > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.10:test (default-test) on > project dal: There are test failures. > [ERROR] > [ERROR] Please refer to > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports > for the individual test results. > [ERROR] -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-surefire-plugin:2.10:test (default-test) > on project dal: There are test failures. > Please refer to > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports > for the individual test results. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:158) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoFailureException: There are test > failures. > Please refer to > /home/liqiang/ovirt-engine/backend/manager/modules/dal/target/surefire-reports > for the individual test results. > at > org.apache.maven.plugin.surefire.SurefireHelper.reportExecution(SurefireHelper.java:87) > at > org.apache.maven.plugin.surefire.SurefirePlugin.writeSummary(SurefirePlugin.java:641) > at > org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:615) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:137) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:98) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 19 more > [ERROR] > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the > command > [ERROR] mvn -rf :dal > [liqiang at localhost ovirt-engine]$ > ========================================================== > _______________________________________________ > 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: From dfediuck at redhat.com Thu Apr 18 08:23:47 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Thu, 18 Apr 2013 04:23:47 -0400 (EDT) Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: References: <1308686351.886592.1366183406691.JavaMail.root@redhat.com> <516E9618.7010406@redhat.com> <746655980.1215862.1366267106372.JavaMail.root@redhat.com> <1673217119.2659279.1366269589775.JavaMail.root@redhat.com> Message-ID: <493453906.2690855.1366273427791.JavaMail.root@redhat.com> Generally speaking I agree, we can drop the periodic check is this is the way we expect it to work (ie- change trust level only during reboot). The only thing I'd like to verify is what happens is we miss something. ie- let's assume the engine crashed. During the engine down time a host reboots and becomes untrusted. Now what? The same goes for network disconnect. I'd expect to run a query in such cases to make sure we do not miss a state change. ----- Original Message ----- > From: "Wei D Chen" > To: "Omer Frenkel" , "Ofri Masad" , "Doron Fediuck" > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > Sent: Thursday, April 18, 2013 10:42:10 AM > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 > > Yes, the host must be rebooted to take effect. Doron, what do you think? > > Best Regards, > Dave Chen > > > -----Original Message----- > From: Omer Frenkel [mailto:ofrenkel at redhat.com] > Sent: Thursday, April 18, 2013 3:20 PM > To: Ofri Masad > Cc: Chen, Wei D; Oved Ourfalli; engine-devel at ovirt.org > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > integration with oVirt in 4/9 > > > > ----- Original Message ----- > > From: "Ofri Masad" > > To: "Wei D Chen" > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > Sent: Thursday, April 18, 2013 9:38:26 AM > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > integration with oVirt in 4/9 > > > > Hi Dave, > > > > Can't a host become untrusted without being rebooted? > > If that is really the case, there is no need for a periodic check - > > the trigger for the check would be the host rebooting (which is > > visible to the engine). > > > > +1 > > > Thanks, > > Ofri > > > > ----- Original Message ----- > > > From: "Wei D Chen" > > > To: "Itamar Heim" , "Ofri Masad" > > > > > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > > Sent: Thursday, April 18, 2013 9:19:03 AM > > > Subject: RE: [Engine-devel] minutes for sync up on Open Attestation > > > integration with oVirt in 4/9 > > > > > > I think it's more sensible, the initial status should be the real > > > status for this host (trusted / untrusted) only the untrusted host > > > will be set to non-operational. > > > we just need poll this host instead of all of the hosts in the > > > cluster if this can be done in "InitVdsOnUpCommand", and we suppose > > > this is the first time when this host add into the cluster. > > > Follow these steps (conclusion based on your suggestion). > > > > > > - The first time when one host is added into a trust cluster then poll > > > this > > > host, the host will be in "up" status if get "trusted" result from > > > attestation server, or else, set this host as non-operational status. > > > - The periodic check will poll all of the hosts only once as this will > > > cut > > > down a lot of time needed instead of poll each host one by one, this > > > conclusion is based on our experiments because most of time consumed > > > is in parallel. > > > - When host is down for a different reason and up again, we suppose > > > "InitVdsOnUpCommand" will be triggered again (right?), so we will > > > poll this host again to get the real status(trusted / untrusted). > > > Then mark the host as up or non-operational. > > right > > > > > > > As a trusted host flip to untrusted and take effective only under > > > the condition of this host has been hacked and rebooted, so we > > > proposal no need to add periodic check if any host's reboot will invoke > > > "InitVdsOnUpCommand" > > > and we add attestation logic in "InitVdsOnUpCommand" is enough. > > > > > > My proposal would be like this (no periodic check is needed, will > > > simply our > > > integration) > > > > > > - The first time when one host is added into a trust cluster then poll > > > this > > > host, the host will be in "up" status if get "trusted" result from > > > attestation server, or else, set this host as non-operational status. > > > - The periodic check will poll all of the hosts only once as this will > > > cut > > > down a lot of time needed instead of poll each host one by one, this > > > conclusion is based on our experiments because most of time consumed > > > is in parallel. > > > - (up -> nonoperationl / trusted -> untrusted)When host is down for a > > > different reason and up again, we suppose "InitVdsOnUpCommand" will > > > be triggered again (right?) and we also suppose the host will be > > > non-operational if host is down for some reason (right), so we will > > > poll this host again to get the real status(trusted / untrusted) > > > after host's rebooting. > > > - (nonoperationl -> up / untrusted -> trusted) Admin will activate this > > > host > > > manually after admin fix the issue of this host. Attestation logic > > > will be added into "VdsManager:activate ()" as the clue you give me > > > before. > > > > > > Any suggestion? > > > > > > Best Regards, > > > Dave Chen > > > > > > > > > -----Original Message----- > > > From: Itamar Heim [mailto:iheim at redhat.com] > > > Sent: Wednesday, April 17, 2013 8:31 PM > > > To: Ofri Masad > > > Cc: Chen, Wei D; Oved Ourfalli; engine-devel at ovirt.org > > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > > integration with oVirt in 4/9 > > > > > > On 04/17/2013 10:23 AM, Ofri Masad wrote: > > > > Hi Dave, > > > > The VdsUpdateRunTimeInfo runs every 3 seconds or so. so it not a > > > > good place to call the attestation host. > > > > Instead, like we suggested earlier, create a new Quartz job (like > > > > the one I've sent you in the QuotaManager class) which run every > > > > couple of minutes and update the hosts state. > > > > You can also add the check to InitVdsOnUpCommand, so that if a > > > > host was down for a different reason, it will be rechecked for > > > > attestation. > > > > You can add a UI to allow manual "refresh attestation". > > > > > > > > > > so the new thread will poll all for all hosts and update the db, > > > then during the normal monitoring "detect" the issue? > > > > > > > Ofri > > > > > > > > ----- Original Message ----- > > > >> From: "Wei D Chen" > > > >> To: "Omer Frenkel" , "Doron Fediuck" > > > >> > > > >> Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > > >> Sent: Monday, April 15, 2013 5:53:34 PM > > > >> Subject: Re: [Engine-devel] minutes for sync up on Open > > > >> Attestation integration with oVirt in 4/9 > > > >> > > > >> Good approach, thanks all. How long it needs to invoke periodic > > > >> check in the class of VdsUpdateRunTimeInfo? Whether this time > > > >> configurable? > > > >> My concern is if the initial status of each host added into > > > >> trusted cluster is non-operational, we need wait a long time for > > > >> the invoking of this periodic check, so a trusted host's with > > > >> initial status of non-operational will take a long time to flip to a > > > >> trusted host. > > > >> > > > >> As I have not seen the configuration of periodic check in > > > >> VdsUpdateRunTimeInfo, would you give me some tips if you has some > > > >> clue. > > > >> Thanks a lot. > > > >> > > > >> Best Regards, > > > >> Dave Chen > > > >> > > > >> -----Original Message----- > > > >> From: engine-devel-bounces at ovirt.org > > > >> [mailto:engine-devel-bounces at ovirt.org] > > > >> On Behalf Of Omer Frenkel > > > >> Sent: Monday, April 15, 2013 7:01 PM > > > >> To: Doron Fediuck > > > >> Cc: Oved Ourfalli; engine-devel at ovirt.org > > > >> Subject: Re: [Engine-devel] minutes for sync up on Open > > > >> Attestation integration with oVirt in 4/9 > > > >> > > > >> > > > >> > > > >> ----- Original Message ----- > > > >>> From: "Doron Fediuck" > > > >>> To: "Itamar Heim" > > > >>> Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > > >>> Sent: Monday, April 15, 2013 10:05:57 AM > > > >>> Subject: Re: [Engine-devel] minutes for sync up on Open > > > >>> Attestation integration with oVirt in 4/9 > > > >>> > > > >>> > > > >>> > > > >>> ----- Original Message ----- > > > >>>> From: "Itamar Heim" > > > >>>> To: "Oved Ourfalli" > > > >>>> Cc: engine-devel at ovirt.org > > > >>>> Sent: Monday, April 15, 2013 9:49:12 AM > > > >>>> Subject: Re: [Engine-devel] minutes for sync up on Open > > > >>>> Attestation integration with oVirt in 4/9 > > > >>>> > > > >>>> On 04/15/2013 09:20 AM, Oved Ourfalli wrote: > > > >>>>> > > > >>>>> > > > >>>>> ----- Original Message ----- > > > >>>>>> From: "Wei D Chen" > > > >>>>>> To: "Doron Fediuck" , "Ofri Masad" > > > >>>>>> > > > >>>>>> Cc: engine-devel at ovirt.org > > > >>>>>> Sent: Monday, April 15, 2013 8:54:18 AM > > > >>>>>> Subject: Re: [Engine-devel] minutes for sync up on Open > > > >>>>>> Attestation integration with oVirt in 4/9 > > > >>>>>> > > > >>>>>> Hi Doron and Ofri, > > > >>>>>> > > > >>>>>> Thanks for your reply, here is some other question. > > > >>>>>> > > > >>>>>> ii. When adding a host into the trusted cluster, the host > > > >>>>>> will be attested via OAT service, only trusted hosted can be > > > >>>>>> added. > > > >>>>>> > > > >>>>>> Would you also kindly tell me if there is any mandatory logic > > > >>>>>> check when adding a host into a cluster, so we can also put > > > >>>>>> attestation logic with these mandatory check together? Some > > > >>>>>> example or code location is better. > > > >>>>>> Thanks a lot. > > > >>>>>> > > > >>>>> > > > >>>>> I think there are two approaches, depending on the use case. > > > >>>>> #1: > > > >>>>> If the host trusted property is static, then you can narrow > > > >>>>> the tests to two locations: > > > >>>>> * AddVdsCommand - (Vds = Host) - This command is triggered > > > >>>>> when a new host is added to the system. You can use the > > > >>>>> canDoAction method (which we have on all commands, and it > > > >>>>> determines whether an action can be run or not), and there, if > > > >>>>> cluster requires trusted hosts only, you can test whether this > > > >>>>> host is trusted or not. > > > >>>>> * ChangeVdsClusterCommand - this command is used when you > > > >>>>> change the cluster of a host. So, if the target cluster > > > >>>>> requires tursted hosts, you can do a similar test in its > > > >>>>> canDoAction method. > > > >>>>> > > > >>>>> #2: > > > >>>>> If the host trusted property can change, then I'd suggest > > > >>>>> using the NonOperational property of a host. > > > >>>>> We have a class called VdsUpdateRunTimeInfo that does periodic > > > >>>>> tests of hosts, deciding what's their status, according to > > > >>>>> specific flags. > > > >>>>> The code there is quite complex, and would require refactoring > > > >>>>> at some point, but in the meantime you can use the > > > >>>>> MonitoringStrategy interface that is being used there, and > > > >>>>> implement a new monitoring strategy for Open Attestation. > > > >>>>> > > > >>>>> There, in the processHardwareCapabilities, you can test that > > > >>>>> the host is trusted. > > > >>>>> > > > >>>>> When creating the strategy, using the > > > >>>>> MonitoringStrategyFactory, you'll need to create the appropriate > > > >>>>> strategy. > > > >>>>> Currently we support either virt strategy or gluster strategy > > > >>>>> or both. In your case you would need virt+attestation / > > > >>>>> gluster+attestation / > > > >>>>> virt+gluster+attestation, according to the services deployed > > > >>>>> virt+gluster+on the > > > >>>>> cluster. > > > >>>> > > > >>>> I'd go with the 2nd approach. i.e., not block the host from > > > >>>> being added, only from being used, based on monitoring / non-op > > > >>>> status > > > >>>> > > > >>> +1. > > > >>> It means that the admin can add the host, but the host will not > > > >>> be operational until we get a positive indication from the > > > >>> attestation service. > > > >>> > > > >> +1 > > > >> if we want to test attestation only once, every time before host > > > >> moves to up. > > > >> the right place for it, imo, is InitVdsOnUpCommand if its > > > >> periodic also after host is up, then it should be somewhere in > > > >> the monitoring code > > > >> > > > >>>> > > > >>>>> > > > >>>>> > > > >>>>> Does that make sense? > > > >>>>> Doron and Ofri, what did you have in mind for this feature? > > > >>>>> > > > >>>>> Regards, > > > >>>>> Oved > > > >>>>> > > > >>>>>> > > > >>>>>> Best Regards, > > > >>>>>> Dave Chen > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Doron Fediuck [mailto:dfediuck at redhat.com] > > > >>>>>> Sent: Wednesday, April 10, 2013 8:03 PM > > > >>>>>> To: Ofri Masad > > > >>>>>> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan > > > >>>>>> Subject: Re: minutes for sync up on Open Attestation > > > >>>>>> integration with oVirt in 4/9 > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> ----- Original Message ----- > > > >>>>>>> From: "Ofri Masad" > > > >>>>>>> To: "Gang Wei" > > > >>>>>>> Cc: "Wei D Chen" , "Buddy Cao" > > > >>>>>>> , "Lijuan Zhang" > > > >>>>>>> , "Doron Fediuck" > > > >>>>>>> > > > >>>>>>> Sent: Wednesday, April 10, 2013 2:23:57 PM > > > >>>>>>> Subject: Re: minutes for sync up on Open Attestation > > > >>>>>>> integration with oVirt in 4/9 > > > >>>>>>> > > > >>>>>>> Hi, > > > >>>>>>> > > > >>>>>>> answers inside the mail body. > > > >>>>>>> > > > >>>>>>> ----- Original Message ----- > > > >>>>>>>> From: "Doron Fediuck" > > > >>>>>>>> To: "Wei D Chen" > > > >>>>>>>> Cc: "Gang Wei" , "Buddy Cao" > > > >>>>>>>> , "Lijuan Zhang" > > > >>>>>>>> , "Ofri Masad" > > > >>>>>>>> Sent: Wednesday, April 10, 2013 12:12:26 PM > > > >>>>>>>> Subject: Re: minutes for sync up on Open Attestation > > > >>>>>>>> integration with oVirt in 4/9 > > > >>>>>>>> > > > >>>>>>>> Hi Dave, > > > >>>>>>>> Adding Ofri to answer your questions. > > > >>>>>>>> > > > >>>>>>>> ----- Original Message ----- > > > >>>>>>>>> From: "Wei D Chen" > > > >>>>>>>>> To: "Gang Wei" , "Doron Fediuck" > > > >>>>>>>>> , > > > >>>>>>>>> "Buddy Cao" , "Lijuan Zhang" > > > >>>>>>>>> > > > >>>>>>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM > > > >>>>>>>>> Subject: RE: minutes for sync up on Open Attestation > > > >>>>>>>>> integration with oVirt in 4/9 > > > >>>>>>>>> > > > >>>>>>>>> Hi Doron, > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> iii. Then periodic trust check will be added into background > > > >>>>>>>>> process > > > >>>>>>>>> for > > > >>>>>>>>> all existing hosts, once becoming non-trusted, mark it as > > > >>>>>>>>> non-operational. > > > >>>>>>>>> > > > >>>>>>>>> - [Dave] Would you give me some details about the > > > >>>>>>>>> ?background > > > >>>>>>>>> process? mentioned in our sync up meeting? What?s the > > > >>>>>>>>> process and where is related code? > > > >>>>>>>>> > > > >>>>>>> > > > >>>>>>> The use Quartz Job to scheduled background processes. > > > >>>>>>> An example can be found in: > > > >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > > > >>>>>>> 222) > > > >>>>>>> > > > >>>>>>> This code calls a method that is located in: > > > >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/o > > > >>>>>>> virt /engin e/core/bll/quota/QuotaManager.java > > > >>>>>>> (Line: 1000) > > > >>>>>>> the @OnTimerMethodAnnotation annotation and the unique job > > > >>>>>>> name connects the two in runtime. > > > >>>>>>> > > > >>>>>>> The job can query the attestation server for all the host > > > >>>>>>> and then set untrusted hosts to Non-Operational. > > > >>>>>>> the best way would be to call SetNonOperationalVdsCommand > > > >>>>>>> with a new NonOperationalReason. > > > >>>>>>> This command tries to migrate all VMs from the host and then > > > >>>>>>> set it non operational. > > > >>>>>>> (We need to think about non-migrational VMs - should we > > > >>>>>>> close those VMs or keep the host running) > > > >>>>>>> > > > >>>>>> > > > >>>>>> One more thing you may want to consider; If we get a positive > > > >>>>>> response for a host which is currently non-operational, issue > > > >>>>>> an activate command to try and make it operational again. > > > >>>>>> Alternatively, you may decide not to handle it, assuming > > > >>>>>> untrusted hosts can only be activated manually (see below > > > >>>>>> Ofri's response on activating a host). > > > >>>>>> > > > >>>>>>>>> > > > >>>>>>>>> iv. If admin fixed the non-operational node and try to > > > >>>>>>>>> switch > > > >>>>>>>>> it > > > >>>>>>>>> to > > > >>>>>>>>> operational mode again, a trust check will happen to gate > > > >>>>>>>>> the switching. > > > >>>>>>>>> > > > >>>>>>>>> - [Dave] If there is a button provided from UI for > > > >>>>>>>>> checking > > > >>>>>>>>> the > > > >>>>>>>>> logic? or we need add an extra-button for attestation check > > > >>>>>>>>> only? > > > >>>>>>>>> > > > >>>>>>> > > > >>>>>>> In the UI we already have the "Activate" option. What still > > > >>>>>>> needs to be added is the check with the attestation provider > > > >>>>>>> to make sure that if the cluster is defined 'Trusted'. If > > > >>>>>>> so, only trusted host will succeed in the activate command > > > >>>>>>> (and, of course, a proper Audit Log error in case the host > > > >>>>>>> failed to activate due to trust issue. > > > >>>>>>> > > > >>>>>>> the correct place to add this check would be in: > > > >>>>>>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java > > > >>>>>>> /org > > > >>>>>>> /ovirt > > > >>>>>>> /engine/core/vdsbroker/VdsManager.java:activate() > > > >>>>>>> this is where the re-activation process begins. > > > >>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> Thanks very much. > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> Best Regards, > > > >>>>>>>>> Dave Chen > > > >>>>>> _______________________________________________ > > > >>>>>> 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 > > > >>> > > > >> _______________________________________________ > > > >> 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 > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From omasad at redhat.com Thu Apr 18 08:31:28 2013 From: omasad at redhat.com (Ofri Masad) Date: Thu, 18 Apr 2013 04:31:28 -0400 (EDT) Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: <493453906.2690855.1366273427791.JavaMail.root@redhat.com> References: <1308686351.886592.1366183406691.JavaMail.root@redhat.com> <516E9618.7010406@redhat.com> <746655980.1215862.1366267106372.JavaMail.root@redhat.com> <1673217119.2659279.1366269589775.JavaMail.root@redhat.com> <493453906.2690855.1366273427791.JavaMail.root@redhat.com> Message-ID: <1599979549.1242012.1366273888898.JavaMail.root@redhat.com> We run the query each time the host is moving to UP state. Which means, we query all the hosts on engine restart. if the host was unreachable or down for any reason - we will query it again before moving to UP state. Ofri ----- Original Message ----- > From: "Doron Fediuck" > To: "Wei D Chen" > Cc: "Omer Frenkel" , "Ofri Masad" , "Oved Ourfalli" , > engine-devel at ovirt.org > Sent: Thursday, April 18, 2013 11:23:47 AM > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 > > Generally speaking I agree, we can drop the periodic check is > this is the way we expect it to work (ie- change trust level only during > reboot). > > The only thing I'd like to verify is what happens is we miss something. > ie- let's assume the engine crashed. During the engine down time a host > reboots and becomes untrusted. Now what? The same goes for network > disconnect. > I'd expect to run a query in such cases to make sure we do not miss > a state change. > > > ----- Original Message ----- > > From: "Wei D Chen" > > To: "Omer Frenkel" , "Ofri Masad" , > > "Doron Fediuck" > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > Sent: Thursday, April 18, 2013 10:42:10 AM > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > integration with oVirt in 4/9 > > > > Yes, the host must be rebooted to take effect. Doron, what do you think? > > > > Best Regards, > > Dave Chen > > > > > > -----Original Message----- > > From: Omer Frenkel [mailto:ofrenkel at redhat.com] > > Sent: Thursday, April 18, 2013 3:20 PM > > To: Ofri Masad > > Cc: Chen, Wei D; Oved Ourfalli; engine-devel at ovirt.org > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > integration with oVirt in 4/9 > > > > > > > > ----- Original Message ----- > > > From: "Ofri Masad" > > > To: "Wei D Chen" > > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > > Sent: Thursday, April 18, 2013 9:38:26 AM > > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > > integration with oVirt in 4/9 > > > > > > Hi Dave, > > > > > > Can't a host become untrusted without being rebooted? > > > If that is really the case, there is no need for a periodic check - > > > the trigger for the check would be the host rebooting (which is > > > visible to the engine). > > > > > > > +1 > > > > > Thanks, > > > Ofri > > > > > > ----- Original Message ----- > > > > From: "Wei D Chen" > > > > To: "Itamar Heim" , "Ofri Masad" > > > > > > > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > > > Sent: Thursday, April 18, 2013 9:19:03 AM > > > > Subject: RE: [Engine-devel] minutes for sync up on Open Attestation > > > > integration with oVirt in 4/9 > > > > > > > > I think it's more sensible, the initial status should be the real > > > > status for this host (trusted / untrusted) only the untrusted host > > > > will be set to non-operational. > > > > we just need poll this host instead of all of the hosts in the > > > > cluster if this can be done in "InitVdsOnUpCommand", and we suppose > > > > this is the first time when this host add into the cluster. > > > > Follow these steps (conclusion based on your suggestion). > > > > > > > > - The first time when one host is added into a trust cluster then poll > > > > this > > > > host, the host will be in "up" status if get "trusted" result from > > > > attestation server, or else, set this host as non-operational status. > > > > - The periodic check will poll all of the hosts only once as this will > > > > cut > > > > down a lot of time needed instead of poll each host one by one, this > > > > conclusion is based on our experiments because most of time consumed > > > > is in parallel. > > > > - When host is down for a different reason and up again, we suppose > > > > "InitVdsOnUpCommand" will be triggered again (right?), so we will > > > > poll this host again to get the real status(trusted / untrusted). > > > > Then mark the host as up or non-operational. > > > > right > > > > > > > > > > As a trusted host flip to untrusted and take effective only under > > > > the condition of this host has been hacked and rebooted, so we > > > > proposal no need to add periodic check if any host's reboot will invoke > > > > "InitVdsOnUpCommand" > > > > and we add attestation logic in "InitVdsOnUpCommand" is enough. > > > > > > > > My proposal would be like this (no periodic check is needed, will > > > > simply our > > > > integration) > > > > > > > > - The first time when one host is added into a trust cluster then poll > > > > this > > > > host, the host will be in "up" status if get "trusted" result from > > > > attestation server, or else, set this host as non-operational status. > > > > - The periodic check will poll all of the hosts only once as this will > > > > cut > > > > down a lot of time needed instead of poll each host one by one, this > > > > conclusion is based on our experiments because most of time consumed > > > > is in parallel. > > > > - (up -> nonoperationl / trusted -> untrusted)When host is down for a > > > > different reason and up again, we suppose "InitVdsOnUpCommand" will > > > > be triggered again (right?) and we also suppose the host will be > > > > non-operational if host is down for some reason (right), so we will > > > > poll this host again to get the real status(trusted / untrusted) > > > > after host's rebooting. > > > > - (nonoperationl -> up / untrusted -> trusted) Admin will activate this > > > > host > > > > manually after admin fix the issue of this host. Attestation logic > > > > will be added into "VdsManager:activate ()" as the clue you give me > > > > before. > > > > > > > > Any suggestion? > > > > > > > > Best Regards, > > > > Dave Chen > > > > > > > > > > > > -----Original Message----- > > > > From: Itamar Heim [mailto:iheim at redhat.com] > > > > Sent: Wednesday, April 17, 2013 8:31 PM > > > > To: Ofri Masad > > > > Cc: Chen, Wei D; Oved Ourfalli; engine-devel at ovirt.org > > > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > > > integration with oVirt in 4/9 > > > > > > > > On 04/17/2013 10:23 AM, Ofri Masad wrote: > > > > > Hi Dave, > > > > > The VdsUpdateRunTimeInfo runs every 3 seconds or so. so it not a > > > > > good place to call the attestation host. > > > > > Instead, like we suggested earlier, create a new Quartz job (like > > > > > the one I've sent you in the QuotaManager class) which run every > > > > > couple of minutes and update the hosts state. > > > > > You can also add the check to InitVdsOnUpCommand, so that if a > > > > > host was down for a different reason, it will be rechecked for > > > > > attestation. > > > > > You can add a UI to allow manual "refresh attestation". > > > > > > > > > > > > > so the new thread will poll all for all hosts and update the db, > > > > then during the normal monitoring "detect" the issue? > > > > > > > > > Ofri > > > > > > > > > > ----- Original Message ----- > > > > >> From: "Wei D Chen" > > > > >> To: "Omer Frenkel" , "Doron Fediuck" > > > > >> > > > > >> Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > > > >> Sent: Monday, April 15, 2013 5:53:34 PM > > > > >> Subject: Re: [Engine-devel] minutes for sync up on Open > > > > >> Attestation integration with oVirt in 4/9 > > > > >> > > > > >> Good approach, thanks all. How long it needs to invoke periodic > > > > >> check in the class of VdsUpdateRunTimeInfo? Whether this time > > > > >> configurable? > > > > >> My concern is if the initial status of each host added into > > > > >> trusted cluster is non-operational, we need wait a long time for > > > > >> the invoking of this periodic check, so a trusted host's with > > > > >> initial status of non-operational will take a long time to flip to a > > > > >> trusted host. > > > > >> > > > > >> As I have not seen the configuration of periodic check in > > > > >> VdsUpdateRunTimeInfo, would you give me some tips if you has some > > > > >> clue. > > > > >> Thanks a lot. > > > > >> > > > > >> Best Regards, > > > > >> Dave Chen > > > > >> > > > > >> -----Original Message----- > > > > >> From: engine-devel-bounces at ovirt.org > > > > >> [mailto:engine-devel-bounces at ovirt.org] > > > > >> On Behalf Of Omer Frenkel > > > > >> Sent: Monday, April 15, 2013 7:01 PM > > > > >> To: Doron Fediuck > > > > >> Cc: Oved Ourfalli; engine-devel at ovirt.org > > > > >> Subject: Re: [Engine-devel] minutes for sync up on Open > > > > >> Attestation integration with oVirt in 4/9 > > > > >> > > > > >> > > > > >> > > > > >> ----- Original Message ----- > > > > >>> From: "Doron Fediuck" > > > > >>> To: "Itamar Heim" > > > > >>> Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > > > >>> Sent: Monday, April 15, 2013 10:05:57 AM > > > > >>> Subject: Re: [Engine-devel] minutes for sync up on Open > > > > >>> Attestation integration with oVirt in 4/9 > > > > >>> > > > > >>> > > > > >>> > > > > >>> ----- Original Message ----- > > > > >>>> From: "Itamar Heim" > > > > >>>> To: "Oved Ourfalli" > > > > >>>> Cc: engine-devel at ovirt.org > > > > >>>> Sent: Monday, April 15, 2013 9:49:12 AM > > > > >>>> Subject: Re: [Engine-devel] minutes for sync up on Open > > > > >>>> Attestation integration with oVirt in 4/9 > > > > >>>> > > > > >>>> On 04/15/2013 09:20 AM, Oved Ourfalli wrote: > > > > >>>>> > > > > >>>>> > > > > >>>>> ----- Original Message ----- > > > > >>>>>> From: "Wei D Chen" > > > > >>>>>> To: "Doron Fediuck" , "Ofri Masad" > > > > >>>>>> > > > > >>>>>> Cc: engine-devel at ovirt.org > > > > >>>>>> Sent: Monday, April 15, 2013 8:54:18 AM > > > > >>>>>> Subject: Re: [Engine-devel] minutes for sync up on Open > > > > >>>>>> Attestation integration with oVirt in 4/9 > > > > >>>>>> > > > > >>>>>> Hi Doron and Ofri, > > > > >>>>>> > > > > >>>>>> Thanks for your reply, here is some other question. > > > > >>>>>> > > > > >>>>>> ii. When adding a host into the trusted cluster, the host > > > > >>>>>> will be attested via OAT service, only trusted hosted can be > > > > >>>>>> added. > > > > >>>>>> > > > > >>>>>> Would you also kindly tell me if there is any mandatory logic > > > > >>>>>> check when adding a host into a cluster, so we can also put > > > > >>>>>> attestation logic with these mandatory check together? Some > > > > >>>>>> example or code location is better. > > > > >>>>>> Thanks a lot. > > > > >>>>>> > > > > >>>>> > > > > >>>>> I think there are two approaches, depending on the use case. > > > > >>>>> #1: > > > > >>>>> If the host trusted property is static, then you can narrow > > > > >>>>> the tests to two locations: > > > > >>>>> * AddVdsCommand - (Vds = Host) - This command is triggered > > > > >>>>> when a new host is added to the system. You can use the > > > > >>>>> canDoAction method (which we have on all commands, and it > > > > >>>>> determines whether an action can be run or not), and there, if > > > > >>>>> cluster requires trusted hosts only, you can test whether this > > > > >>>>> host is trusted or not. > > > > >>>>> * ChangeVdsClusterCommand - this command is used when you > > > > >>>>> change the cluster of a host. So, if the target cluster > > > > >>>>> requires tursted hosts, you can do a similar test in its > > > > >>>>> canDoAction method. > > > > >>>>> > > > > >>>>> #2: > > > > >>>>> If the host trusted property can change, then I'd suggest > > > > >>>>> using the NonOperational property of a host. > > > > >>>>> We have a class called VdsUpdateRunTimeInfo that does periodic > > > > >>>>> tests of hosts, deciding what's their status, according to > > > > >>>>> specific flags. > > > > >>>>> The code there is quite complex, and would require refactoring > > > > >>>>> at some point, but in the meantime you can use the > > > > >>>>> MonitoringStrategy interface that is being used there, and > > > > >>>>> implement a new monitoring strategy for Open Attestation. > > > > >>>>> > > > > >>>>> There, in the processHardwareCapabilities, you can test that > > > > >>>>> the host is trusted. > > > > >>>>> > > > > >>>>> When creating the strategy, using the > > > > >>>>> MonitoringStrategyFactory, you'll need to create the appropriate > > > > >>>>> strategy. > > > > >>>>> Currently we support either virt strategy or gluster strategy > > > > >>>>> or both. In your case you would need virt+attestation / > > > > >>>>> gluster+attestation / > > > > >>>>> virt+gluster+attestation, according to the services deployed > > > > >>>>> virt+gluster+on the > > > > >>>>> cluster. > > > > >>>> > > > > >>>> I'd go with the 2nd approach. i.e., not block the host from > > > > >>>> being added, only from being used, based on monitoring / non-op > > > > >>>> status > > > > >>>> > > > > >>> +1. > > > > >>> It means that the admin can add the host, but the host will not > > > > >>> be operational until we get a positive indication from the > > > > >>> attestation service. > > > > >>> > > > > >> +1 > > > > >> if we want to test attestation only once, every time before host > > > > >> moves to up. > > > > >> the right place for it, imo, is InitVdsOnUpCommand if its > > > > >> periodic also after host is up, then it should be somewhere in > > > > >> the monitoring code > > > > >> > > > > >>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> Does that make sense? > > > > >>>>> Doron and Ofri, what did you have in mind for this feature? > > > > >>>>> > > > > >>>>> Regards, > > > > >>>>> Oved > > > > >>>>> > > > > >>>>>> > > > > >>>>>> Best Regards, > > > > >>>>>> Dave Chen > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> -----Original Message----- > > > > >>>>>> From: Doron Fediuck [mailto:dfediuck at redhat.com] > > > > >>>>>> Sent: Wednesday, April 10, 2013 8:03 PM > > > > >>>>>> To: Ofri Masad > > > > >>>>>> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan > > > > >>>>>> Subject: Re: minutes for sync up on Open Attestation > > > > >>>>>> integration with oVirt in 4/9 > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> ----- Original Message ----- > > > > >>>>>>> From: "Ofri Masad" > > > > >>>>>>> To: "Gang Wei" > > > > >>>>>>> Cc: "Wei D Chen" , "Buddy Cao" > > > > >>>>>>> , "Lijuan Zhang" > > > > >>>>>>> , "Doron Fediuck" > > > > >>>>>>> > > > > >>>>>>> Sent: Wednesday, April 10, 2013 2:23:57 PM > > > > >>>>>>> Subject: Re: minutes for sync up on Open Attestation > > > > >>>>>>> integration with oVirt in 4/9 > > > > >>>>>>> > > > > >>>>>>> Hi, > > > > >>>>>>> > > > > >>>>>>> answers inside the mail body. > > > > >>>>>>> > > > > >>>>>>> ----- Original Message ----- > > > > >>>>>>>> From: "Doron Fediuck" > > > > >>>>>>>> To: "Wei D Chen" > > > > >>>>>>>> Cc: "Gang Wei" , "Buddy Cao" > > > > >>>>>>>> , "Lijuan Zhang" > > > > >>>>>>>> , "Ofri Masad" > > > > >>>>>>>> Sent: Wednesday, April 10, 2013 12:12:26 PM > > > > >>>>>>>> Subject: Re: minutes for sync up on Open Attestation > > > > >>>>>>>> integration with oVirt in 4/9 > > > > >>>>>>>> > > > > >>>>>>>> Hi Dave, > > > > >>>>>>>> Adding Ofri to answer your questions. > > > > >>>>>>>> > > > > >>>>>>>> ----- Original Message ----- > > > > >>>>>>>>> From: "Wei D Chen" > > > > >>>>>>>>> To: "Gang Wei" , "Doron Fediuck" > > > > >>>>>>>>> , > > > > >>>>>>>>> "Buddy Cao" , "Lijuan Zhang" > > > > >>>>>>>>> > > > > >>>>>>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM > > > > >>>>>>>>> Subject: RE: minutes for sync up on Open Attestation > > > > >>>>>>>>> integration with oVirt in 4/9 > > > > >>>>>>>>> > > > > >>>>>>>>> Hi Doron, > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> iii. Then periodic trust check will be added into > > > > >>>>>>>>> background > > > > >>>>>>>>> process > > > > >>>>>>>>> for > > > > >>>>>>>>> all existing hosts, once becoming non-trusted, mark it as > > > > >>>>>>>>> non-operational. > > > > >>>>>>>>> > > > > >>>>>>>>> - [Dave] Would you give me some details about the > > > > >>>>>>>>> ?background > > > > >>>>>>>>> process? mentioned in our sync up meeting? What?s the > > > > >>>>>>>>> process and where is related code? > > > > >>>>>>>>> > > > > >>>>>>> > > > > >>>>>>> The use Quartz Job to scheduled background processes. > > > > >>>>>>> An example can be found in: > > > > >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > > > > >>>>>>> 222) > > > > >>>>>>> > > > > >>>>>>> This code calls a method that is located in: > > > > >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/o > > > > >>>>>>> virt /engin e/core/bll/quota/QuotaManager.java > > > > >>>>>>> (Line: 1000) > > > > >>>>>>> the @OnTimerMethodAnnotation annotation and the unique job > > > > >>>>>>> name connects the two in runtime. > > > > >>>>>>> > > > > >>>>>>> The job can query the attestation server for all the host > > > > >>>>>>> and then set untrusted hosts to Non-Operational. > > > > >>>>>>> the best way would be to call SetNonOperationalVdsCommand > > > > >>>>>>> with a new NonOperationalReason. > > > > >>>>>>> This command tries to migrate all VMs from the host and then > > > > >>>>>>> set it non operational. > > > > >>>>>>> (We need to think about non-migrational VMs - should we > > > > >>>>>>> close those VMs or keep the host running) > > > > >>>>>>> > > > > >>>>>> > > > > >>>>>> One more thing you may want to consider; If we get a positive > > > > >>>>>> response for a host which is currently non-operational, issue > > > > >>>>>> an activate command to try and make it operational again. > > > > >>>>>> Alternatively, you may decide not to handle it, assuming > > > > >>>>>> untrusted hosts can only be activated manually (see below > > > > >>>>>> Ofri's response on activating a host). > > > > >>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> iv. If admin fixed the non-operational node and try to > > > > >>>>>>>>> switch > > > > >>>>>>>>> it > > > > >>>>>>>>> to > > > > >>>>>>>>> operational mode again, a trust check will happen to gate > > > > >>>>>>>>> the switching. > > > > >>>>>>>>> > > > > >>>>>>>>> - [Dave] If there is a button provided from UI for > > > > >>>>>>>>> checking > > > > >>>>>>>>> the > > > > >>>>>>>>> logic? or we need add an extra-button for attestation check > > > > >>>>>>>>> only? > > > > >>>>>>>>> > > > > >>>>>>> > > > > >>>>>>> In the UI we already have the "Activate" option. What still > > > > >>>>>>> needs to be added is the check with the attestation provider > > > > >>>>>>> to make sure that if the cluster is defined 'Trusted'. If > > > > >>>>>>> so, only trusted host will succeed in the activate command > > > > >>>>>>> (and, of course, a proper Audit Log error in case the host > > > > >>>>>>> failed to activate due to trust issue. > > > > >>>>>>> > > > > >>>>>>> the correct place to add this check would be in: > > > > >>>>>>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java > > > > >>>>>>> /org > > > > >>>>>>> /ovirt > > > > >>>>>>> /engine/core/vdsbroker/VdsManager.java:activate() > > > > >>>>>>> this is where the re-activation process begins. > > > > >>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> Thanks very much. > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> Best Regards, > > > > >>>>>>>>> Dave Chen > > > > >>>>>> _______________________________________________ > > > > >>>>>> 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 > > > > >>> > > > > >> _______________________________________________ > > > > >> 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 > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From dfediuck at redhat.com Thu Apr 18 08:35:40 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Thu, 18 Apr 2013 04:35:40 -0400 (EDT) Subject: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 In-Reply-To: <1599979549.1242012.1366273888898.JavaMail.root@redhat.com> References: <516E9618.7010406@redhat.com> <746655980.1215862.1366267106372.JavaMail.root@redhat.com> <1673217119.2659279.1366269589775.JavaMail.root@redhat.com> <493453906.2690855.1366273427791.JavaMail.root@redhat.com> <1599979549.1242012.1366273888898.JavaMail.root@redhat.com> Message-ID: <679526307.2697733.1366274140466.JavaMail.root@redhat.com> True, I just want folks to be aware of it. So this should resolve it all. Now just make sure to optimize the attestation call. ----- Original Message ----- > From: "Ofri Masad" > To: "Doron Fediuck" > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > Sent: Thursday, April 18, 2013 11:31:28 AM > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation integration with oVirt in 4/9 > > We run the query each time the host is moving to UP state. > Which means, we query all the hosts on engine restart. if the host was > unreachable or down for any reason - we will query it again before moving to > UP state. > > Ofri > > ----- Original Message ----- > > From: "Doron Fediuck" > > To: "Wei D Chen" > > Cc: "Omer Frenkel" , "Ofri Masad" , > > "Oved Ourfalli" , > > engine-devel at ovirt.org > > Sent: Thursday, April 18, 2013 11:23:47 AM > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > integration with oVirt in 4/9 > > > > Generally speaking I agree, we can drop the periodic check is > > this is the way we expect it to work (ie- change trust level only during > > reboot). > > > > The only thing I'd like to verify is what happens is we miss something. > > ie- let's assume the engine crashed. During the engine down time a host > > reboots and becomes untrusted. Now what? The same goes for network > > disconnect. > > I'd expect to run a query in such cases to make sure we do not miss > > a state change. > > > > > > ----- Original Message ----- > > > From: "Wei D Chen" > > > To: "Omer Frenkel" , "Ofri Masad" > > > , > > > "Doron Fediuck" > > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > > Sent: Thursday, April 18, 2013 10:42:10 AM > > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > > integration with oVirt in 4/9 > > > > > > Yes, the host must be rebooted to take effect. Doron, what do you think? > > > > > > Best Regards, > > > Dave Chen > > > > > > > > > -----Original Message----- > > > From: Omer Frenkel [mailto:ofrenkel at redhat.com] > > > Sent: Thursday, April 18, 2013 3:20 PM > > > To: Ofri Masad > > > Cc: Chen, Wei D; Oved Ourfalli; engine-devel at ovirt.org > > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > > integration with oVirt in 4/9 > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Ofri Masad" > > > > To: "Wei D Chen" > > > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > > > Sent: Thursday, April 18, 2013 9:38:26 AM > > > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > > > integration with oVirt in 4/9 > > > > > > > > Hi Dave, > > > > > > > > Can't a host become untrusted without being rebooted? > > > > If that is really the case, there is no need for a periodic check - > > > > the trigger for the check would be the host rebooting (which is > > > > visible to the engine). > > > > > > > > > > +1 > > > > > > > Thanks, > > > > Ofri > > > > > > > > ----- Original Message ----- > > > > > From: "Wei D Chen" > > > > > To: "Itamar Heim" , "Ofri Masad" > > > > > > > > > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > > > > Sent: Thursday, April 18, 2013 9:19:03 AM > > > > > Subject: RE: [Engine-devel] minutes for sync up on Open Attestation > > > > > integration with oVirt in 4/9 > > > > > > > > > > I think it's more sensible, the initial status should be the real > > > > > status for this host (trusted / untrusted) only the untrusted host > > > > > will be set to non-operational. > > > > > we just need poll this host instead of all of the hosts in the > > > > > cluster if this can be done in "InitVdsOnUpCommand", and we suppose > > > > > this is the first time when this host add into the cluster. > > > > > Follow these steps (conclusion based on your suggestion). > > > > > > > > > > - The first time when one host is added into a trust cluster then > > > > > poll > > > > > this > > > > > host, the host will be in "up" status if get "trusted" result from > > > > > attestation server, or else, set this host as non-operational status. > > > > > - The periodic check will poll all of the hosts only once as this > > > > > will > > > > > cut > > > > > down a lot of time needed instead of poll each host one by one, this > > > > > conclusion is based on our experiments because most of time consumed > > > > > is in parallel. > > > > > - When host is down for a different reason and up again, we suppose > > > > > "InitVdsOnUpCommand" will be triggered again (right?), so we will > > > > > poll this host again to get the real status(trusted / untrusted). > > > > > Then mark the host as up or non-operational. > > > > > > right > > > > > > > > > > > > > As a trusted host flip to untrusted and take effective only under > > > > > the condition of this host has been hacked and rebooted, so we > > > > > proposal no need to add periodic check if any host's reboot will > > > > > invoke > > > > > "InitVdsOnUpCommand" > > > > > and we add attestation logic in "InitVdsOnUpCommand" is enough. > > > > > > > > > > My proposal would be like this (no periodic check is needed, will > > > > > simply our > > > > > integration) > > > > > > > > > > - The first time when one host is added into a trust cluster then > > > > > poll > > > > > this > > > > > host, the host will be in "up" status if get "trusted" result from > > > > > attestation server, or else, set this host as non-operational status. > > > > > - The periodic check will poll all of the hosts only once as this > > > > > will > > > > > cut > > > > > down a lot of time needed instead of poll each host one by one, this > > > > > conclusion is based on our experiments because most of time consumed > > > > > is in parallel. > > > > > - (up -> nonoperationl / trusted -> untrusted)When host is down for a > > > > > different reason and up again, we suppose "InitVdsOnUpCommand" will > > > > > be triggered again (right?) and we also suppose the host will be > > > > > non-operational if host is down for some reason (right), so we will > > > > > poll this host again to get the real status(trusted / untrusted) > > > > > after host's rebooting. > > > > > - (nonoperationl -> up / untrusted -> trusted) Admin will activate > > > > > this > > > > > host > > > > > manually after admin fix the issue of this host. Attestation logic > > > > > will be added into "VdsManager:activate ()" as the clue you give me > > > > > before. > > > > > > > > > > Any suggestion? > > > > > > > > > > Best Regards, > > > > > Dave Chen > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Itamar Heim [mailto:iheim at redhat.com] > > > > > Sent: Wednesday, April 17, 2013 8:31 PM > > > > > To: Ofri Masad > > > > > Cc: Chen, Wei D; Oved Ourfalli; engine-devel at ovirt.org > > > > > Subject: Re: [Engine-devel] minutes for sync up on Open Attestation > > > > > integration with oVirt in 4/9 > > > > > > > > > > On 04/17/2013 10:23 AM, Ofri Masad wrote: > > > > > > Hi Dave, > > > > > > The VdsUpdateRunTimeInfo runs every 3 seconds or so. so it not a > > > > > > good place to call the attestation host. > > > > > > Instead, like we suggested earlier, create a new Quartz job (like > > > > > > the one I've sent you in the QuotaManager class) which run every > > > > > > couple of minutes and update the hosts state. > > > > > > You can also add the check to InitVdsOnUpCommand, so that if a > > > > > > host was down for a different reason, it will be rechecked for > > > > > > attestation. > > > > > > You can add a UI to allow manual "refresh attestation". > > > > > > > > > > > > > > > > so the new thread will poll all for all hosts and update the db, > > > > > then during the normal monitoring "detect" the issue? > > > > > > > > > > > Ofri > > > > > > > > > > > > ----- Original Message ----- > > > > > >> From: "Wei D Chen" > > > > > >> To: "Omer Frenkel" , "Doron Fediuck" > > > > > >> > > > > > >> Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > > > > >> Sent: Monday, April 15, 2013 5:53:34 PM > > > > > >> Subject: Re: [Engine-devel] minutes for sync up on Open > > > > > >> Attestation integration with oVirt in 4/9 > > > > > >> > > > > > >> Good approach, thanks all. How long it needs to invoke periodic > > > > > >> check in the class of VdsUpdateRunTimeInfo? Whether this time > > > > > >> configurable? > > > > > >> My concern is if the initial status of each host added into > > > > > >> trusted cluster is non-operational, we need wait a long time for > > > > > >> the invoking of this periodic check, so a trusted host's with > > > > > >> initial status of non-operational will take a long time to flip to > > > > > >> a > > > > > >> trusted host. > > > > > >> > > > > > >> As I have not seen the configuration of periodic check in > > > > > >> VdsUpdateRunTimeInfo, would you give me some tips if you has some > > > > > >> clue. > > > > > >> Thanks a lot. > > > > > >> > > > > > >> Best Regards, > > > > > >> Dave Chen > > > > > >> > > > > > >> -----Original Message----- > > > > > >> From: engine-devel-bounces at ovirt.org > > > > > >> [mailto:engine-devel-bounces at ovirt.org] > > > > > >> On Behalf Of Omer Frenkel > > > > > >> Sent: Monday, April 15, 2013 7:01 PM > > > > > >> To: Doron Fediuck > > > > > >> Cc: Oved Ourfalli; engine-devel at ovirt.org > > > > > >> Subject: Re: [Engine-devel] minutes for sync up on Open > > > > > >> Attestation integration with oVirt in 4/9 > > > > > >> > > > > > >> > > > > > >> > > > > > >> ----- Original Message ----- > > > > > >>> From: "Doron Fediuck" > > > > > >>> To: "Itamar Heim" > > > > > >>> Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > > > > >>> Sent: Monday, April 15, 2013 10:05:57 AM > > > > > >>> Subject: Re: [Engine-devel] minutes for sync up on Open > > > > > >>> Attestation integration with oVirt in 4/9 > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> ----- Original Message ----- > > > > > >>>> From: "Itamar Heim" > > > > > >>>> To: "Oved Ourfalli" > > > > > >>>> Cc: engine-devel at ovirt.org > > > > > >>>> Sent: Monday, April 15, 2013 9:49:12 AM > > > > > >>>> Subject: Re: [Engine-devel] minutes for sync up on Open > > > > > >>>> Attestation integration with oVirt in 4/9 > > > > > >>>> > > > > > >>>> On 04/15/2013 09:20 AM, Oved Ourfalli wrote: > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> ----- Original Message ----- > > > > > >>>>>> From: "Wei D Chen" > > > > > >>>>>> To: "Doron Fediuck" , "Ofri Masad" > > > > > >>>>>> > > > > > >>>>>> Cc: engine-devel at ovirt.org > > > > > >>>>>> Sent: Monday, April 15, 2013 8:54:18 AM > > > > > >>>>>> Subject: Re: [Engine-devel] minutes for sync up on Open > > > > > >>>>>> Attestation integration with oVirt in 4/9 > > > > > >>>>>> > > > > > >>>>>> Hi Doron and Ofri, > > > > > >>>>>> > > > > > >>>>>> Thanks for your reply, here is some other question. > > > > > >>>>>> > > > > > >>>>>> ii. When adding a host into the trusted cluster, the host > > > > > >>>>>> will be attested via OAT service, only trusted hosted can be > > > > > >>>>>> added. > > > > > >>>>>> > > > > > >>>>>> Would you also kindly tell me if there is any mandatory logic > > > > > >>>>>> check when adding a host into a cluster, so we can also put > > > > > >>>>>> attestation logic with these mandatory check together? Some > > > > > >>>>>> example or code location is better. > > > > > >>>>>> Thanks a lot. > > > > > >>>>>> > > > > > >>>>> > > > > > >>>>> I think there are two approaches, depending on the use case. > > > > > >>>>> #1: > > > > > >>>>> If the host trusted property is static, then you can narrow > > > > > >>>>> the tests to two locations: > > > > > >>>>> * AddVdsCommand - (Vds = Host) - This command is triggered > > > > > >>>>> when a new host is added to the system. You can use the > > > > > >>>>> canDoAction method (which we have on all commands, and it > > > > > >>>>> determines whether an action can be run or not), and there, if > > > > > >>>>> cluster requires trusted hosts only, you can test whether this > > > > > >>>>> host is trusted or not. > > > > > >>>>> * ChangeVdsClusterCommand - this command is used when you > > > > > >>>>> change the cluster of a host. So, if the target cluster > > > > > >>>>> requires tursted hosts, you can do a similar test in its > > > > > >>>>> canDoAction method. > > > > > >>>>> > > > > > >>>>> #2: > > > > > >>>>> If the host trusted property can change, then I'd suggest > > > > > >>>>> using the NonOperational property of a host. > > > > > >>>>> We have a class called VdsUpdateRunTimeInfo that does periodic > > > > > >>>>> tests of hosts, deciding what's their status, according to > > > > > >>>>> specific flags. > > > > > >>>>> The code there is quite complex, and would require refactoring > > > > > >>>>> at some point, but in the meantime you can use the > > > > > >>>>> MonitoringStrategy interface that is being used there, and > > > > > >>>>> implement a new monitoring strategy for Open Attestation. > > > > > >>>>> > > > > > >>>>> There, in the processHardwareCapabilities, you can test that > > > > > >>>>> the host is trusted. > > > > > >>>>> > > > > > >>>>> When creating the strategy, using the > > > > > >>>>> MonitoringStrategyFactory, you'll need to create the > > > > > >>>>> appropriate > > > > > >>>>> strategy. > > > > > >>>>> Currently we support either virt strategy or gluster strategy > > > > > >>>>> or both. In your case you would need virt+attestation / > > > > > >>>>> gluster+attestation / > > > > > >>>>> virt+gluster+attestation, according to the services deployed > > > > > >>>>> virt+gluster+on the > > > > > >>>>> cluster. > > > > > >>>> > > > > > >>>> I'd go with the 2nd approach. i.e., not block the host from > > > > > >>>> being added, only from being used, based on monitoring / non-op > > > > > >>>> status > > > > > >>>> > > > > > >>> +1. > > > > > >>> It means that the admin can add the host, but the host will not > > > > > >>> be operational until we get a positive indication from the > > > > > >>> attestation service. > > > > > >>> > > > > > >> +1 > > > > > >> if we want to test attestation only once, every time before host > > > > > >> moves to up. > > > > > >> the right place for it, imo, is InitVdsOnUpCommand if its > > > > > >> periodic also after host is up, then it should be somewhere in > > > > > >> the monitoring code > > > > > >> > > > > > >>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> Does that make sense? > > > > > >>>>> Doron and Ofri, what did you have in mind for this feature? > > > > > >>>>> > > > > > >>>>> Regards, > > > > > >>>>> Oved > > > > > >>>>> > > > > > >>>>>> > > > > > >>>>>> Best Regards, > > > > > >>>>>> Dave Chen > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> -----Original Message----- > > > > > >>>>>> From: Doron Fediuck [mailto:dfediuck at redhat.com] > > > > > >>>>>> Sent: Wednesday, April 10, 2013 8:03 PM > > > > > >>>>>> To: Ofri Masad > > > > > >>>>>> Cc: Wei, Gang; Chen, Wei D; Cao, Buddy; Zhang, Lijuan > > > > > >>>>>> Subject: Re: minutes for sync up on Open Attestation > > > > > >>>>>> integration with oVirt in 4/9 > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> ----- Original Message ----- > > > > > >>>>>>> From: "Ofri Masad" > > > > > >>>>>>> To: "Gang Wei" > > > > > >>>>>>> Cc: "Wei D Chen" , "Buddy Cao" > > > > > >>>>>>> , "Lijuan Zhang" > > > > > >>>>>>> , "Doron Fediuck" > > > > > >>>>>>> > > > > > >>>>>>> Sent: Wednesday, April 10, 2013 2:23:57 PM > > > > > >>>>>>> Subject: Re: minutes for sync up on Open Attestation > > > > > >>>>>>> integration with oVirt in 4/9 > > > > > >>>>>>> > > > > > >>>>>>> Hi, > > > > > >>>>>>> > > > > > >>>>>>> answers inside the mail body. > > > > > >>>>>>> > > > > > >>>>>>> ----- Original Message ----- > > > > > >>>>>>>> From: "Doron Fediuck" > > > > > >>>>>>>> To: "Wei D Chen" > > > > > >>>>>>>> Cc: "Gang Wei" , "Buddy Cao" > > > > > >>>>>>>> , "Lijuan Zhang" > > > > > >>>>>>>> , "Ofri Masad" > > > > > >>>>>>>> Sent: Wednesday, April 10, 2013 12:12:26 PM > > > > > >>>>>>>> Subject: Re: minutes for sync up on Open Attestation > > > > > >>>>>>>> integration with oVirt in 4/9 > > > > > >>>>>>>> > > > > > >>>>>>>> Hi Dave, > > > > > >>>>>>>> Adding Ofri to answer your questions. > > > > > >>>>>>>> > > > > > >>>>>>>> ----- Original Message ----- > > > > > >>>>>>>>> From: "Wei D Chen" > > > > > >>>>>>>>> To: "Gang Wei" , "Doron Fediuck" > > > > > >>>>>>>>> , > > > > > >>>>>>>>> "Buddy Cao" , "Lijuan Zhang" > > > > > >>>>>>>>> > > > > > >>>>>>>>> Sent: Wednesday, April 10, 2013 6:31:05 AM > > > > > >>>>>>>>> Subject: RE: minutes for sync up on Open Attestation > > > > > >>>>>>>>> integration with oVirt in 4/9 > > > > > >>>>>>>>> > > > > > >>>>>>>>> Hi Doron, > > > > > >>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>> iii. Then periodic trust check will be added into > > > > > >>>>>>>>> background > > > > > >>>>>>>>> process > > > > > >>>>>>>>> for > > > > > >>>>>>>>> all existing hosts, once becoming non-trusted, mark it as > > > > > >>>>>>>>> non-operational. > > > > > >>>>>>>>> > > > > > >>>>>>>>> - [Dave] Would you give me some details about the > > > > > >>>>>>>>> ?background > > > > > >>>>>>>>> process? mentioned in our sync up meeting? What?s the > > > > > >>>>>>>>> process and where is related code? > > > > > >>>>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> The use Quartz Job to scheduled background processes. > > > > > >>>>>>> An example can be found in: > > > > > >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/Backend.java(Line: > > > > > >>>>>>> 222) > > > > > >>>>>>> > > > > > >>>>>>> This code calls a method that is located in: > > > > > >>>>>>> ovirt-engine/backend/manager/modules/bll/src/main/java/org/o > > > > > >>>>>>> virt /engin e/core/bll/quota/QuotaManager.java > > > > > >>>>>>> (Line: 1000) > > > > > >>>>>>> the @OnTimerMethodAnnotation annotation and the unique job > > > > > >>>>>>> name connects the two in runtime. > > > > > >>>>>>> > > > > > >>>>>>> The job can query the attestation server for all the host > > > > > >>>>>>> and then set untrusted hosts to Non-Operational. > > > > > >>>>>>> the best way would be to call SetNonOperationalVdsCommand > > > > > >>>>>>> with a new NonOperationalReason. > > > > > >>>>>>> This command tries to migrate all VMs from the host and then > > > > > >>>>>>> set it non operational. > > > > > >>>>>>> (We need to think about non-migrational VMs - should we > > > > > >>>>>>> close those VMs or keep the host running) > > > > > >>>>>>> > > > > > >>>>>> > > > > > >>>>>> One more thing you may want to consider; If we get a positive > > > > > >>>>>> response for a host which is currently non-operational, issue > > > > > >>>>>> an activate command to try and make it operational again. > > > > > >>>>>> Alternatively, you may decide not to handle it, assuming > > > > > >>>>>> untrusted hosts can only be activated manually (see below > > > > > >>>>>> Ofri's response on activating a host). > > > > > >>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>> iv. If admin fixed the non-operational node and try to > > > > > >>>>>>>>> switch > > > > > >>>>>>>>> it > > > > > >>>>>>>>> to > > > > > >>>>>>>>> operational mode again, a trust check will happen to gate > > > > > >>>>>>>>> the switching. > > > > > >>>>>>>>> > > > > > >>>>>>>>> - [Dave] If there is a button provided from UI > > > > > >>>>>>>>> for > > > > > >>>>>>>>> checking > > > > > >>>>>>>>> the > > > > > >>>>>>>>> logic? or we need add an extra-button for attestation check > > > > > >>>>>>>>> only? > > > > > >>>>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> In the UI we already have the "Activate" option. What still > > > > > >>>>>>> needs to be added is the check with the attestation provider > > > > > >>>>>>> to make sure that if the cluster is defined 'Trusted'. If > > > > > >>>>>>> so, only trusted host will succeed in the activate command > > > > > >>>>>>> (and, of course, a proper Audit Log error in case the host > > > > > >>>>>>> failed to activate due to trust issue. > > > > > >>>>>>> > > > > > >>>>>>> the correct place to add this check would be in: > > > > > >>>>>>> ovirt-engine/backend/manager/modules/vdsbroker/src/main/java > > > > > >>>>>>> /org > > > > > >>>>>>> /ovirt > > > > > >>>>>>> /engine/core/vdsbroker/VdsManager.java:activate() > > > > > >>>>>>> this is where the re-activation process begins. > > > > > >>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>> Thanks very much. > > > > > >>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>> Best Regards, > > > > > >>>>>>>>> Dave Chen > > > > > >>>>>> _______________________________________________ > > > > > >>>>>> 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 > > > > > >>> > > > > > >> _______________________________________________ > > > > > >> 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 > > > > > > > _______________________________________________ > > > 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 Thu Apr 18 09:19:43 2013 From: emesika at redhat.com (Eli Mesika) Date: Thu, 18 Apr 2013 05:19:43 -0400 (EDT) Subject: [Engine-devel] Changes in DB scripts that need your attension In-Reply-To: <1894764561.2511949.1366276193265.JavaMail.root@redhat.com> Message-ID: <14647780.2516361.1366276783416.JavaMail.root@redhat.com> Hi As part of solving https://bugzilla.redhat.com/show_bug.cgi?id=947344 I am doing the following changes: 1) Create all *.md5 files in /tmp/db 2) Create db log files by default under /var/log/ovirt-engine/db 3) Do not automatically create a *.schema file that represent the up-to-date schema (after all upgrades took place) A new utility script exportDbSchema.sh will be available for that (manual only, no auto-generation schema) In order that DB scripts in development environment will keep working, please do > sudo mkdir -p /var/log/ovirt-engine/db > sudo chmod 777 /var/log/ovirt-engine/db If you are getting "Permission Denied" errors while running the scripts it means that you didn't run the 2 commands above. If you have any comments/suggestions to this solution, please respond before this patch is merged, I will wait with this change to next SUN , APR 21 2013 Best Regards Eli From alonbl at redhat.com Thu Apr 18 09:26:44 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 18 Apr 2013 05:26:44 -0400 (EDT) Subject: [Engine-devel] Changes in DB scripts that need your attension In-Reply-To: <14647780.2516361.1366276783416.JavaMail.root@redhat.com> References: <14647780.2516361.1366276783416.JavaMail.root@redhat.com> Message-ID: <582991960.1253157.1366277204064.JavaMail.root@redhat.com> Hi, ----- Original Message ----- > From: "Eli Mesika" > To: "engine-devel" > Sent: Thursday, April 18, 2013 12:19:43 PM > Subject: [Engine-devel] Changes in DB scripts that need your attension > > Hi > > As part of solving https://bugzilla.redhat.com/show_bug.cgi?id=947344 I am > doing the following changes: > > 1) Create all *.md5 files in /tmp/db Please use mkstemp or equivalent to create unique temp directory. > 2) Create db log files by default under /var/log/ovirt-engine/db Please allow to override log location and/or output logs to stdout. This will make it easier to run it within installer so that the log will be available at installer log. > 3) Do not automatically create a *.schema file that represent the up-to-date > schema (after all upgrades took place) > A new utility script exportDbSchema.sh will be available for that (manual > only, no auto-generation schema) > > In order that DB scripts in development environment will keep working, please > do > > > sudo mkdir -p /var/log/ovirt-engine/db > > sudo chmod 777 /var/log/ovirt-engine/db 777 access permission is not something that should exist in system anywhere, well apart of /tmp and /tmp is marked using 't' attribute. Regards, Alon From emesika at redhat.com Thu Apr 18 09:44:06 2013 From: emesika at redhat.com (Eli Mesika) Date: Thu, 18 Apr 2013 05:44:06 -0400 (EDT) Subject: [Engine-devel] Changes in DB scripts that need your attension In-Reply-To: <582991960.1253157.1366277204064.JavaMail.root@redhat.com> References: <14647780.2516361.1366276783416.JavaMail.root@redhat.com> <582991960.1253157.1366277204064.JavaMail.root@redhat.com> Message-ID: <1452414632.2545412.1366278246728.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Eli Mesika" > Cc: "engine-devel" > Sent: Thursday, April 18, 2013 12:26:44 PM > Subject: Re: [Engine-devel] Changes in DB scripts that need your attension > > Hi, > > ----- Original Message ----- > > From: "Eli Mesika" > > To: "engine-devel" > > Sent: Thursday, April 18, 2013 12:19:43 PM > > Subject: [Engine-devel] Changes in DB scripts that need your attension > > > > Hi > > > > As part of solving https://bugzilla.redhat.com/show_bug.cgi?id=947344 I am > > doing the following changes: > > > > 1) Create all *.md5 files in /tmp/db > > Please use mkstemp or equivalent to create unique temp directory. OK, will use mktemp -d for that > > > 2) Create db log files by default under /var/log/ovirt-engine/db > > Please allow to override log location and/or output logs to stdout. > This will make it easier to run it within installer so that the log will be > available at installer log. All scripts supports the -l LOGFILE flag > > > 3) Do not automatically create a *.schema file that represent the > > up-to-date > > schema (after all upgrades took place) > > A new utility script exportDbSchema.sh will be available for that > > (manual > > only, no auto-generation schema) > > > > In order that DB scripts in development environment will keep working, > > please > > do > > > > > sudo mkdir -p /var/log/ovirt-engine/db > > > sudo chmod 777 /var/log/ovirt-engine/db > > 777 access permission is not something that should exist in system anywhere, > well apart of /tmp and /tmp is marked using 't' attribute. > > Regards, > Alon > From emesika at redhat.com Thu Apr 18 09:53:11 2013 From: emesika at redhat.com (Eli Mesika) Date: Thu, 18 Apr 2013 05:53:11 -0400 (EDT) Subject: [Engine-devel] Changes in DB scripts that need your attension In-Reply-To: <1452414632.2545412.1366278246728.JavaMail.root@redhat.com> References: <14647780.2516361.1366276783416.JavaMail.root@redhat.com> <582991960.1253157.1366277204064.JavaMail.root@redhat.com> <1452414632.2545412.1366278246728.JavaMail.root@redhat.com> Message-ID: <1743617805.2548737.1366278791486.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Eli Mesika" > To: "Alon Bar-Lev" > Cc: "engine-devel" > Sent: Thursday, April 18, 2013 12:44:06 PM > Subject: Re: [Engine-devel] Changes in DB scripts that need your attension > > > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "Eli Mesika" > > Cc: "engine-devel" > > Sent: Thursday, April 18, 2013 12:26:44 PM > > Subject: Re: [Engine-devel] Changes in DB scripts that need your attension > > > > Hi, > > > > ----- Original Message ----- > > > From: "Eli Mesika" > > > To: "engine-devel" > > > Sent: Thursday, April 18, 2013 12:19:43 PM > > > Subject: [Engine-devel] Changes in DB scripts that need your attension > > > > > > Hi > > > > > > As part of solving https://bugzilla.redhat.com/show_bug.cgi?id=947344 I > > > am > > > doing the following changes: > > > > > > 1) Create all *.md5 files in /tmp/db > > > > Please use mkstemp or equivalent to create unique temp directory. > > OK, will use mktemp -d for that > > > > > > 2) Create db log files by default under /var/log/ovirt-engine/db > > > > Please allow to override log location and/or output logs to stdout. > > This will make it easier to run it within installer so that the log will be > > available at installer log. > > > All scripts supports the -l LOGFILE flag > > > > > > 3) Do not automatically create a *.schema file that represent the > > > up-to-date > > > schema (after all upgrades took place) > > > A new utility script exportDbSchema.sh will be available for that > > > (manual > > > only, no auto-generation schema) > > > > > > In order that DB scripts in development environment will keep working, > > > please > > > do > > > > > > > sudo mkdir -p /var/log/ovirt-engine/db > > > > sudo chmod 777 /var/log/ovirt-engine/db > > > > 777 access permission is not something that should exist in system > > anywhere, > > well apart of /tmp and /tmp is marked using 't' attribute. Missed that in my prev reply anyway , do whatever is needed so that the user that access the scripts in dbscripts has r/w/ permisssions on /var/log/ovirt-engine/db since this is only for development, each developer will decide how to do that.... > > > > Regards, > > Alon > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From alonbl at redhat.com Thu Apr 18 09:58:26 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 18 Apr 2013 05:58:26 -0400 (EDT) Subject: [Engine-devel] Changes in DB scripts that need your attension In-Reply-To: <1743617805.2548737.1366278791486.JavaMail.root@redhat.com> References: <14647780.2516361.1366276783416.JavaMail.root@redhat.com> <582991960.1253157.1366277204064.JavaMail.root@redhat.com> <1452414632.2545412.1366278246728.JavaMail.root@redhat.com> <1743617805.2548737.1366278791486.JavaMail.root@redhat.com> Message-ID: <922844857.1260857.1366279106732.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Eli Mesika" > To: "Alon Bar-Lev" > Cc: "engine-devel" > Sent: Thursday, April 18, 2013 12:53:11 PM > Subject: Re: [Engine-devel] Changes in DB scripts that need your attension > > > > ----- Original Message ----- > > From: "Eli Mesika" > > To: "Alon Bar-Lev" > > Cc: "engine-devel" > > Sent: Thursday, April 18, 2013 12:44:06 PM > > Subject: Re: [Engine-devel] Changes in DB scripts that need your attension > > > > > > > > ----- Original Message ----- > > > From: "Alon Bar-Lev" > > > To: "Eli Mesika" > > > Cc: "engine-devel" > > > Sent: Thursday, April 18, 2013 12:26:44 PM > > > Subject: Re: [Engine-devel] Changes in DB scripts that need your > > > attension > > > > > > Hi, > > > > > > ----- Original Message ----- > > > > From: "Eli Mesika" > > > > To: "engine-devel" > > > > Sent: Thursday, April 18, 2013 12:19:43 PM > > > > Subject: [Engine-devel] Changes in DB scripts that need your attension > > > > > > > > Hi > > > > > > > > As part of solving https://bugzilla.redhat.com/show_bug.cgi?id=947344 I > > > > am > > > > doing the following changes: > > > > > > > > 1) Create all *.md5 files in /tmp/db > > > > > > Please use mkstemp or equivalent to create unique temp directory. > > > > OK, will use mktemp -d for that > > > > > > > > > 2) Create db log files by default under /var/log/ovirt-engine/db > > > > > > Please allow to override log location and/or output logs to stdout. > > > This will make it easier to run it within installer so that the log will > > > be > > > available at installer log. > > > > > > All scripts supports the -l LOGFILE flag > > > > > > > > > 3) Do not automatically create a *.schema file that represent the > > > > up-to-date > > > > schema (after all upgrades took place) > > > > A new utility script exportDbSchema.sh will be available for that > > > > (manual > > > > only, no auto-generation schema) > > > > > > > > In order that DB scripts in development environment will keep working, > > > > please > > > > do > > > > > > > > > sudo mkdir -p /var/log/ovirt-engine/db > > > > > sudo chmod 777 /var/log/ovirt-engine/db > > > > > > 777 access permission is not something that should exist in system > > > anywhere, > > > well apart of /tmp and /tmp is marked using 't' attribute. > > Missed that in my prev reply > anyway , do whatever is needed so that the user that access the scripts in > dbscripts has r/w/ permisssions on /var/log/ovirt-engine/db > since this is only for development, each developer will decide how to do > that.... OK... I will check this with the new development environment[1] [1] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer > > > > > > > Regards, > > > Alon > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From mpastern at redhat.com Thu Apr 18 11:57:46 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 18 Apr 2013 14:57:46 +0300 Subject: [Engine-devel] [oss-security] CVE-2012-XXYY Request -- google-authenticator: Information disclosure due insecure requirement on the secrets file In-Reply-To: <1000627254.3615210.1366281932982.JavaMail.root@redhat.com> References: <1000627254.3615210.1366281932982.JavaMail.root@redhat.com> Message-ID: <516FDFBA.7090607@redhat.com> FYI On 04/18/2013 01:45 PM, Jan Lieskovsky wrote: > Hello Kurt, Steve, Alexander, vendors, > > as noted in [1]: > > An information disclosure file was found in the way google-authenticator, > a pluggable authentication module (PAM) which allows login using one-time > passcodes conforming to the open standards developed by the Initiative for > Open Authentication (OATH), performed management of its secret / state file > in certain configurations. Due the lack of 'user=' option the secret file > was previously required to be user-readable, allowing (in certain cases) > a local attacker to obtain the (pre)shared client-to-authentication-server > secret, possibly leading to victim's account impersonation. > > A different vulnerability than CVE-2013-0258. > > References: > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666129 > [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666129#10 > [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666129#20 > [4] https://bugzilla.redhat.com/show_bug.cgi?id=953505 > > Relevant upstream patch: > [5] https://code.google.com/p/google-authenticator/source/detail?r=c3414e9857ad64e52283f3266065ef3023fc69a8 > > @Alexander - since I am not sure I have described the attack vector above > properly, please correct me if / where required. > > @Kurt * the CVE-2012- identifier should be allocated to this issue, since > the security implications of this problem are for the first time > mentioned here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666129#10 (2012-09-22), > > * from what I have looked, there doesn't seem to be: > http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authenticator > > a CVE identifier allocated to this issue yet (as noted above > CVE-2013-0258 from that list is different issue). > > => could you allocate one? > > Thank you && Regards, Jan. > -- > Jan iankko Lieskovsky / Red Hat Security Response Team -- Michael Pasternak RedHat, ENG-Virtualization R&D From yzaslavs at redhat.com Thu Apr 18 13:55:46 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 18 Apr 2013 09:55:46 -0400 (EDT) Subject: [Engine-devel] Location of findbugs filter.xml file In-Reply-To: <869626819.3724121.1366293169623.JavaMail.root@redhat.com> Message-ID: <969455724.3725819.1366293346372.JavaMail.root@redhat.com> Hi all, I sent a patch upstream to add findbugs filter that will filter out bug reports that we decided that are not bugs. We have a debate on whether to have the findbugs filter definition in the root pom.xml or to put it in the jenkins jobs repo and treat it as an external tool. I would like to hear opinions about what you think should be the proper location Thanks, Yair From ovedo at redhat.com Thu Apr 18 13:58:03 2013 From: ovedo at redhat.com (Oved Ourfalli) Date: Thu, 18 Apr 2013 09:58:03 -0400 (EDT) Subject: [Engine-devel] Location of findbugs filter.xml file In-Reply-To: <969455724.3725819.1366293346372.JavaMail.root@redhat.com> References: <969455724.3725819.1366293346372.JavaMail.root@redhat.com> Message-ID: <1309930797.20107146.1366293483425.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Yair Zaslavsky" > To: "engine-devel" > Sent: Thursday, April 18, 2013 4:55:46 PM > Subject: [Engine-devel] Location of findbugs filter.xml file > > Hi all, > I sent a patch upstream to add findbugs filter that will filter out bug > reports that we decided that are not bugs. > We have a debate on whether to have the findbugs filter definition in the > root pom.xml or to put it in the jenkins jobs repo and treat it as an > external tool. > I would like to hear opinions about what you think should be the proper > location > Putting it in the root pom.xml file will allow running filtered findbugs using maven, without the need to use jenkins, so I'd go with that approach. > Thanks, > Yair > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mkolesni at redhat.com Thu Apr 18 14:10:39 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Thu, 18 Apr 2013 10:10:39 -0400 (EDT) Subject: [Engine-devel] Location of findbugs filter.xml file In-Reply-To: <1309930797.20107146.1366293483425.JavaMail.root@redhat.com> References: <969455724.3725819.1366293346372.JavaMail.root@redhat.com> <1309930797.20107146.1366293483425.JavaMail.root@redhat.com> Message-ID: <2025610334.2384227.1366294239310.JavaMail.root@redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > From: "Yair Zaslavsky" > > To: "engine-devel" > > Sent: Thursday, April 18, 2013 4:55:46 PM > > Subject: [Engine-devel] Location of findbugs filter.xml file > > > > Hi all, > > I sent a patch upstream to add findbugs filter that will filter out bug > > reports that we decided that are not bugs. > > We have a debate on whether to have the findbugs filter definition in the > > root pom.xml or to put it in the jenkins jobs repo and treat it as an > > external tool. > > I would like to hear opinions about what you think should be the proper > > location > > > Putting it in the root pom.xml file will allow running filtered findbugs > using maven, without the need to use jenkins, so I'd go with that approach. +1 > > > Thanks, > > Yair > > _______________________________________________ > > 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 amureini at redhat.com Thu Apr 18 14:46:35 2013 From: amureini at redhat.com (Allon Mureinik) Date: Thu, 18 Apr 2013 10:46:35 -0400 (EDT) Subject: [Engine-devel] Location of findbugs filter.xml file In-Reply-To: <2025610334.2384227.1366294239310.JavaMail.root@redhat.com> References: <969455724.3725819.1366293346372.JavaMail.root@redhat.com> <1309930797.20107146.1366293483425.JavaMail.root@redhat.com> <2025610334.2384227.1366294239310.JavaMail.root@redhat.com> Message-ID: <1980521224.2651985.1366296395683.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Mike Kolesnik" > To: "engine-devel" > Cc: "Oved Ourfalli" > Sent: Thursday, April 18, 2013 5:10:39 PM > Subject: Re: [Engine-devel] Location of findbugs filter.xml file > > ----- Original Message ----- > > > > > > ----- Original Message ----- > > > From: "Yair Zaslavsky" > > > To: "engine-devel" > > > Sent: Thursday, April 18, 2013 4:55:46 PM > > > Subject: [Engine-devel] Location of findbugs filter.xml file > > > > > > Hi all, > > > I sent a patch upstream to add findbugs filter that will filter out bug > > > reports that we decided that are not bugs. > > > We have a debate on whether to have the findbugs filter definition in the > > > root pom.xml or to put it in the jenkins jobs repo and treat it as an > > > external tool. > > > I would like to hear opinions about what you think should be the proper > > > location > > > > > Putting it in the root pom.xml file will allow running filtered findbugs > > using maven, without the need to use jenkins, so I'd go with that approach. > > +1 Even better than that - each module can override the configuration with its own exceptions in its own pom file > > > > > > Thanks, > > > Yair > > > _______________________________________________ > > > 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 deadhorseconsulting at gmail.com Thu Apr 18 15:57:33 2013 From: deadhorseconsulting at gmail.com (Dead Horse) Date: Thu, 18 Apr 2013 10:57:33 -0500 Subject: [Engine-devel] spice-xpi(firefox) plugin for Windows In-Reply-To: <20130417124545.GB13447@teriyaki.redhat.com> References: <20130417124545.GB13447@teriyaki.redhat.com> Message-ID: Nicely done and this would definitely be useful. Nothing is more nauseating then being forced to use Internet Exploder to interact with an ovirt/KVM SPICE console under windows. For the plugin deployment this is definitely a point of pain. At the moment ovirt users wishing to use the SPICE Activex plugin must use an an dated version of the SPICE client packaged with the necessary SpiceX.dll. ( http://elmarco.fedorapeople.org/spice.cab) They must also take manual steps to install and deploy the plugin on ovirt-engine server (this very painful to users). The versions of the SPICE client also made available to the community here: http://spice-space.org/download/gtk/windows/ are also a bit dated and do not include the plugin (SpiceX.dll). Perhaps a plugin deployment page linked from the main ovirt landing page would be a prudent way to deploy the plugin? In any event a working SPICE Plugin for Firefox and newer SPICE Client version under windows would be a very welcome sight indeed. I think one of the most frequently asked questions or gripes I see about ovirt is around SPICE console issues and concerns. - DHC On Wed, Apr 17, 2013 at 7:45 AM, Christophe Fergeau wrote: > Hi everyone, > > Lately I've been hacking on getting the spice-xpi plugin to work on > Windows. This is the Firefox plugin that is used on Linux to implement > the portal SPICE console. > > This work has now been merged upstream ( > http://cgit.freedesktop.org/spice/spice-xpi/ ), and I've pushed a > scratch build using mingw available from > http://koji.fedoraproject.org/koji/taskinfo?taskID=5265107 (this will go > away in several days). Copying this dll + its dependencies to the > C:\Program Files\Mozilla Firefox\plugins directory are enough to get > a spice-xpi plugin to show up in about:plugins, and to then be able > to start a SPICE client from the spice-xpi test page ( > http://teuf.fedorapeople.org/plugins/test.html ). > The dependencies I had to copy are: > > gspawn-win32-helper-console.exe > gspawn-win32-helper.exe > iconv.dll > libffi-6.dll > libgcc_s_sjlj-1.dll > libgio-2.0-0.dll > libglib-2.0-0.dll > libgmodule-2.0-0.dll > libgobject-2.0-0.dll > libgthread-2.0-0.dll > libintl-8.dll > libstdc++-6.dll > pthreadGC2.dll > zlib1.dll > > (I picked them from the various mingw-* fedora packages). > > > The reason for this email is that to be usable from oVirt, some portal > changes are needed as it currently only tries to use the spice-xpi plugin > on Linux platforms. > Another fuzzy bit is how to get this plugin to the users' machines... > > > And that's about all I had to say in that email ;) Let me know if that's > useful to oVirt, how you want to integrate this, ... > > Cheers, > > Christophe > > _______________________________________________ > 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: From mpastern at redhat.com Thu Apr 18 18:33:34 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 18 Apr 2013 21:33:34 +0300 Subject: [Engine-devel] Location of findbugs filter.xml file In-Reply-To: <1309930797.20107146.1366293483425.JavaMail.root@redhat.com> References: <969455724.3725819.1366293346372.JavaMail.root@redhat.com> <1309930797.20107146.1366293483425.JavaMail.root@redhat.com> Message-ID: <51703C7E.2030002@redhat.com> On 04/18/2013 04:58 PM, Oved Ourfalli wrote: > > > ----- Original Message ----- >> From: "Yair Zaslavsky" >> To: "engine-devel" >> Sent: Thursday, April 18, 2013 4:55:46 PM >> Subject: [Engine-devel] Location of findbugs filter.xml file >> >> Hi all, >> I sent a patch upstream to add findbugs filter that will filter out bug >> reports that we decided that are not bugs. >> We have a debate on whether to have the findbugs filter definition in the >> root pom.xml or to put it in the jenkins jobs repo and treat it as an >> external tool. >> I would like to hear opinions about what you think should be the proper >> location >> > Putting it in the root pom.xml file will allow running filtered findbugs using maven, without the need to use jenkins, so I'd go with that approach. +1 > >> Thanks, >> Yair >> _______________________________________________ >> 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 -- Michael Pasternak RedHat, ENG-Virtualization R&D From alonbl at redhat.com Thu Apr 18 18:43:00 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 18 Apr 2013 14:43:00 -0400 (EDT) Subject: [Engine-devel] Changes in DB scripts that need your attension In-Reply-To: <922844857.1260857.1366279106732.JavaMail.root@redhat.com> References: <14647780.2516361.1366276783416.JavaMail.root@redhat.com> <582991960.1253157.1366277204064.JavaMail.root@redhat.com> <1452414632.2545412.1366278246728.JavaMail.root@redhat.com> <1743617805.2548737.1366278791486.JavaMail.root@redhat.com> <922844857.1260857.1366279106732.JavaMail.root@redhat.com> Message-ID: <1106985479.1467239.1366310580033.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Eli Mesika" > Cc: "engine-devel" > Sent: Thursday, April 18, 2013 12:58:26 PM > Subject: Re: [Engine-devel] Changes in DB scripts that need your attension > > > > ----- Original Message ----- > > From: "Eli Mesika" > > To: "Alon Bar-Lev" > > Cc: "engine-devel" > > Sent: Thursday, April 18, 2013 12:53:11 PM > > Subject: Re: [Engine-devel] Changes in DB scripts that need your attension > > > > > > > > ----- Original Message ----- > > > From: "Eli Mesika" > > > To: "Alon Bar-Lev" > > > Cc: "engine-devel" > > > Sent: Thursday, April 18, 2013 12:44:06 PM > > > Subject: Re: [Engine-devel] Changes in DB scripts that need your > > > attension > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Alon Bar-Lev" > > > > To: "Eli Mesika" > > > > Cc: "engine-devel" > > > > Sent: Thursday, April 18, 2013 12:26:44 PM > > > > Subject: Re: [Engine-devel] Changes in DB scripts that need your > > > > attension > > > > > > > > Hi, > > > > > > > > ----- Original Message ----- > > > > > From: "Eli Mesika" > > > > > To: "engine-devel" > > > > > Sent: Thursday, April 18, 2013 12:19:43 PM > > > > > Subject: [Engine-devel] Changes in DB scripts that need your > > > > > attension > > > > > > > > > > Hi > > > > > > > > > > As part of solving https://bugzilla.redhat.com/show_bug.cgi?id=947344 > > > > > I > > > > > am > > > > > doing the following changes: > > > > > > > > > > 1) Create all *.md5 files in /tmp/db > > > > > > > > Please use mkstemp or equivalent to create unique temp directory. > > > > > > OK, will use mktemp -d for that > > > > > > > > > > > > 2) Create db log files by default under /var/log/ovirt-engine/db > > > > > > > > Please allow to override log location and/or output logs to stdout. > > > > This will make it easier to run it within installer so that the log > > > > will > > > > be > > > > available at installer log. > > > > > > > > > All scripts supports the -l LOGFILE flag > > > > > > > > > > > > 3) Do not automatically create a *.schema file that represent the > > > > > up-to-date > > > > > schema (after all upgrades took place) > > > > > A new utility script exportDbSchema.sh will be available for that > > > > > (manual > > > > > only, no auto-generation schema) > > > > > > > > > > In order that DB scripts in development environment will keep > > > > > working, > > > > > please > > > > > do > > > > > > > > > > > sudo mkdir -p /var/log/ovirt-engine/db > > > > > > sudo chmod 777 /var/log/ovirt-engine/db > > > > > > > > 777 access permission is not something that should exist in system > > > > anywhere, > > > > well apart of /tmp and /tmp is marked using 't' attribute. > > > > Missed that in my prev reply > > anyway , do whatever is needed so that the user that access the scripts in > > dbscripts has r/w/ permisssions on /var/log/ovirt-engine/db > > since this is only for development, each developer will decide how to do > > that.... > > OK... I will check this with the new development environment[1] > > [1] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer Hi, Where can I find the patch? I cannot see this in gerrit nor reference in bug#947344 Alon From michal.skrivanek at redhat.com Fri Apr 19 08:08:58 2013 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Fri, 19 Apr 2013 10:08:58 +0200 Subject: [Engine-devel] spice-xpi(firefox) plugin for Windows In-Reply-To: References: <20130417124545.GB13447@teriyaki.redhat.com> Message-ID: <8EB4DD94-60E2-4B88-9E58-AF1BBC6765DA@redhat.com> On 18 Apr 2013, at 17:57, Dead Horse wrote: > Nicely done and this would definitely be useful. Nothing is more nauseating then being forced to use Internet Exploder to interact with an ovirt/KVM SPICE console under windows. > For the plugin deployment this is definitely a point of pain. At the moment ovirt users wishing to use the SPICE Activex plugin must use an an dated version of the SPICE client packaged with the necessary SpiceX.dll. (http://elmarco.fedorapeople.org/spice.cab) > They must also take manual steps to install and deploy the plugin on ovirt-engine server (this very painful to users). The versions of the SPICE client also made available to the community here: http://spice-space.org/download/gtk/windows/ are also a bit dated and do not include the plugin (SpiceX.dll). MIME file SPICE and VNC support is in oVirt master for couple of weeks now. This should work on all browsers with latest remote-viewer client. > > Perhaps a plugin deployment page linked from the main ovirt landing page would be a prudent way to deploy the plugin? > In any event a working SPICE Plugin for Firefox and newer SPICE Client version under windows would be a very welcome sight indeed. definitely. Another alternative planned for 3.3 is SPICE HTML5, it has lots of limitations, but it's purely browser-based solution. > > I think one of the most frequently asked questions or gripes I see about ovirt is around SPICE console issues and concerns. indeed. And we'll have 3 solutions soon!:-) Thanks, michal > > - DHC > > > > On Wed, Apr 17, 2013 at 7:45 AM, Christophe Fergeau wrote: > Hi everyone, > > Lately I've been hacking on getting the spice-xpi plugin to work on > Windows. This is the Firefox plugin that is used on Linux to implement > the portal SPICE console. > > This work has now been merged upstream ( > http://cgit.freedesktop.org/spice/spice-xpi/ ), and I've pushed a > scratch build using mingw available from > http://koji.fedoraproject.org/koji/taskinfo?taskID=5265107 (this will go > away in several days). Copying this dll + its dependencies to the > C:\Program Files\Mozilla Firefox\plugins directory are enough to get > a spice-xpi plugin to show up in about:plugins, and to then be able > to start a SPICE client from the spice-xpi test page ( > http://teuf.fedorapeople.org/plugins/test.html ). > The dependencies I had to copy are: > > gspawn-win32-helper-console.exe > gspawn-win32-helper.exe > iconv.dll > libffi-6.dll > libgcc_s_sjlj-1.dll > libgio-2.0-0.dll > libglib-2.0-0.dll > libgmodule-2.0-0.dll > libgobject-2.0-0.dll > libgthread-2.0-0.dll > libintl-8.dll > libstdc++-6.dll > pthreadGC2.dll > zlib1.dll > > (I picked them from the various mingw-* fedora packages). > > > The reason for this email is that to be usable from oVirt, some portal > changes are needed as it currently only tries to use the spice-xpi plugin > on Linux platforms. > Another fuzzy bit is how to get this plugin to the users' machines... > > > And that's about all I had to say in that email ;) Let me know if that's > useful to oVirt, how you want to integrate this, ... > > Cheers, > > Christophe > > _______________________________________________ > 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: From michal.skrivanek at redhat.com Fri Apr 19 08:30:19 2013 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Fri, 19 Apr 2013 10:30:19 +0200 Subject: [Engine-devel] [vdsm] Snapshots with RAM feature In-Reply-To: <20130411120126.GF16563@redhat.com> References: <319368954.768893.1365494496958.JavaMail.root@redhat.com> <720BEF86-8C5F-43AC-8EE2-6CCD05AD8107@redhat.com> <20130410084312.GD32275@redhat.com> <20130411120126.GF16563@redhat.com> Message-ID: On 11 Apr 2013, at 14:01, Dan Kenigsberg wrote: > On Wed, Apr 10, 2013 at 11:43:12AM +0300, Dan Kenigsberg wrote: >> On Wed, Apr 10, 2013 at 02:12:20AM -0400, Michal Skrivanek wrote: >>> >>> >>> On 9 Apr 2013, at 10:01, Arik Hadas wrote: >>> >>>> Hi All, >>>> >>>> The proposed feature will make it possible to run a VM which was reverted to live snapshot >>>> or created from live snapshot with the same memory state as it was at the moment the live >>>> snapshot was taken. >>>> >>>> http://www.ovirt.org/Features/RAM_Snapshots >>>> >>>> All feedback is welcome! >>> Nice! >> >> (I prefer to inline the document when discussing it) >> >>> VDSM changes >>> >>> Default parameter will be added to vmSnapshot verb that maps string to string. >>> The map will include two keys for now: >>> 'mode' that can be mapped to 'disks_only' or 'disks_memory' to >>> indicate if memory state should be saved. >>> 'memVol' that will be mapped to a string that represent the two >>> volums that will be used to save the memory state and the >>> VM configuration. The default map will include the >>> mapping of 'mode':'disks_only' only. >>> >>> If the 'mode' value in the map decribed above is >>> 'disks_memory' the first volume in 'memVol' will be >>> passed to libvirt in order to dump the memory to >>> it, and the second volume in 'memVol' will be used >>> to save the VM configuration (the same way it is >>> done for hibernate operation). >> >> This definition of 'memVol' would not allow saving the state to another >> storage domain, or a direct lun or whatever. >> >> I suggest that you have two independet arguments, say memVol and >> vmConfVol. Both may have the standard pool-domain-image-volume quartet, >> or a lun specification, or a local path. > > On a second thought - why should we even store vmConf on vmConfVol? Why > not keep it in Engine's db? you trust the engine db? I don't:-) RAM snapshot absolutely needs to correspond to the actual VM configuration otherwise it can crash the VM or corrupt > Sure, we do this for hibernation. But it creates a lot of inconsistency pains. > Engine sends one vmconf to vdsm, but vdsm ignores it and starts the VM > with an old vmconf that was stored besides the hibernation volume. On > top of this, it wastes some GiB of disk space for each snapshot. Pardon my lack of knowledge in this area, how/where is it wasting that much? > I think it is time to have Engine keep a snapshot of its vm config > whenever it takes a snapshot - live or offline. I'm really not sure about the impacts when it goes out of sync. I'd rather have the VM resumed and configuration in engine updated/overwritten afterwards in first stats update than screwing up the VM Thanks, michal > > Dan. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From wei.d.chen at intel.com Fri Apr 19 09:21:19 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Fri, 19 Apr 2013 09:21:19 +0000 Subject: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated Message-ID: Hi All, Our second approach for trusted compute pools integration with oVirt seems more simple and sensible than previous VM level approach. Welcome any comments on our latest design. Thanks in advance. Link is here, http://www.ovirt.org/Trusted_compute_pools Best Regards, Dave Chen From liqiang.net at gmail.com Fri Apr 19 15:18:24 2013 From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=) Date: Fri, 19 Apr 2013 23:18:24 +0800 Subject: [Engine-devel] Why deploy failed? Please help me, thanks. Message-ID: HI?All OS:F18 Ovirt engine version: the first is 3.2.0 update to 3.2.1 and now I compile the source to other language. MEM:8G CPU:I7 DISK:60G I will use chinese language for ovirt engine, but rpm have not chinese language for default install. So I git clone source, that I compile the source success. >From link: http://www.ovirt.org/Building_oVirt_engine COMPILE COMMAND mvn clean install -Pdep,gwt-admin,gwt-user,all-langs and show message: ------------------------ ------------------------ I deploy: DEPLOY COMMAND: cd ear && mvn clean install -Pdep QUESTION: 1, I open the first page that it show ------------------ Welcome to Open Virtualization Manager. Version 3.2.1- ------------------ Source shoule be 3.3.0? If souce version 3.3.0,then I deploy is not invalid. 2, Change language is failed and is still englist. Other language is invalid. COMMAND DEPLOY: ++++++++++++++++++++++ [liqiang at engine ear]$ mvn clean install -Pdep [INFO] Scanning for projects... [WARNING] [WARNING] Some problems were encountered while building the effective model for org.ovirt.engine:engine-server-ear:ear:3.3.0-SNAPSHOT [WARNING] 'distributionManagement.repository.id' must not be 'local', this identifier is reserved for the local repository, using it for other repositories will corrupt your repository metadata. @ line 18, column 11 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. [WARNING] [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building oVirt Server EAR 3.3.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ engine-server-ear --- [INFO] Deleting /home/liqiang/ovirt-engine/ear/target [INFO] [INFO] --- maven-antrun-plugin:1.7:run (undeploy-ear) @ engine-server-ear --- [WARNING] Parameter tasks is deprecated, use target instead [INFO] Executing tasks main: [echo] *** Deleting /usr/share/jboss-as/standalone/deployments/engine.ear/... [delete] Deleting directory /usr/share/jboss-as/standalone/deployments/engine.ear [INFO] Executed tasks [INFO] [INFO] --- maven-ear-plugin:2.8:generate-application-xml (default-generate-application-xml) @ engine-server-ear --- [INFO] Generating application.xml [INFO] [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ engine-server-ear --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /home/liqiang/ovirt-engine/ear/src/main/java [INFO] Copying 1 resource [INFO] [INFO] --- maven-ear-plugin:2.8:ear (default-ear) @ engine-server-ear --- [INFO] Copying artifact [war:org.ovirt.engine.core:root-war:3.3.0-SNAPSHOT] to [root.war] (unpacked) [INFO] Copying artifact [war:org.ovirt.engine.api:restapi-webapp:3.3.0-SNAPSHOT] to [restapi.war] (unpacked) [INFO] Copying artifact [war:org.ovirt.engine.ui:userportal:3.3.0-SNAPSHOT] to [userportal.war] (unpacked) [INFO] Copying artifact [war:org.ovirt.engine.ui:webadmin:3.3.0-SNAPSHOT] to [webadmin.war] (unpacked) [INFO] Copying artifact [ejb:org.ovirt.engine.core:scheduler:3.3.0-SNAPSHOT] to [scheduler.jar] [INFO] Copying artifact [ejb:org.ovirt.engine.core:bll:3.3.0-SNAPSHOT] to [bll.jar] [INFO] Copying artifact [jar:org.ovirt.engine.core:vdsbroker:3.3.0-SNAPSHOT] to [lib/vdsbroker.jar] [INFO] Copying artifact [jar:org.ovirt.engine.core:compat:3.3.0-SNAPSHOT] to [lib/compat.jar] [INFO] Copying artifact [jar:org.ovirt.engine.core:common:3.3.0-SNAPSHOT] to [lib/common.jar] [INFO] Copying artifact [jar:org.hibernate:hibernate-validator:4.0.2.GA] to [lib/hibernate-validator.jar] [INFO] Copying artifact [jar:javax.validation:validation-api:1.0.0.GA] to [lib/validation-api.jar] [INFO] Copying artifact [jar:javax.xml.bind:jaxb-api:2.1] to [lib/jaxb-api.jar] [INFO] Copying artifact [jar:javax.xml.stream:stax-api:1.0-2] to [lib/stax-api.jar] [INFO] Copying artifact [jar:com.sun.xml.bind:jaxb-impl:2.1.3] to [lib/jaxb-impl.jar] [INFO] Copying artifact [jar:org.ovirt.engine.core:utils:3.3.0-SNAPSHOT] to [lib/utils.jar] [INFO] Copying artifact [jar:commons-beanutils:commons-beanutils:1.8.2] to [lib/commons-beanutils.jar] [INFO] Copying artifact [jar:org.apache.mina:mina-core:2.0.1] to [lib/mina-core.jar] [INFO] Copying artifact [jar:org.apache.sshd:sshd-core:0.7.0] to [lib/sshd-core.jar] [INFO] Copying artifact [jar:org.ovirt.otopi:otopi:1.0.0] to [lib/otopi.jar] [INFO] Copying artifact [jar:org.ovirt.ovirt-host-deploy:ovirt-host-deploy:1.0.0] to [lib/ovirt-host-deploy.jar] [INFO] Copying artifact [jar:org.apache.commons:commons-compress:1.4.1] to [lib/commons-compress.jar] [INFO] Copying artifact [jar:org.tukaani:xz:1.0] to [lib/xz.jar] [INFO] Copying artifact [jar:commons-lang:commons-lang:2.6] to [lib/commons-lang.jar] [INFO] Copying artifact [jar:commons-codec:commons-codec:1.4] to [lib/commons-codec.jar] [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] to [lib/xmlrpc-client.jar] [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] to [lib/xmlrpc-common.jar] [INFO] Copying artifact [jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to [lib/ws-commons-util.jar] [INFO] Copying artifact [jar:xml-apis:xml-apis:1.0.b2] to [lib/xml-apis.jar] [INFO] Copying artifact [jar:org.ovirt.engine.core:dal:3.3.0-SNAPSHOT] to [lib/dal.jar] [INFO] Copying artifact [jar:org.springframework:spring-jdbc:3.1.1.RELEASE] to [lib/spring-jdbc.jar] [INFO] Copying artifact [jar:org.springframework:spring-tx:3.1.1.RELEASE] to [lib/spring-tx.jar] [INFO] Copying artifact [jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to [lib/spring-ldap-core.jar] [INFO] Copying artifact [jar:commons-httpclient:commons-httpclient:3.1] to [lib/commons-httpclient.jar] [INFO] Copying artifact [jar:commons-collections:commons-collections:3.1] to [lib/commons-collections.jar] [INFO] Copying artifact [jar:org.quartz-scheduler:quartz:2.1.2] to [lib/quartz.jar] [INFO] Copying artifact [jar:c3p0:c3p0:0.9.1.1] to [lib/c3p0.jar] [INFO] Copying artifact [jar:org.slf4j:slf4j-api:1.6.1] to [lib/slf4j-api.jar] [INFO] Copying artifact [jar:org.ovirt.engine.core:searchbackend:3.3.0-SNAPSHOT] to [lib/searchbackend.jar] [INFO] Copying artifact [jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] to [lib/jboss-interceptors-api_1.1_spec.jar] [INFO] Copying artifact [jar:org.springframework:spring-core:3.1.1.RELEASE] to [lib/spring-core.jar] [INFO] Copying artifact [jar:org.springframework:spring-asm:3.1.1.RELEASE] to [lib/spring-asm.jar] [INFO] Copying artifact [jar:org.springframework:spring-beans:3.1.1.RELEASE] to [lib/spring-beans.jar] [INFO] Copying artifact [jar:org.springframework:spring-context:3.1.1.RELEASE] to [lib/spring-context.jar] [INFO] Copying artifact [jar:org.springframework:spring-aop:3.1.1.RELEASE] to [lib/spring-aop.jar] [INFO] Copying artifact [jar:aopalliance:aopalliance:1.0] to [lib/aopalliance.jar] [INFO] Copying artifact [jar:org.springframework:spring-expression:3.1.1.RELEASE] to [lib/spring-expression.jar] [INFO] Copy ear sources to /home/liqiang/ovirt-engine/ear/target/engine [INFO] Could not find manifest file: /home/liqiang/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF - Generating one [INFO] Building jar: /home/liqiang/ovirt-engine/ear/target/engine.ear [INFO] [INFO] --- maven-dependency-plugin:2.1:unpack (deploy-modules) @ engine-server-ear --- [INFO] Configured Artifact: org.ovirt.engine.core:dependencies:modules:3.3.0-SNAPSHOT:zip [INFO] Configured Artifact: org.ovirt.engine.core:common:modules:3.3.0-SNAPSHOT:zip [INFO] Configured Artifact: org.ovirt.engine.core:compat:modules:3.3.0-SNAPSHOT:zip [INFO] Configured Artifact: org.ovirt.engine.core:dal:modules:3.3.0-SNAPSHOT:zip [INFO] Configured Artifact: org.ovirt.engine.core:searchbackend:modules:3.3.0-SNAPSHOT:zip [INFO] Configured Artifact: org.ovirt.engine.core:tools:modules:3.3.0-SNAPSHOT:zip [INFO] Configured Artifact: org.ovirt.engine.core:utils:modules:3.3.0-SNAPSHOT:zip [INFO] Unpacking /home/liqiang/.m2/repository/org/ovirt/engine/core/dependencies/3.3.0-SNAPSHOT/dependencies-3.3.0-SNAPSHOT-modules.zip to /usr/share/jboss-as/modules with includes null and excludes:null [WARNING] Unable to expand to file /usr/share/jboss-as/modules/org/apache/commons/configuration/main/module.xml [WARNING] Unable to expand to file /usr/share/java/apache-commons-configuration.jar [INFO] Unpacking /home/liqiang/.m2/repository/org/ovirt/engine/core/common/3.3.0-SNAPSHOT/common-3.3.0-SNAPSHOT-modules.zip to /usr/share/jboss-as/modules with includes null and excludes:null [INFO] Unpacking /home/liqiang/.m2/repository/org/ovirt/engine/core/compat/3.3.0-SNAPSHOT/compat-3.3.0-SNAPSHOT-modules.zip to /usr/share/jboss-as/modules with includes null and excludes:null [INFO] Unpacking /home/liqiang/.m2/repository/org/ovirt/engine/core/dal/3.3.0-SNAPSHOT/dal-3.3.0-SNAPSHOT-modules.zip to /usr/share/jboss-as/modules with includes null and excludes:null [INFO] Unpacking /home/liqiang/.m2/repository/org/ovirt/engine/core/searchbackend/3.3.0-SNAPSHOT/searchbackend-3.3.0-SNAPSHOT-modules.zip to /usr/share/jboss-as/modules with includes null and excludes:null [INFO] Unpacking /home/liqiang/.m2/repository/org/ovirt/engine/core/tools/3.3.0-SNAPSHOT/tools-3.3.0-SNAPSHOT-modules.zip to /usr/share/jboss-as/modules with includes null and excludes:null [INFO] Unpacking /home/liqiang/.m2/repository/org/ovirt/engine/core/utils/3.3.0-SNAPSHOT/utils-3.3.0-SNAPSHOT-modules.zip to /usr/share/jboss-as/modules with includes null and excludes:null [INFO] [INFO] --- maven-antrun-plugin:1.7:run (deploy-ear) @ engine-server-ear --- [WARNING] Parameter tasks is deprecated, use target instead [INFO] Executing tasks main: [echo] *** Copying updated files to /usr/share/jboss-as/standalone/deployments/engine.ear/... [unjar] Expanding: /home/liqiang/ovirt-engine/ear/target/engine.ear into /usr/share/jboss-as/standalone/deployments/engine.ear [echo] *** Touching /usr/share/jboss-as/standalone/deployments/engine.ear/META-INF/application.xml to force redeployment of engine.ear... [echo] *** Touching engine.ear.dodeploy to force deployment of engine.ear... [INFO] Executed tasks [INFO] [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ engine-server-ear --- [INFO] Installing /home/liqiang/ovirt-engine/ear/target/engine.ear to /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear [INFO] Installing /home/liqiang/ovirt-engine/ear/pom.xml to /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 54.354s [INFO] Finished at: Fri Apr 19 10:48:39 EDT 2013 [INFO] Final Memory: 14M/191M [INFO] ------------------------------------------------------------------------ ++++++++++++++++++++++ engine-upgrade COMMAND MESSAGE: ------------------------------------ [root at engine ~]# engine-upgrade Checking for updates... (This may take several minutes)...[ DONE ] 8 Updates available: * ovirt-engine-3.2.1-1.fc18.noarch * ovirt-engine-tools-3.2.1-1.fc18.noarch * ovirt-engine-backend-3.2.1-1.fc18.noarch * ovirt-engine-dbscripts-3.2.1-1.fc18.noarch * ovirt-engine-genericapi-3.2.1-1.fc18.noarch * ovirt-engine-restapi-3.2.1-1.fc18.noarch * ovirt-engine-userportal-3.2.1-1.fc18.noarch * ovirt-engine-webadmin-portal-3.2.1-1.fc18.noarch During the upgrade process, oVirt Engine will not be accessible. All existing running virtual machines will continue but you will not be able to start or stop any new virtual machines during the process. Would you like to proceed? (yes|no): yes Stopping ovirt-engine service... [ DONE ] Stopping DB related services... [ DONE ] Pre-upgrade validations... [ DONE ] Backing Up Database... [ DONE ] Rename Database... [ DONE ] Updating rpms... [ DONE ] Updating Database... [ DONE ] Restore Database name... [ DONE ] Preparing CA... [ DONE ] Running post install configuration... [ DONE ] Starting ovirt-engine service... [ DONE ] oVirt Engine upgrade completed successfully! * Upgrade log available at /var/log/ovirt-engine/ovirt-engine-upgrade_2013_04_19_10_39_54.log * DB Backup available at /var/lib/ovirt-engine/backups/ovirt-engine_db_backup_2013_04_19_10_39_54.sql ------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alonbl at redhat.com Fri Apr 19 15:24:46 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Fri, 19 Apr 2013 11:24:46 -0400 (EDT) Subject: [Engine-devel] Why deploy failed? Please help me, thanks. In-Reply-To: References: Message-ID: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> Please try setup product without tweaks if you don't have real reason to. Close the repository, then: $ make tarball $ rpmbuild -t Then install the result rpms as usual. Alternatively, you can try out soon to be merged development environment[1][2] [1] https://github.com/alonbl/ovirt-engine/tree/otopi [2] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer ----- Original Message ----- > From: "??" > To: engine-devel at ovirt.org > Sent: Friday, April 19, 2013 6:18:24 PM > Subject: [Engine-devel] Why deploy failed? Please help me, thanks. > > > HI?All > > OS:F18 > Ovirt engine version: > the first is 3.2.0 > update to 3.2.1 > and now I compile the source to other language. > MEM:8G > CPU:I7 > DISK:60G > > > I will use chinese language for ovirt engine, > but rpm have not chinese language for default install. > > So I git clone source, that I compile the source success. > From link: > http://www.ovirt.org/Building_oVirt_engine > > COMPILE COMMAND > mvn clean install -Pdep,gwt-admin,gwt-user,all-langs > and show message: > ------------------------ > > ------------------------ > > I deploy: > DEPLOY COMMAND: > cd ear && mvn clean install -Pdep > > QUESTION: > 1, > I open the first page that it show > ------------------ > Welcome to Open Virtualization Manager. > Version 3.2.1- > ------------------ > Source shoule be 3.3.0? > If souce version 3.3.0,then I deploy is not invalid. > > 2, > Change language is failed and is still englist. > Other language is invalid. > COMMAND DEPLOY: > ++++++++++++++++++++++ > [liqiang at engine ear]$ mvn clean install -Pdep > [INFO] Scanning for projects... > [WARNING] > [WARNING] Some problems were encountered while building the effective model > for org.ovirt.engine:engine-server-ear:ear:3.3.0-SNAPSHOT > [WARNING] ' distributionManagement.repository.id ' must not be 'local', this > identifier is reserved for the local repository, using it for other > repositories will corrupt your repository metadata. @ line 18, column 11 > [WARNING] > [WARNING] It is highly recommended to fix these problems because they > threaten the stability of your build. > [WARNING] > [WARNING] For this reason, future Maven versions might no longer support > building such malformed projects. > [WARNING] > [INFO] > [INFO] > ------------------------------------------------------------------------ > [INFO] Building oVirt Server EAR 3.3.0-SNAPSHOT > [INFO] > ------------------------------------------------------------------------ > [INFO] > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ engine-server-ear > --- > [INFO] Deleting /home/liqiang/ovirt-engine/ear/target > [INFO] > [INFO] --- maven-antrun-plugin:1.7:run (undeploy-ear) @ engine-server-ear --- > [WARNING] Parameter tasks is deprecated, use target instead > [INFO] Executing tasks > > main: > [echo] *** Deleting /usr/share/jboss-as/standalone/deployments/engine.ear/... > [delete] Deleting directory > /usr/share/jboss-as/standalone/deployments/engine.ear > [INFO] Executed tasks > [INFO] > [INFO] --- maven-ear-plugin:2.8:generate-application-xml > (default-generate-application-xml) @ engine-server-ear --- > [INFO] Generating application.xml > [INFO] > [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ > engine-server-ear --- > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] skip non existing resourceDirectory > /home/liqiang/ovirt-engine/ear/src/main/java > [INFO] Copying 1 resource > [INFO] > [INFO] --- maven-ear-plugin:2.8:ear (default-ear) @ engine-server-ear --- > [INFO] Copying artifact [war:org.ovirt.engine.core:root-war:3.3.0-SNAPSHOT] > to [root.war] (unpacked) > [INFO] Copying artifact > [war:org.ovirt.engine.api:restapi-webapp:3.3.0-SNAPSHOT] to [restapi.war] > (unpacked) > [INFO] Copying artifact [war:org.ovirt.engine.ui:userportal:3.3.0-SNAPSHOT] > to [userportal.war] (unpacked) > [INFO] Copying artifact [war:org.ovirt.engine.ui:webadmin:3.3.0-SNAPSHOT] to > [webadmin.war] (unpacked) > [INFO] Copying artifact [ejb:org.ovirt.engine.core:scheduler:3.3.0-SNAPSHOT] > to [scheduler.jar] > [INFO] Copying artifact [ejb:org.ovirt.engine.core:bll:3.3.0-SNAPSHOT] to > [bll.jar] > [INFO] Copying artifact [jar:org.ovirt.engine.core:vdsbroker:3.3.0-SNAPSHOT] > to [lib/vdsbroker.jar] > [INFO] Copying artifact [jar:org.ovirt.engine.core:compat:3.3.0-SNAPSHOT] to > [lib/compat.jar] > [INFO] Copying artifact [jar:org.ovirt.engine.core:common:3.3.0-SNAPSHOT] to > [lib/common.jar] > [INFO] Copying artifact [jar:org.hibernate:hibernate-validator: 4.0.2.GA ] to > [lib/hibernate-validator.jar] > [INFO] Copying artifact [jar:javax.validation:validation-api: 1.0.0.GA ] to > [lib/validation-api.jar] > [INFO] Copying artifact [jar:javax.xml.bind:jaxb-api:2.1] to > [lib/jaxb-api.jar] > [INFO] Copying artifact [jar:javax.xml.stream:stax-api:1.0-2] to > [lib/stax-api.jar] > [INFO] Copying artifact [jar:com.sun.xml.bind:jaxb-impl:2.1.3] to > [lib/jaxb-impl.jar] > [INFO] Copying artifact [jar:org.ovirt.engine.core:utils:3.3.0-SNAPSHOT] to > [lib/utils.jar] > [INFO] Copying artifact [jar:commons-beanutils:commons-beanutils:1.8.2] to > [lib/commons-beanutils.jar] > [INFO] Copying artifact [jar:org.apache.mina:mina-core:2.0.1] to > [lib/mina-core.jar] > [INFO] Copying artifact [jar:org.apache.sshd:sshd-core:0.7.0] to > [lib/sshd-core.jar] > [INFO] Copying artifact [jar:org.ovirt.otopi:otopi:1.0.0] to [lib/otopi.jar] > [INFO] Copying artifact > [jar:org.ovirt.ovirt-host-deploy:ovirt-host-deploy:1.0.0] to > [lib/ovirt-host-deploy.jar] > [INFO] Copying artifact [jar:org.apache.commons:commons-compress:1.4.1] to > [lib/commons-compress.jar] > [INFO] Copying artifact [jar:org.tukaani:xz:1.0] to [lib/xz.jar] > [INFO] Copying artifact [jar:commons-lang:commons-lang:2.6] to > [lib/commons-lang.jar] > [INFO] Copying artifact [jar:commons-codec:commons-codec:1.4] to > [lib/commons-codec.jar] > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] to > [lib/xmlrpc-client.jar] > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] to > [lib/xmlrpc-common.jar] > [INFO] Copying artifact > [jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to > [lib/ws-commons-util.jar] > [INFO] Copying artifact [jar:xml-apis:xml-apis:1.0.b2] to [lib/xml-apis.jar] > [INFO] Copying artifact [jar:org.ovirt.engine.core:dal:3.3.0-SNAPSHOT] to > [lib/dal.jar] > [INFO] Copying artifact [jar:org.springframework:spring-jdbc:3.1.1.RELEASE] > to [lib/spring-jdbc.jar] > [INFO] Copying artifact [jar:org.springframework:spring-tx:3.1.1.RELEASE] to > [lib/spring-tx.jar] > [INFO] Copying artifact > [jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to > [lib/spring-ldap-core.jar] > [INFO] Copying artifact [jar:commons-httpclient:commons-httpclient:3.1] to > [lib/commons-httpclient.jar] > [INFO] Copying artifact [jar:commons-collections:commons-collections:3.1] to > [lib/commons-collections.jar] > [INFO] Copying artifact [jar:org.quartz-scheduler:quartz:2.1.2] to > [lib/quartz.jar] > [INFO] Copying artifact [jar:c3p0:c3p0:0.9.1.1] to [lib/c3p0.jar] > [INFO] Copying artifact [jar:org.slf4j:slf4j-api:1.6.1] to > [lib/slf4j-api.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:searchbackend:3.3.0-SNAPSHOT] to > [lib/searchbackend.jar] > [INFO] Copying artifact > [jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] > to [lib/jboss-interceptors-api_1.1_spec.jar] > [INFO] Copying artifact [jar:org.springframework:spring-core:3.1.1.RELEASE] > to [lib/spring-core.jar] > [INFO] Copying artifact [jar:org.springframework:spring-asm:3.1.1.RELEASE] to > [lib/spring-asm.jar] > [INFO] Copying artifact [jar:org.springframework:spring-beans:3.1.1.RELEASE] > to [lib/spring-beans.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-context:3.1.1.RELEASE] to > [lib/spring-context.jar] > [INFO] Copying artifact [jar:org.springframework:spring-aop:3.1.1.RELEASE] to > [lib/spring-aop.jar] > [INFO] Copying artifact [jar:aopalliance:aopalliance:1.0] to > [lib/aopalliance.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-expression:3.1.1.RELEASE] to > [lib/spring-expression.jar] > [INFO] Copy ear sources to /home/liqiang/ovirt-engine/ear/target/engine > [INFO] Could not find manifest file: > /home/liqiang/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF - > Generating one > [INFO] Building jar: /home/liqiang/ovirt-engine/ear/target/engine.ear > [INFO] > [INFO] --- maven-dependency-plugin:2.1:unpack (deploy-modules) @ > engine-server-ear --- > [INFO] Configured Artifact: > org.ovirt.engine.core:dependencies:modules:3.3.0-SNAPSHOT:zip > [INFO] Configured Artifact: > org.ovirt.engine.core:common:modules:3.3.0-SNAPSHOT:zip > [INFO] Configured Artifact: > org.ovirt.engine.core:compat:modules:3.3.0-SNAPSHOT:zip > [INFO] Configured Artifact: > org.ovirt.engine.core:dal:modules:3.3.0-SNAPSHOT:zip > [INFO] Configured Artifact: > org.ovirt.engine.core:searchbackend:modules:3.3.0-SNAPSHOT:zip > [INFO] Configured Artifact: > org.ovirt.engine.core:tools:modules:3.3.0-SNAPSHOT:zip > [INFO] Configured Artifact: > org.ovirt.engine.core:utils:modules:3.3.0-SNAPSHOT:zip > [INFO] Unpacking > /home/liqiang/.m2/repository/org/ovirt/engine/core/dependencies/3.3.0-SNAPSHOT/dependencies-3.3.0-SNAPSHOT-modules.zip > to > /usr/share/jboss-as/modules > with includes null and excludes:null > [WARNING] Unable to expand to file > /usr/share/jboss-as/modules/org/apache/commons/configuration/main/module.xml > [WARNING] Unable to expand to file > /usr/share/java/apache-commons-configuration.jar > [INFO] Unpacking > /home/liqiang/.m2/repository/org/ovirt/engine/core/common/3.3.0-SNAPSHOT/common-3.3.0-SNAPSHOT-modules.zip > to > /usr/share/jboss-as/modules > with includes null and excludes:null > [INFO] Unpacking > /home/liqiang/.m2/repository/org/ovirt/engine/core/compat/3.3.0-SNAPSHOT/compat-3.3.0-SNAPSHOT-modules.zip > to > /usr/share/jboss-as/modules > with includes null and excludes:null > [INFO] Unpacking > /home/liqiang/.m2/repository/org/ovirt/engine/core/dal/3.3.0-SNAPSHOT/dal-3.3.0-SNAPSHOT-modules.zip > to > /usr/share/jboss-as/modules > with includes null and excludes:null > [INFO] Unpacking > /home/liqiang/.m2/repository/org/ovirt/engine/core/searchbackend/3.3.0-SNAPSHOT/searchbackend-3.3.0-SNAPSHOT-modules.zip > to > /usr/share/jboss-as/modules > with includes null and excludes:null > [INFO] Unpacking > /home/liqiang/.m2/repository/org/ovirt/engine/core/tools/3.3.0-SNAPSHOT/tools-3.3.0-SNAPSHOT-modules.zip > to > /usr/share/jboss-as/modules > with includes null and excludes:null > [INFO] Unpacking > /home/liqiang/.m2/repository/org/ovirt/engine/core/utils/3.3.0-SNAPSHOT/utils-3.3.0-SNAPSHOT-modules.zip > to > /usr/share/jboss-as/modules > with includes null and excludes:null > [INFO] > [INFO] --- maven-antrun-plugin:1.7:run (deploy-ear) @ engine-server-ear --- > [WARNING] Parameter tasks is deprecated, use target instead > [INFO] Executing tasks > > main: > [echo] *** Copying updated files to > /usr/share/jboss-as/standalone/deployments/engine.ear/... > [unjar] Expanding: /home/liqiang/ovirt-engine/ear/target/engine.ear into > /usr/share/jboss-as/standalone/deployments/engine.ear > [echo] *** Touching > /usr/share/jboss-as/standalone/deployments/engine.ear/META-INF/application.xml > to force redeployment of engine.ear... > [echo] *** Touching engine.ear.dodeploy to force deployment of engine.ear... > [INFO] Executed tasks > [INFO] > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ > engine-server-ear --- > [INFO] Installing /home/liqiang/ovirt-engine/ear/target/engine.ear to > /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear > [INFO] Installing /home/liqiang/ovirt-engine/ear/pom.xml to > /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 54.354s > [INFO] Finished at: Fri Apr 19 10:48:39 EDT 2013 > [INFO] Final Memory: 14M/191M > [INFO] > ------------------------------------------------------------------------ > ++++++++++++++++++++++ > > > engine-upgrade > COMMAND MESSAGE: > ------------------------------------ > [root at engine ~]# engine-upgrade > > Checking for updates... (This may take several minutes)...[ DONE ] > 8 Updates available: > * ovirt-engine-3.2.1-1.fc18.noarch > * ovirt-engine-tools-3.2.1-1.fc18.noarch > * ovirt-engine-backend-3.2.1-1.fc18.noarch > * ovirt-engine-dbscripts-3.2.1-1.fc18.noarch > * ovirt-engine-genericapi-3.2.1-1.fc18.noarch > * ovirt-engine-restapi-3.2.1-1.fc18.noarch > * ovirt-engine-userportal-3.2.1-1.fc18.noarch > * ovirt-engine-webadmin-portal-3.2.1-1.fc18.noarch > > During the upgrade process, oVirt Engine will not be accessible. > All existing running virtual machines will continue but you will not be able > to > start or stop any new virtual machines during the process. > > Would you like to proceed? (yes|no): yes > Stopping ovirt-engine service... [ DONE ] > Stopping DB related services... [ DONE ] > Pre-upgrade validations... [ DONE ] > Backing Up Database... [ DONE ] > Rename Database... [ DONE ] > Updating rpms... [ DONE ] > Updating Database... [ DONE ] > Restore Database name... [ DONE ] > Preparing CA... [ DONE ] > Running post install configuration... [ DONE ] > Starting ovirt-engine service... [ DONE ] > > oVirt Engine upgrade completed successfully! > > * Upgrade log available at > /var/log/ovirt-engine/ovirt-engine-upgrade_2013_04_19_10_39_54.log > * DB Backup available at > /var/lib/ovirt-engine/backups/ovirt-engine_db_backup_2013_04_19_10_39_54.sql > ------------------------------------ > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From vszocs at redhat.com Fri Apr 19 18:46:24 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 19 Apr 2013 14:46:24 -0400 (EDT) Subject: [Engine-devel] Why deploy failed? Please help me, thanks. In-Reply-To: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> References: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> Message-ID: <768646248.3461998.1366397184625.JavaMail.root@redhat.com> Hi, > COMPILE COMMAND > mvn clean install -Pdep,gwt-admin,gwt-user,all-langs > Change language is failed and is still englist. > Other language is invalid. Using "all-langs" profile means compiling GUI for all supported languages (including Chinese). Alternatively, to speed up GWT compilation, you can compile only for English and Chinese: $ mvn clean install -Pdep,gwt-admin,gwt-user -Dgwt.locale=en_US,zh_CN If the Maven build succeeds but Chinese language still doesn't work in GUI, there's something wrong with deployment of Engine EAR to JBoss ("dep" profile). As Alon suggests, please try building Engine RPMs via "make", but IIRC you have to edit Makefile to specify Chinese language support: EXTRA_BUILD_FLAGS=-Dgwt.locale=en_US,zh_CN Vojtech ----- Original Message ----- From: "Alon Bar-Lev" To: "??" Cc: engine-devel at ovirt.org Sent: Friday, April 19, 2013 5:24:46 PM Subject: Re: [Engine-devel] Why deploy failed? Please help me, thanks. Please try setup product without tweaks if you don't have real reason to. Close the repository, then: $ make tarball $ rpmbuild -t Then install the result rpms as usual. Alternatively, you can try out soon to be merged development environment[1][2] [1] https://github.com/alonbl/ovirt-engine/tree/otopi [2] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer ----- Original Message ----- > From: "??" > To: engine-devel at ovirt.org > Sent: Friday, April 19, 2013 6:18:24 PM > Subject: [Engine-devel] Why deploy failed? Please help me, thanks. > > > HI?All > > OS:F18 > Ovirt engine version: > the first is 3.2.0 > update to 3.2.1 > and now I compile the source to other language. > MEM:8G > CPU:I7 > DISK:60G > > > I will use chinese language for ovirt engine, > but rpm have not chinese language for default install. > > So I git clone source, that I compile the source success. > From link: > http://www.ovirt.org/Building_oVirt_engine > > COMPILE COMMAND > mvn clean install -Pdep,gwt-admin,gwt-user,all-langs > and show message: > ------------------------ > > ------------------------ > > I deploy: > DEPLOY COMMAND: > cd ear && mvn clean install -Pdep > > QUESTION: > 1, > I open the first page that it show > ------------------ > Welcome to Open Virtualization Manager. > Version 3.2.1- > ------------------ > Source shoule be 3.3.0? > If souce version 3.3.0,then I deploy is not invalid. > > 2, > Change language is failed and is still englist. > Other language is invalid. > COMMAND DEPLOY: > ++++++++++++++++++++++ > [liqiang at engine ear]$ mvn clean install -Pdep > [INFO] Scanning for projects... > [WARNING] > [WARNING] Some problems were encountered while building the effective model > for org.ovirt.engine:engine-server-ear:ear:3.3.0-SNAPSHOT > [WARNING] ' distributionManagement.repository.id ' must not be 'local', this > identifier is reserved for the local repository, using it for other > repositories will corrupt your repository metadata. @ line 18, column 11 > [WARNING] > [WARNING] It is highly recommended to fix these problems because they > threaten the stability of your build. > [WARNING] > [WARNING] For this reason, future Maven versions might no longer support > building such malformed projects. > [WARNING] > [INFO] > [INFO] > ------------------------------------------------------------------------ > [INFO] Building oVirt Server EAR 3.3.0-SNAPSHOT > [INFO] > ------------------------------------------------------------------------ > [INFO] > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ engine-server-ear > --- > [INFO] Deleting /home/liqiang/ovirt-engine/ear/target > [INFO] > [INFO] --- maven-antrun-plugin:1.7:run (undeploy-ear) @ engine-server-ear --- > [WARNING] Parameter tasks is deprecated, use target instead > [INFO] Executing tasks > > main: > [echo] *** Deleting /usr/share/jboss-as/standalone/deployments/engine.ear/... > [delete] Deleting directory > /usr/share/jboss-as/standalone/deployments/engine.ear > [INFO] Executed tasks > [INFO] > [INFO] --- maven-ear-plugin:2.8:generate-application-xml > (default-generate-application-xml) @ engine-server-ear --- > [INFO] Generating application.xml > [INFO] > [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ > engine-server-ear --- > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] skip non existing resourceDirectory > /home/liqiang/ovirt-engine/ear/src/main/java > [INFO] Copying 1 resource > [INFO] > [INFO] --- maven-ear-plugin:2.8:ear (default-ear) @ engine-server-ear --- > [INFO] Copying artifact [war:org.ovirt.engine.core:root-war:3.3.0-SNAPSHOT] > to [root.war] (unpacked) > [INFO] Copying artifact > [war:org.ovirt.engine.api:restapi-webapp:3.3.0-SNAPSHOT] to [restapi.war] > (unpacked) > [INFO] Copying artifact [war:org.ovirt.engine.ui:userportal:3.3.0-SNAPSHOT] > to [userportal.war] (unpacked) > [INFO] Copying artifact [war:org.ovirt.engine.ui:webadmin:3.3.0-SNAPSHOT] to > [webadmin.war] (unpacked) > [INFO] Copying artifact [ejb:org.ovirt.engine.core:scheduler:3.3.0-SNAPSHOT] > to [scheduler.jar] > [INFO] Copying artifact [ejb:org.ovirt.engine.core:bll:3.3.0-SNAPSHOT] to > [bll.jar] > [INFO] Copying artifact [jar:org.ovirt.engine.core:vdsbroker:3.3.0-SNAPSHOT] > to [lib/vdsbroker.jar] > [INFO] Copying artifact [jar:org.ovirt.engine.core:compat:3.3.0-SNAPSHOT] to > [lib/compat.jar] > [INFO] Copying artifact [jar:org.ovirt.engine.core:common:3.3.0-SNAPSHOT] to > [lib/common.jar] > [INFO] Copying artifact [jar:org.hibernate:hibernate-validator: 4.0.2.GA ] to > [lib/hibernate-validator.jar] > [INFO] Copying artifact [jar:javax.validation:validation-api: 1.0.0.GA ] to > [lib/validation-api.jar] > [INFO] Copying artifact [jar:javax.xml.bind:jaxb-api:2.1] to > [lib/jaxb-api.jar] > [INFO] Copying artifact [jar:javax.xml.stream:stax-api:1.0-2] to > [lib/stax-api.jar] > [INFO] Copying artifact [jar:com.sun.xml.bind:jaxb-impl:2.1.3] to > [lib/jaxb-impl.jar] > [INFO] Copying artifact [jar:org.ovirt.engine.core:utils:3.3.0-SNAPSHOT] to > [lib/utils.jar] > [INFO] Copying artifact [jar:commons-beanutils:commons-beanutils:1.8.2] to > [lib/commons-beanutils.jar] > [INFO] Copying artifact [jar:org.apache.mina:mina-core:2.0.1] to > [lib/mina-core.jar] > [INFO] Copying artifact [jar:org.apache.sshd:sshd-core:0.7.0] to > [lib/sshd-core.jar] > [INFO] Copying artifact [jar:org.ovirt.otopi:otopi:1.0.0] to [lib/otopi.jar] > [INFO] Copying artifact > [jar:org.ovirt.ovirt-host-deploy:ovirt-host-deploy:1.0.0] to > [lib/ovirt-host-deploy.jar] > [INFO] Copying artifact [jar:org.apache.commons:commons-compress:1.4.1] to > [lib/commons-compress.jar] > [INFO] Copying artifact [jar:org.tukaani:xz:1.0] to [lib/xz.jar] > [INFO] Copying artifact [jar:commons-lang:commons-lang:2.6] to > [lib/commons-lang.jar] > [INFO] Copying artifact [jar:commons-codec:commons-codec:1.4] to > [lib/commons-codec.jar] > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] to > [lib/xmlrpc-client.jar] > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] to > [lib/xmlrpc-common.jar] > [INFO] Copying artifact > [jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to > [lib/ws-commons-util.jar] > [INFO] Copying artifact [jar:xml-apis:xml-apis:1.0.b2] to [lib/xml-apis.jar] > [INFO] Copying artifact [jar:org.ovirt.engine.core:dal:3.3.0-SNAPSHOT] to > [lib/dal.jar] > [INFO] Copying artifact [jar:org.springframework:spring-jdbc:3.1.1.RELEASE] > to [lib/spring-jdbc.jar] > [INFO] Copying artifact [jar:org.springframework:spring-tx:3.1.1.RELEASE] to > [lib/spring-tx.jar] > [INFO] Copying artifact > [jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to > [lib/spring-ldap-core.jar] > [INFO] Copying artifact [jar:commons-httpclient:commons-httpclient:3.1] to > [lib/commons-httpclient.jar] > [INFO] Copying artifact [jar:commons-collections:commons-collections:3.1] to > [lib/commons-collections.jar] > [INFO] Copying artifact [jar:org.quartz-scheduler:quartz:2.1.2] to > [lib/quartz.jar] > [INFO] Copying artifact [jar:c3p0:c3p0:0.9.1.1] to [lib/c3p0.jar] > [INFO] Copying artifact [jar:org.slf4j:slf4j-api:1.6.1] to > [lib/slf4j-api.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:searchbackend:3.3.0-SNAPSHOT] to > [lib/searchbackend.jar] > [INFO] Copying artifact > [jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] > to [lib/jboss-interceptors-api_1.1_spec.jar] > [INFO] Copying artifact [jar:org.springframework:spring-core:3.1.1.RELEASE] > to [lib/spring-core.jar] > [INFO] Copying artifact [jar:org.springframework:spring-asm:3.1.1.RELEASE] to > [lib/spring-asm.jar] > [INFO] Copying artifact [jar:org.springframework:spring-beans:3.1.1.RELEASE] > to [lib/spring-beans.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-context:3.1.1.RELEASE] to > [lib/spring-context.jar] > [INFO] Copying artifact [jar:org.springframework:spring-aop:3.1.1.RELEASE] to > [lib/spring-aop.jar] > [INFO] Copying artifact [jar:aopalliance:aopalliance:1.0] to > [lib/aopalliance.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-expression:3.1.1.RELEASE] to > [lib/spring-expression.jar] > [INFO] Copy ear sources to /home/liqiang/ovirt-engine/ear/target/engine > [INFO] Could not find manifest file: > /home/liqiang/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF - > Generating one > [INFO] Building jar: /home/liqiang/ovirt-engine/ear/target/engine.ear > [INFO] > [INFO] --- maven-dependency-plugin:2.1:unpack (deploy-modules) @ > engine-server-ear --- > [INFO] Configured Artifact: > org.ovirt.engine.core:dependencies:modules:3.3.0-SNAPSHOT:zip > [INFO] Configured Artifact: > org.ovirt.engine.core:common:modules:3.3.0-SNAPSHOT:zip > [INFO] Configured Artifact: > org.ovirt.engine.core:compat:modules:3.3.0-SNAPSHOT:zip > [INFO] Configured Artifact: > org.ovirt.engine.core:dal:modules:3.3.0-SNAPSHOT:zip > [INFO] Configured Artifact: > org.ovirt.engine.core:searchbackend:modules:3.3.0-SNAPSHOT:zip > [INFO] Configured Artifact: > org.ovirt.engine.core:tools:modules:3.3.0-SNAPSHOT:zip > [INFO] Configured Artifact: > org.ovirt.engine.core:utils:modules:3.3.0-SNAPSHOT:zip > [INFO] Unpacking > /home/liqiang/.m2/repository/org/ovirt/engine/core/dependencies/3.3.0-SNAPSHOT/dependencies-3.3.0-SNAPSHOT-modules.zip > to > /usr/share/jboss-as/modules > with includes null and excludes:null > [WARNING] Unable to expand to file > /usr/share/jboss-as/modules/org/apache/commons/configuration/main/module.xml > [WARNING] Unable to expand to file > /usr/share/java/apache-commons-configuration.jar > [INFO] Unpacking > /home/liqiang/.m2/repository/org/ovirt/engine/core/common/3.3.0-SNAPSHOT/common-3.3.0-SNAPSHOT-modules.zip > to > /usr/share/jboss-as/modules > with includes null and excludes:null > [INFO] Unpacking > /home/liqiang/.m2/repository/org/ovirt/engine/core/compat/3.3.0-SNAPSHOT/compat-3.3.0-SNAPSHOT-modules.zip > to > /usr/share/jboss-as/modules > with includes null and excludes:null > [INFO] Unpacking > /home/liqiang/.m2/repository/org/ovirt/engine/core/dal/3.3.0-SNAPSHOT/dal-3.3.0-SNAPSHOT-modules.zip > to > /usr/share/jboss-as/modules > with includes null and excludes:null > [INFO] Unpacking > /home/liqiang/.m2/repository/org/ovirt/engine/core/searchbackend/3.3.0-SNAPSHOT/searchbackend-3.3.0-SNAPSHOT-modules.zip > to > /usr/share/jboss-as/modules > with includes null and excludes:null > [INFO] Unpacking > /home/liqiang/.m2/repository/org/ovirt/engine/core/tools/3.3.0-SNAPSHOT/tools-3.3.0-SNAPSHOT-modules.zip > to > /usr/share/jboss-as/modules > with includes null and excludes:null > [INFO] Unpacking > /home/liqiang/.m2/repository/org/ovirt/engine/core/utils/3.3.0-SNAPSHOT/utils-3.3.0-SNAPSHOT-modules.zip > to > /usr/share/jboss-as/modules > with includes null and excludes:null > [INFO] > [INFO] --- maven-antrun-plugin:1.7:run (deploy-ear) @ engine-server-ear --- > [WARNING] Parameter tasks is deprecated, use target instead > [INFO] Executing tasks > > main: > [echo] *** Copying updated files to > /usr/share/jboss-as/standalone/deployments/engine.ear/... > [unjar] Expanding: /home/liqiang/ovirt-engine/ear/target/engine.ear into > /usr/share/jboss-as/standalone/deployments/engine.ear > [echo] *** Touching > /usr/share/jboss-as/standalone/deployments/engine.ear/META-INF/application.xml > to force redeployment of engine.ear... > [echo] *** Touching engine.ear.dodeploy to force deployment of engine.ear... > [INFO] Executed tasks > [INFO] > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ > engine-server-ear --- > [INFO] Installing /home/liqiang/ovirt-engine/ear/target/engine.ear to > /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear > [INFO] Installing /home/liqiang/ovirt-engine/ear/pom.xml to > /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 54.354s > [INFO] Finished at: Fri Apr 19 10:48:39 EDT 2013 > [INFO] Final Memory: 14M/191M > [INFO] > ------------------------------------------------------------------------ > ++++++++++++++++++++++ > > > engine-upgrade > COMMAND MESSAGE: > ------------------------------------ > [root at engine ~]# engine-upgrade > > Checking for updates... (This may take several minutes)...[ DONE ] > 8 Updates available: > * ovirt-engine-3.2.1-1.fc18.noarch > * ovirt-engine-tools-3.2.1-1.fc18.noarch > * ovirt-engine-backend-3.2.1-1.fc18.noarch > * ovirt-engine-dbscripts-3.2.1-1.fc18.noarch > * ovirt-engine-genericapi-3.2.1-1.fc18.noarch > * ovirt-engine-restapi-3.2.1-1.fc18.noarch > * ovirt-engine-userportal-3.2.1-1.fc18.noarch > * ovirt-engine-webadmin-portal-3.2.1-1.fc18.noarch > > During the upgrade process, oVirt Engine will not be accessible. > All existing running virtual machines will continue but you will not be able > to > start or stop any new virtual machines during the process. > > Would you like to proceed? (yes|no): yes > Stopping ovirt-engine service... [ DONE ] > Stopping DB related services... [ DONE ] > Pre-upgrade validations... [ DONE ] > Backing Up Database... [ DONE ] > Rename Database... [ DONE ] > Updating rpms... [ DONE ] > Updating Database... [ DONE ] > Restore Database name... [ DONE ] > Preparing CA... [ DONE ] > Running post install configuration... [ DONE ] > Starting ovirt-engine service... [ DONE ] > > oVirt Engine upgrade completed successfully! > > * Upgrade log available at > /var/log/ovirt-engine/ovirt-engine-upgrade_2013_04_19_10_39_54.log > * DB Backup available at > /var/lib/ovirt-engine/backups/ovirt-engine_db_backup_2013_04_19_10_39_54.sql > ------------------------------------ > > > > _______________________________________________ > 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 Fri Apr 19 18:49:43 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Fri, 19 Apr 2013 14:49:43 -0400 (EDT) Subject: [Engine-devel] Why deploy failed? Please help me, thanks. In-Reply-To: <768646248.3461998.1366397184625.JavaMail.root@redhat.com> References: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> <768646248.3461998.1366397184625.JavaMail.root@redhat.com> Message-ID: <2076251227.1825669.1366397383543.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Vojtech Szocs" > To: "Alon Bar-Lev" > Cc: "??" , engine-devel at ovirt.org > Sent: Friday, April 19, 2013 9:46:24 PM > Subject: Re: [Engine-devel] Why deploy failed? Please help me, thanks. > > Hi, > > > COMPILE COMMAND > > mvn clean install -Pdep,gwt-admin,gwt-user,all-langs > > > Change language is failed and is still englist. > > Other language is invalid. > > Using "all-langs" profile means compiling GUI for all supported languages > (including Chinese). > > Alternatively, to speed up GWT compilation, you can compile only for English > and Chinese: > > $ mvn clean install -Pdep,gwt-admin,gwt-user -Dgwt.locale=en_US,zh_CN > > If the Maven build succeeds but Chinese language still doesn't work in GUI, > there's something wrong with deployment of Engine EAR to JBoss ("dep" > profile). > > As Alon suggests, please try building Engine RPMs via "make", but IIRC you > have to edit Makefile to specify Chinese language support: > > EXTRA_BUILD_FLAGS=-Dgwt.locale=en_US,zh_CN rpmbuild --define="EXTRA_BUILD_FLAGS -Dgwt.locale=en_US,zh_CN" -tb > > Vojtech > > > ----- Original Message ----- > From: "Alon Bar-Lev" > To: "??" > Cc: engine-devel at ovirt.org > Sent: Friday, April 19, 2013 5:24:46 PM > Subject: Re: [Engine-devel] Why deploy failed? Please help me, thanks. > > Please try setup product without tweaks if you don't have real reason to. > > Close the repository, then: > $ make tarball > $ rpmbuild -t > > Then install the result rpms as usual. > > Alternatively, you can try out soon to be merged development > environment[1][2] > > [1] https://github.com/alonbl/ovirt-engine/tree/otopi > [2] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer > > > ----- Original Message ----- > > From: "??" > > To: engine-devel at ovirt.org > > Sent: Friday, April 19, 2013 6:18:24 PM > > Subject: [Engine-devel] Why deploy failed? Please help me, thanks. > > > > > > HI?All > > > > OS:F18 > > Ovirt engine version: > > the first is 3.2.0 > > update to 3.2.1 > > and now I compile the source to other language. > > MEM:8G > > CPU:I7 > > DISK:60G > > > > > > I will use chinese language for ovirt engine, > > but rpm have not chinese language for default install. > > > > So I git clone source, that I compile the source success. > > From link: > > http://www.ovirt.org/Building_oVirt_engine > > > > COMPILE COMMAND > > mvn clean install -Pdep,gwt-admin,gwt-user,all-langs > > and show message: > > ------------------------ > > > > ------------------------ > > > > I deploy: > > DEPLOY COMMAND: > > cd ear && mvn clean install -Pdep > > > > QUESTION: > > 1, > > I open the first page that it show > > ------------------ > > Welcome to Open Virtualization Manager. > > Version 3.2.1- > > ------------------ > > Source shoule be 3.3.0? > > If souce version 3.3.0,then I deploy is not invalid. > > > > 2, > > Change language is failed and is still englist. > > Other language is invalid. > > COMMAND DEPLOY: > > ++++++++++++++++++++++ > > [liqiang at engine ear]$ mvn clean install -Pdep > > [INFO] Scanning for projects... > > [WARNING] > > [WARNING] Some problems were encountered while building the effective model > > for org.ovirt.engine:engine-server-ear:ear:3.3.0-SNAPSHOT > > [WARNING] ' distributionManagement.repository.id ' must not be 'local', > > this > > identifier is reserved for the local repository, using it for other > > repositories will corrupt your repository metadata. @ line 18, column 11 > > [WARNING] > > [WARNING] It is highly recommended to fix these problems because they > > threaten the stability of your build. > > [WARNING] > > [WARNING] For this reason, future Maven versions might no longer support > > building such malformed projects. > > [WARNING] > > [INFO] > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] Building oVirt Server EAR 3.3.0-SNAPSHOT > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] > > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ > > engine-server-ear > > --- > > [INFO] Deleting /home/liqiang/ovirt-engine/ear/target > > [INFO] > > [INFO] --- maven-antrun-plugin:1.7:run (undeploy-ear) @ engine-server-ear > > --- > > [WARNING] Parameter tasks is deprecated, use target instead > > [INFO] Executing tasks > > > > main: > > [echo] *** Deleting > > /usr/share/jboss-as/standalone/deployments/engine.ear/... > > [delete] Deleting directory > > /usr/share/jboss-as/standalone/deployments/engine.ear > > [INFO] Executed tasks > > [INFO] > > [INFO] --- maven-ear-plugin:2.8:generate-application-xml > > (default-generate-application-xml) @ engine-server-ear --- > > [INFO] Generating application.xml > > [INFO] > > [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ > > engine-server-ear --- > > [INFO] Using 'UTF-8' encoding to copy filtered resources. > > [INFO] skip non existing resourceDirectory > > /home/liqiang/ovirt-engine/ear/src/main/java > > [INFO] Copying 1 resource > > [INFO] > > [INFO] --- maven-ear-plugin:2.8:ear (default-ear) @ engine-server-ear --- > > [INFO] Copying artifact [war:org.ovirt.engine.core:root-war:3.3.0-SNAPSHOT] > > to [root.war] (unpacked) > > [INFO] Copying artifact > > [war:org.ovirt.engine.api:restapi-webapp:3.3.0-SNAPSHOT] to [restapi.war] > > (unpacked) > > [INFO] Copying artifact [war:org.ovirt.engine.ui:userportal:3.3.0-SNAPSHOT] > > to [userportal.war] (unpacked) > > [INFO] Copying artifact [war:org.ovirt.engine.ui:webadmin:3.3.0-SNAPSHOT] > > to > > [webadmin.war] (unpacked) > > [INFO] Copying artifact > > [ejb:org.ovirt.engine.core:scheduler:3.3.0-SNAPSHOT] > > to [scheduler.jar] > > [INFO] Copying artifact [ejb:org.ovirt.engine.core:bll:3.3.0-SNAPSHOT] to > > [bll.jar] > > [INFO] Copying artifact > > [jar:org.ovirt.engine.core:vdsbroker:3.3.0-SNAPSHOT] > > to [lib/vdsbroker.jar] > > [INFO] Copying artifact [jar:org.ovirt.engine.core:compat:3.3.0-SNAPSHOT] > > to > > [lib/compat.jar] > > [INFO] Copying artifact [jar:org.ovirt.engine.core:common:3.3.0-SNAPSHOT] > > to > > [lib/common.jar] > > [INFO] Copying artifact [jar:org.hibernate:hibernate-validator: 4.0.2.GA ] > > to > > [lib/hibernate-validator.jar] > > [INFO] Copying artifact [jar:javax.validation:validation-api: 1.0.0.GA ] to > > [lib/validation-api.jar] > > [INFO] Copying artifact [jar:javax.xml.bind:jaxb-api:2.1] to > > [lib/jaxb-api.jar] > > [INFO] Copying artifact [jar:javax.xml.stream:stax-api:1.0-2] to > > [lib/stax-api.jar] > > [INFO] Copying artifact [jar:com.sun.xml.bind:jaxb-impl:2.1.3] to > > [lib/jaxb-impl.jar] > > [INFO] Copying artifact [jar:org.ovirt.engine.core:utils:3.3.0-SNAPSHOT] to > > [lib/utils.jar] > > [INFO] Copying artifact [jar:commons-beanutils:commons-beanutils:1.8.2] to > > [lib/commons-beanutils.jar] > > [INFO] Copying artifact [jar:org.apache.mina:mina-core:2.0.1] to > > [lib/mina-core.jar] > > [INFO] Copying artifact [jar:org.apache.sshd:sshd-core:0.7.0] to > > [lib/sshd-core.jar] > > [INFO] Copying artifact [jar:org.ovirt.otopi:otopi:1.0.0] to > > [lib/otopi.jar] > > [INFO] Copying artifact > > [jar:org.ovirt.ovirt-host-deploy:ovirt-host-deploy:1.0.0] to > > [lib/ovirt-host-deploy.jar] > > [INFO] Copying artifact [jar:org.apache.commons:commons-compress:1.4.1] to > > [lib/commons-compress.jar] > > [INFO] Copying artifact [jar:org.tukaani:xz:1.0] to [lib/xz.jar] > > [INFO] Copying artifact [jar:commons-lang:commons-lang:2.6] to > > [lib/commons-lang.jar] > > [INFO] Copying artifact [jar:commons-codec:commons-codec:1.4] to > > [lib/commons-codec.jar] > > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] to > > [lib/xmlrpc-client.jar] > > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] to > > [lib/xmlrpc-common.jar] > > [INFO] Copying artifact > > [jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to > > [lib/ws-commons-util.jar] > > [INFO] Copying artifact [jar:xml-apis:xml-apis:1.0.b2] to > > [lib/xml-apis.jar] > > [INFO] Copying artifact [jar:org.ovirt.engine.core:dal:3.3.0-SNAPSHOT] to > > [lib/dal.jar] > > [INFO] Copying artifact [jar:org.springframework:spring-jdbc:3.1.1.RELEASE] > > to [lib/spring-jdbc.jar] > > [INFO] Copying artifact [jar:org.springframework:spring-tx:3.1.1.RELEASE] > > to > > [lib/spring-tx.jar] > > [INFO] Copying artifact > > [jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to > > [lib/spring-ldap-core.jar] > > [INFO] Copying artifact [jar:commons-httpclient:commons-httpclient:3.1] to > > [lib/commons-httpclient.jar] > > [INFO] Copying artifact [jar:commons-collections:commons-collections:3.1] > > to > > [lib/commons-collections.jar] > > [INFO] Copying artifact [jar:org.quartz-scheduler:quartz:2.1.2] to > > [lib/quartz.jar] > > [INFO] Copying artifact [jar:c3p0:c3p0:0.9.1.1] to [lib/c3p0.jar] > > [INFO] Copying artifact [jar:org.slf4j:slf4j-api:1.6.1] to > > [lib/slf4j-api.jar] > > [INFO] Copying artifact > > [jar:org.ovirt.engine.core:searchbackend:3.3.0-SNAPSHOT] to > > [lib/searchbackend.jar] > > [INFO] Copying artifact > > [jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] > > to [lib/jboss-interceptors-api_1.1_spec.jar] > > [INFO] Copying artifact [jar:org.springframework:spring-core:3.1.1.RELEASE] > > to [lib/spring-core.jar] > > [INFO] Copying artifact [jar:org.springframework:spring-asm:3.1.1.RELEASE] > > to > > [lib/spring-asm.jar] > > [INFO] Copying artifact > > [jar:org.springframework:spring-beans:3.1.1.RELEASE] > > to [lib/spring-beans.jar] > > [INFO] Copying artifact > > [jar:org.springframework:spring-context:3.1.1.RELEASE] to > > [lib/spring-context.jar] > > [INFO] Copying artifact [jar:org.springframework:spring-aop:3.1.1.RELEASE] > > to > > [lib/spring-aop.jar] > > [INFO] Copying artifact [jar:aopalliance:aopalliance:1.0] to > > [lib/aopalliance.jar] > > [INFO] Copying artifact > > [jar:org.springframework:spring-expression:3.1.1.RELEASE] to > > [lib/spring-expression.jar] > > [INFO] Copy ear sources to /home/liqiang/ovirt-engine/ear/target/engine > > [INFO] Could not find manifest file: > > /home/liqiang/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF - > > Generating one > > [INFO] Building jar: /home/liqiang/ovirt-engine/ear/target/engine.ear > > [INFO] > > [INFO] --- maven-dependency-plugin:2.1:unpack (deploy-modules) @ > > engine-server-ear --- > > [INFO] Configured Artifact: > > org.ovirt.engine.core:dependencies:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:common:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:compat:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:dal:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:searchbackend:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:tools:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:utils:modules:3.3.0-SNAPSHOT:zip > > [INFO] Unpacking > > /home/liqiang/.m2/repository/org/ovirt/engine/core/dependencies/3.3.0-SNAPSHOT/dependencies-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [WARNING] Unable to expand to file > > /usr/share/jboss-as/modules/org/apache/commons/configuration/main/module.xml > > [WARNING] Unable to expand to file > > /usr/share/java/apache-commons-configuration.jar > > [INFO] Unpacking > > /home/liqiang/.m2/repository/org/ovirt/engine/core/common/3.3.0-SNAPSHOT/common-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] Unpacking > > /home/liqiang/.m2/repository/org/ovirt/engine/core/compat/3.3.0-SNAPSHOT/compat-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] Unpacking > > /home/liqiang/.m2/repository/org/ovirt/engine/core/dal/3.3.0-SNAPSHOT/dal-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] Unpacking > > /home/liqiang/.m2/repository/org/ovirt/engine/core/searchbackend/3.3.0-SNAPSHOT/searchbackend-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] Unpacking > > /home/liqiang/.m2/repository/org/ovirt/engine/core/tools/3.3.0-SNAPSHOT/tools-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] Unpacking > > /home/liqiang/.m2/repository/org/ovirt/engine/core/utils/3.3.0-SNAPSHOT/utils-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] > > [INFO] --- maven-antrun-plugin:1.7:run (deploy-ear) @ engine-server-ear --- > > [WARNING] Parameter tasks is deprecated, use target instead > > [INFO] Executing tasks > > > > main: > > [echo] *** Copying updated files to > > /usr/share/jboss-as/standalone/deployments/engine.ear/... > > [unjar] Expanding: /home/liqiang/ovirt-engine/ear/target/engine.ear into > > /usr/share/jboss-as/standalone/deployments/engine.ear > > [echo] *** Touching > > /usr/share/jboss-as/standalone/deployments/engine.ear/META-INF/application.xml > > to force redeployment of engine.ear... > > [echo] *** Touching engine.ear.dodeploy to force deployment of > > engine.ear... > > [INFO] Executed tasks > > [INFO] > > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ > > engine-server-ear --- > > [INFO] Installing /home/liqiang/ovirt-engine/ear/target/engine.ear to > > /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear > > [INFO] Installing /home/liqiang/ovirt-engine/ear/pom.xml to > > /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] BUILD SUCCESS > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] Total time: 54.354s > > [INFO] Finished at: Fri Apr 19 10:48:39 EDT 2013 > > [INFO] Final Memory: 14M/191M > > [INFO] > > ------------------------------------------------------------------------ > > ++++++++++++++++++++++ > > > > > > engine-upgrade > > COMMAND MESSAGE: > > ------------------------------------ > > [root at engine ~]# engine-upgrade > > > > Checking for updates... (This may take several minutes)...[ DONE ] > > 8 Updates available: > > * ovirt-engine-3.2.1-1.fc18.noarch > > * ovirt-engine-tools-3.2.1-1.fc18.noarch > > * ovirt-engine-backend-3.2.1-1.fc18.noarch > > * ovirt-engine-dbscripts-3.2.1-1.fc18.noarch > > * ovirt-engine-genericapi-3.2.1-1.fc18.noarch > > * ovirt-engine-restapi-3.2.1-1.fc18.noarch > > * ovirt-engine-userportal-3.2.1-1.fc18.noarch > > * ovirt-engine-webadmin-portal-3.2.1-1.fc18.noarch > > > > During the upgrade process, oVirt Engine will not be accessible. > > All existing running virtual machines will continue but you will not be > > able > > to > > start or stop any new virtual machines during the process. > > > > Would you like to proceed? (yes|no): yes > > Stopping ovirt-engine service... [ DONE ] > > Stopping DB related services... [ DONE ] > > Pre-upgrade validations... [ DONE ] > > Backing Up Database... [ DONE ] > > Rename Database... [ DONE ] > > Updating rpms... [ DONE ] > > Updating Database... [ DONE ] > > Restore Database name... [ DONE ] > > Preparing CA... [ DONE ] > > Running post install configuration... [ DONE ] > > Starting ovirt-engine service... [ DONE ] > > > > oVirt Engine upgrade completed successfully! > > > > * Upgrade log available at > > /var/log/ovirt-engine/ovirt-engine-upgrade_2013_04_19_10_39_54.log > > * DB Backup available at > > /var/lib/ovirt-engine/backups/ovirt-engine_db_backup_2013_04_19_10_39_54.sql > > ------------------------------------ > > > > > > > > _______________________________________________ > > 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 liqiang.net at gmail.com Sat Apr 20 00:59:23 2013 From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=) Date: Sat, 20 Apr 2013 08:59:23 +0800 Subject: [Engine-devel] Why deploy failed? Please help me, thanks. In-Reply-To: <2076251227.1825669.1366397383543.JavaMail.root@redhat.com> References: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> <768646248.3461998.1366397184625.JavaMail.root@redhat.com> <2076251227.1825669.1366397383543.JavaMail.root@redhat.com> Message-ID: HI:all The first THANKS to all, I rpmbuild and create this files: [root at engine noarch]# ls ovirt-engine-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-backend-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-dbscripts-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-restapi-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-setup-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-setup-plugin-allinone-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-tools-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-userportal-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm ovirt-engine-webadmin-portal-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm AND I COMMAND: ++++++++++++++ rpm -Uvh *.rpm ++++++++++++++ That command is OK? Sorry, I have not used rpm command for a long time. If that rpm's command is ok, What should I do next? HI?All ????? --- ??????????? ?? ------------------------------------------------------------------------------ + ????????????????(????1:1) + ------------------------------------------------------------------------------ 2013/4/20 Alon Bar-Lev > > > ----- Original Message ----- > > From: "Vojtech Szocs" > > To: "Alon Bar-Lev" > > Cc: "??" , engine-devel at ovirt.org > > Sent: Friday, April 19, 2013 9:46:24 PM > > Subject: Re: [Engine-devel] Why deploy failed? Please help me, thanks. > > > > Hi, > > > > > COMPILE COMMAND > > > mvn clean install -Pdep,gwt-admin,gwt-user,all-langs > > > > > Change language is failed and is still englist. > > > Other language is invalid. > > > > Using "all-langs" profile means compiling GUI for all supported languages > > (including Chinese). > > > > Alternatively, to speed up GWT compilation, you can compile only for > English > > and Chinese: > > > > $ mvn clean install -Pdep,gwt-admin,gwt-user -Dgwt.locale=en_US,zh_CN > > > > If the Maven build succeeds but Chinese language still doesn't work in > GUI, > > there's something wrong with deployment of Engine EAR to JBoss ("dep" > > profile). > > > > As Alon suggests, please try building Engine RPMs via "make", but IIRC > you > > have to edit Makefile to specify Chinese language support: > > > > EXTRA_BUILD_FLAGS=-Dgwt.locale=en_US,zh_CN > > rpmbuild --define="EXTRA_BUILD_FLAGS -Dgwt.locale=en_US,zh_CN" -tb > > > > > > Vojtech > > > > > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "??" > > Cc: engine-devel at ovirt.org > > Sent: Friday, April 19, 2013 5:24:46 PM > > Subject: Re: [Engine-devel] Why deploy failed? Please help me, thanks. > > > > Please try setup product without tweaks if you don't have real reason to. > > > > Close the repository, then: > > $ make tarball > > $ rpmbuild -t > > > > Then install the result rpms as usual. > > > > Alternatively, you can try out soon to be merged development > > environment[1][2] > > > > [1] https://github.com/alonbl/ovirt-engine/tree/otopi > > [2] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer > > > > > > ----- Original Message ----- > > > From: "??" > > > To: engine-devel at ovirt.org > > > Sent: Friday, April 19, 2013 6:18:24 PM > > > Subject: [Engine-devel] Why deploy failed? Please help me, thanks. > > > > > > > > > HI?All > > > > > > OS:F18 > > > Ovirt engine version: > > > the first is 3.2.0 > > > update to 3.2.1 > > > and now I compile the source to other language. > > > MEM:8G > > > CPU:I7 > > > DISK:60G > > > > > > > > > I will use chinese language for ovirt engine, > > > but rpm have not chinese language for default install. > > > > > > So I git clone source, that I compile the source success. > > > From link: > > > http://www.ovirt.org/Building_oVirt_engine > > > > > > COMPILE COMMAND > > > mvn clean install -Pdep,gwt-admin,gwt-user,all-langs > > > and show message: > > > ------------------------ > > > > > > ------------------------ > > > > > > I deploy: > > > DEPLOY COMMAND: > > > cd ear && mvn clean install -Pdep > > > > > > QUESTION: > > > 1, > > > I open the first page that it show > > > ------------------ > > > Welcome to Open Virtualization Manager. > > > Version 3.2.1- > > > ------------------ > > > Source shoule be 3.3.0? > > > If souce version 3.3.0,then I deploy is not invalid. > > > > > > 2, > > > Change language is failed and is still englist. > > > Other language is invalid. > > > COMMAND DEPLOY: > > > ++++++++++++++++++++++ > > > [liqiang at engine ear]$ mvn clean install -Pdep > > > [INFO] Scanning for projects... > > > [WARNING] > > > [WARNING] Some problems were encountered while building the effective > model > > > for org.ovirt.engine:engine-server-ear:ear:3.3.0-SNAPSHOT > > > [WARNING] ' distributionManagement.repository.id ' must not be > 'local', > > > this > > > identifier is reserved for the local repository, using it for other > > > repositories will corrupt your repository metadata. @ line 18, column > 11 > > > [WARNING] > > > [WARNING] It is highly recommended to fix these problems because they > > > threaten the stability of your build. > > > [WARNING] > > > [WARNING] For this reason, future Maven versions might no longer > support > > > building such malformed projects. > > > [WARNING] > > > [INFO] > > > [INFO] > > > > ------------------------------------------------------------------------ > > > [INFO] Building oVirt Server EAR 3.3.0-SNAPSHOT > > > [INFO] > > > > ------------------------------------------------------------------------ > > > [INFO] > > > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ > > > engine-server-ear > > > --- > > > [INFO] Deleting /home/liqiang/ovirt-engine/ear/target > > > [INFO] > > > [INFO] --- maven-antrun-plugin:1.7:run (undeploy-ear) @ > engine-server-ear > > > --- > > > [WARNING] Parameter tasks is deprecated, use target instead > > > [INFO] Executing tasks > > > > > > main: > > > [echo] *** Deleting > > > /usr/share/jboss-as/standalone/deployments/engine.ear/... > > > [delete] Deleting directory > > > /usr/share/jboss-as/standalone/deployments/engine.ear > > > [INFO] Executed tasks > > > [INFO] > > > [INFO] --- maven-ear-plugin:2.8:generate-application-xml > > > (default-generate-application-xml) @ engine-server-ear --- > > > [INFO] Generating application.xml > > > [INFO] > > > [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ > > > engine-server-ear --- > > > [INFO] Using 'UTF-8' encoding to copy filtered resources. > > > [INFO] skip non existing resourceDirectory > > > /home/liqiang/ovirt-engine/ear/src/main/java > > > [INFO] Copying 1 resource > > > [INFO] > > > [INFO] --- maven-ear-plugin:2.8:ear (default-ear) @ engine-server-ear > --- > > > [INFO] Copying artifact > [war:org.ovirt.engine.core:root-war:3.3.0-SNAPSHOT] > > > to [root.war] (unpacked) > > > [INFO] Copying artifact > > > [war:org.ovirt.engine.api:restapi-webapp:3.3.0-SNAPSHOT] to > [restapi.war] > > > (unpacked) > > > [INFO] Copying artifact > [war:org.ovirt.engine.ui:userportal:3.3.0-SNAPSHOT] > > > to [userportal.war] (unpacked) > > > [INFO] Copying artifact > [war:org.ovirt.engine.ui:webadmin:3.3.0-SNAPSHOT] > > > to > > > [webadmin.war] (unpacked) > > > [INFO] Copying artifact > > > [ejb:org.ovirt.engine.core:scheduler:3.3.0-SNAPSHOT] > > > to [scheduler.jar] > > > [INFO] Copying artifact [ejb:org.ovirt.engine.core:bll:3.3.0-SNAPSHOT] > to > > > [bll.jar] > > > [INFO] Copying artifact > > > [jar:org.ovirt.engine.core:vdsbroker:3.3.0-SNAPSHOT] > > > to [lib/vdsbroker.jar] > > > [INFO] Copying artifact > [jar:org.ovirt.engine.core:compat:3.3.0-SNAPSHOT] > > > to > > > [lib/compat.jar] > > > [INFO] Copying artifact > [jar:org.ovirt.engine.core:common:3.3.0-SNAPSHOT] > > > to > > > [lib/common.jar] > > > [INFO] Copying artifact [jar:org.hibernate:hibernate-validator: > 4.0.2.GA ] > > > to > > > [lib/hibernate-validator.jar] > > > [INFO] Copying artifact [jar:javax.validation:validation-api: 1.0.0.GA] to > > > [lib/validation-api.jar] > > > [INFO] Copying artifact [jar:javax.xml.bind:jaxb-api:2.1] to > > > [lib/jaxb-api.jar] > > > [INFO] Copying artifact [jar:javax.xml.stream:stax-api:1.0-2] to > > > [lib/stax-api.jar] > > > [INFO] Copying artifact [jar:com.sun.xml.bind:jaxb-impl:2.1.3] to > > > [lib/jaxb-impl.jar] > > > [INFO] Copying artifact > [jar:org.ovirt.engine.core:utils:3.3.0-SNAPSHOT] to > > > [lib/utils.jar] > > > [INFO] Copying artifact > [jar:commons-beanutils:commons-beanutils:1.8.2] to > > > [lib/commons-beanutils.jar] > > > [INFO] Copying artifact [jar:org.apache.mina:mina-core:2.0.1] to > > > [lib/mina-core.jar] > > > [INFO] Copying artifact [jar:org.apache.sshd:sshd-core:0.7.0] to > > > [lib/sshd-core.jar] > > > [INFO] Copying artifact [jar:org.ovirt.otopi:otopi:1.0.0] to > > > [lib/otopi.jar] > > > [INFO] Copying artifact > > > [jar:org.ovirt.ovirt-host-deploy:ovirt-host-deploy:1.0.0] to > > > [lib/ovirt-host-deploy.jar] > > > [INFO] Copying artifact > [jar:org.apache.commons:commons-compress:1.4.1] to > > > [lib/commons-compress.jar] > > > [INFO] Copying artifact [jar:org.tukaani:xz:1.0] to [lib/xz.jar] > > > [INFO] Copying artifact [jar:commons-lang:commons-lang:2.6] to > > > [lib/commons-lang.jar] > > > [INFO] Copying artifact [jar:commons-codec:commons-codec:1.4] to > > > [lib/commons-codec.jar] > > > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] to > > > [lib/xmlrpc-client.jar] > > > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] to > > > [lib/xmlrpc-common.jar] > > > [INFO] Copying artifact > > > [jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to > > > [lib/ws-commons-util.jar] > > > [INFO] Copying artifact [jar:xml-apis:xml-apis:1.0.b2] to > > > [lib/xml-apis.jar] > > > [INFO] Copying artifact [jar:org.ovirt.engine.core:dal:3.3.0-SNAPSHOT] > to > > > [lib/dal.jar] > > > [INFO] Copying artifact > [jar:org.springframework:spring-jdbc:3.1.1.RELEASE] > > > to [lib/spring-jdbc.jar] > > > [INFO] Copying artifact > [jar:org.springframework:spring-tx:3.1.1.RELEASE] > > > to > > > [lib/spring-tx.jar] > > > [INFO] Copying artifact > > > [jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to > > > [lib/spring-ldap-core.jar] > > > [INFO] Copying artifact > [jar:commons-httpclient:commons-httpclient:3.1] to > > > [lib/commons-httpclient.jar] > > > [INFO] Copying artifact > [jar:commons-collections:commons-collections:3.1] > > > to > > > [lib/commons-collections.jar] > > > [INFO] Copying artifact [jar:org.quartz-scheduler:quartz:2.1.2] to > > > [lib/quartz.jar] > > > [INFO] Copying artifact [jar:c3p0:c3p0:0.9.1.1] to [lib/c3p0.jar] > > > [INFO] Copying artifact [jar:org.slf4j:slf4j-api:1.6.1] to > > > [lib/slf4j-api.jar] > > > [INFO] Copying artifact > > > [jar:org.ovirt.engine.core:searchbackend:3.3.0-SNAPSHOT] to > > > [lib/searchbackend.jar] > > > [INFO] Copying artifact > > > > [jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] > > > to [lib/jboss-interceptors-api_1.1_spec.jar] > > > [INFO] Copying artifact > [jar:org.springframework:spring-core:3.1.1.RELEASE] > > > to [lib/spring-core.jar] > > > [INFO] Copying artifact > [jar:org.springframework:spring-asm:3.1.1.RELEASE] > > > to > > > [lib/spring-asm.jar] > > > [INFO] Copying artifact > > > [jar:org.springframework:spring-beans:3.1.1.RELEASE] > > > to [lib/spring-beans.jar] > > > [INFO] Copying artifact > > > [jar:org.springframework:spring-context:3.1.1.RELEASE] to > > > [lib/spring-context.jar] > > > [INFO] Copying artifact > [jar:org.springframework:spring-aop:3.1.1.RELEASE] > > > to > > > [lib/spring-aop.jar] > > > [INFO] Copying artifact [jar:aopalliance:aopalliance:1.0] to > > > [lib/aopalliance.jar] > > > [INFO] Copying artifact > > > [jar:org.springframework:spring-expression:3.1.1.RELEASE] to > > > [lib/spring-expression.jar] > > > [INFO] Copy ear sources to /home/liqiang/ovirt-engine/ear/target/engine > > > [INFO] Could not find manifest file: > > > /home/liqiang/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF - > > > Generating one > > > [INFO] Building jar: /home/liqiang/ovirt-engine/ear/target/engine.ear > > > [INFO] > > > [INFO] --- maven-dependency-plugin:2.1:unpack (deploy-modules) @ > > > engine-server-ear --- > > > [INFO] Configured Artifact: > > > org.ovirt.engine.core:dependencies:modules:3.3.0-SNAPSHOT:zip > > > [INFO] Configured Artifact: > > > org.ovirt.engine.core:common:modules:3.3.0-SNAPSHOT:zip > > > [INFO] Configured Artifact: > > > org.ovirt.engine.core:compat:modules:3.3.0-SNAPSHOT:zip > > > [INFO] Configured Artifact: > > > org.ovirt.engine.core:dal:modules:3.3.0-SNAPSHOT:zip > > > [INFO] Configured Artifact: > > > org.ovirt.engine.core:searchbackend:modules:3.3.0-SNAPSHOT:zip > > > [INFO] Configured Artifact: > > > org.ovirt.engine.core:tools:modules:3.3.0-SNAPSHOT:zip > > > [INFO] Configured Artifact: > > > org.ovirt.engine.core:utils:modules:3.3.0-SNAPSHOT:zip > > > [INFO] Unpacking > > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/dependencies/3.3.0-SNAPSHOT/dependencies-3.3.0-SNAPSHOT-modules.zip > > > to > > > /usr/share/jboss-as/modules > > > with includes null and excludes:null > > > [WARNING] Unable to expand to file > > > > /usr/share/jboss-as/modules/org/apache/commons/configuration/main/module.xml > > > [WARNING] Unable to expand to file > > > /usr/share/java/apache-commons-configuration.jar > > > [INFO] Unpacking > > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/common/3.3.0-SNAPSHOT/common-3.3.0-SNAPSHOT-modules.zip > > > to > > > /usr/share/jboss-as/modules > > > with includes null and excludes:null > > > [INFO] Unpacking > > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/compat/3.3.0-SNAPSHOT/compat-3.3.0-SNAPSHOT-modules.zip > > > to > > > /usr/share/jboss-as/modules > > > with includes null and excludes:null > > > [INFO] Unpacking > > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/dal/3.3.0-SNAPSHOT/dal-3.3.0-SNAPSHOT-modules.zip > > > to > > > /usr/share/jboss-as/modules > > > with includes null and excludes:null > > > [INFO] Unpacking > > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/searchbackend/3.3.0-SNAPSHOT/searchbackend-3.3.0-SNAPSHOT-modules.zip > > > to > > > /usr/share/jboss-as/modules > > > with includes null and excludes:null > > > [INFO] Unpacking > > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/tools/3.3.0-SNAPSHOT/tools-3.3.0-SNAPSHOT-modules.zip > > > to > > > /usr/share/jboss-as/modules > > > with includes null and excludes:null > > > [INFO] Unpacking > > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/utils/3.3.0-SNAPSHOT/utils-3.3.0-SNAPSHOT-modules.zip > > > to > > > /usr/share/jboss-as/modules > > > with includes null and excludes:null > > > [INFO] > > > [INFO] --- maven-antrun-plugin:1.7:run (deploy-ear) @ > engine-server-ear --- > > > [WARNING] Parameter tasks is deprecated, use target instead > > > [INFO] Executing tasks > > > > > > main: > > > [echo] *** Copying updated files to > > > /usr/share/jboss-as/standalone/deployments/engine.ear/... > > > [unjar] Expanding: /home/liqiang/ovirt-engine/ear/target/engine.ear > into > > > /usr/share/jboss-as/standalone/deployments/engine.ear > > > [echo] *** Touching > > > > /usr/share/jboss-as/standalone/deployments/engine.ear/META-INF/application.xml > > > to force redeployment of engine.ear... > > > [echo] *** Touching engine.ear.dodeploy to force deployment of > > > engine.ear... > > > [INFO] Executed tasks > > > [INFO] > > > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ > > > engine-server-ear --- > > > [INFO] Installing /home/liqiang/ovirt-engine/ear/target/engine.ear to > > > > /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear > > > [INFO] Installing /home/liqiang/ovirt-engine/ear/pom.xml to > > > > /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom > > > [INFO] > > > > ------------------------------------------------------------------------ > > > [INFO] BUILD SUCCESS > > > [INFO] > > > > ------------------------------------------------------------------------ > > > [INFO] Total time: 54.354s > > > [INFO] Finished at: Fri Apr 19 10:48:39 EDT 2013 > > > [INFO] Final Memory: 14M/191M > > > [INFO] > > > > ------------------------------------------------------------------------ > > > ++++++++++++++++++++++ > > > > > > > > > engine-upgrade > > > COMMAND MESSAGE: > > > ------------------------------------ > > > [root at engine ~]# engine-upgrade > > > > > > Checking for updates... (This may take several minutes)...[ DONE ] > > > 8 Updates available: > > > * ovirt-engine-3.2.1-1.fc18.noarch > > > * ovirt-engine-tools-3.2.1-1.fc18.noarch > > > * ovirt-engine-backend-3.2.1-1.fc18.noarch > > > * ovirt-engine-dbscripts-3.2.1-1.fc18.noarch > > > * ovirt-engine-genericapi-3.2.1-1.fc18.noarch > > > * ovirt-engine-restapi-3.2.1-1.fc18.noarch > > > * ovirt-engine-userportal-3.2.1-1.fc18.noarch > > > * ovirt-engine-webadmin-portal-3.2.1-1.fc18.noarch > > > > > > During the upgrade process, oVirt Engine will not be accessible. > > > All existing running virtual machines will continue but you will not be > > > able > > > to > > > start or stop any new virtual machines during the process. > > > > > > Would you like to proceed? (yes|no): yes > > > Stopping ovirt-engine service... [ DONE ] > > > Stopping DB related services... [ DONE ] > > > Pre-upgrade validations... [ DONE ] > > > Backing Up Database... [ DONE ] > > > Rename Database... [ DONE ] > > > Updating rpms... [ DONE ] > > > Updating Database... [ DONE ] > > > Restore Database name... [ DONE ] > > > Preparing CA... [ DONE ] > > > Running post install configuration... [ DONE ] > > > Starting ovirt-engine service... [ DONE ] > > > > > > oVirt Engine upgrade completed successfully! > > > > > > * Upgrade log available at > > > /var/log/ovirt-engine/ovirt-engine-upgrade_2013_04_19_10_39_54.log > > > * DB Backup available at > > > > /var/lib/ovirt-engine/backups/ovirt-engine_db_backup_2013_04_19_10_39_54.sql > > > ------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > 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: From liqiang.net at gmail.com Sat Apr 20 01:11:39 2013 From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=) Date: Sat, 20 Apr 2013 09:11:39 +0800 Subject: [Engine-devel] Why deploy failed? Please help me, thanks. In-Reply-To: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> References: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> Message-ID: HI?Alon Thank your help, The question: 1,Your email "Close the repository", What does it mean? 2,Your email "Alternatively, you can try out soon to be merged development environment[1][2]" Is it stable? Can be used in a production environment? Thanks again your help, HI?All ????? --- ??????????? ?? ------------------------------------------------------------------------------ + ????????????????(????1:1) + ------------------------------------------------------------------------------ 2013/4/19 Alon Bar-Lev > Please try setup product without tweaks if you don't have real reason to. > > Close the repository, then: > $ make tarball > $ rpmbuild -t > > Then install the result rpms as usual. > > Alternatively, you can try out soon to be merged development > environment[1][2] > > [1] https://github.com/alonbl/ovirt-engine/tree/otopi > [2] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer > > > ----- Original Message ----- > > From: "??" > > To: engine-devel at ovirt.org > > Sent: Friday, April 19, 2013 6:18:24 PM > > Subject: [Engine-devel] Why deploy failed? Please help me, thanks. > > > > > > HI?All > > > > OS:F18 > > Ovirt engine version: > > the first is 3.2.0 > > update to 3.2.1 > > and now I compile the source to other language. > > MEM:8G > > CPU:I7 > > DISK:60G > > > > > > I will use chinese language for ovirt engine, > > but rpm have not chinese language for default install. > > > > So I git clone source, that I compile the source success. > > From link: > > http://www.ovirt.org/Building_oVirt_engine > > > > COMPILE COMMAND > > mvn clean install -Pdep,gwt-admin,gwt-user,all-langs > > and show message: > > ------------------------ > > > > ------------------------ > > > > I deploy: > > DEPLOY COMMAND: > > cd ear && mvn clean install -Pdep > > > > QUESTION: > > 1, > > I open the first page that it show > > ------------------ > > Welcome to Open Virtualization Manager. > > Version 3.2.1- > > ------------------ > > Source shoule be 3.3.0? > > If souce version 3.3.0,then I deploy is not invalid. > > > > 2, > > Change language is failed and is still englist. > > Other language is invalid. > > COMMAND DEPLOY: > > ++++++++++++++++++++++ > > [liqiang at engine ear]$ mvn clean install -Pdep > > [INFO] Scanning for projects... > > [WARNING] > > [WARNING] Some problems were encountered while building the effective > model > > for org.ovirt.engine:engine-server-ear:ear:3.3.0-SNAPSHOT > > [WARNING] ' distributionManagement.repository.id ' must not be 'local', > this > > identifier is reserved for the local repository, using it for other > > repositories will corrupt your repository metadata. @ line 18, column 11 > > [WARNING] > > [WARNING] It is highly recommended to fix these problems because they > > threaten the stability of your build. > > [WARNING] > > [WARNING] For this reason, future Maven versions might no longer support > > building such malformed projects. > > [WARNING] > > [INFO] > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] Building oVirt Server EAR 3.3.0-SNAPSHOT > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] > > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ > engine-server-ear > > --- > > [INFO] Deleting /home/liqiang/ovirt-engine/ear/target > > [INFO] > > [INFO] --- maven-antrun-plugin:1.7:run (undeploy-ear) @ > engine-server-ear --- > > [WARNING] Parameter tasks is deprecated, use target instead > > [INFO] Executing tasks > > > > main: > > [echo] *** Deleting > /usr/share/jboss-as/standalone/deployments/engine.ear/... > > [delete] Deleting directory > > /usr/share/jboss-as/standalone/deployments/engine.ear > > [INFO] Executed tasks > > [INFO] > > [INFO] --- maven-ear-plugin:2.8:generate-application-xml > > (default-generate-application-xml) @ engine-server-ear --- > > [INFO] Generating application.xml > > [INFO] > > [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ > > engine-server-ear --- > > [INFO] Using 'UTF-8' encoding to copy filtered resources. > > [INFO] skip non existing resourceDirectory > > /home/liqiang/ovirt-engine/ear/src/main/java > > [INFO] Copying 1 resource > > [INFO] > > [INFO] --- maven-ear-plugin:2.8:ear (default-ear) @ engine-server-ear --- > > [INFO] Copying artifact > [war:org.ovirt.engine.core:root-war:3.3.0-SNAPSHOT] > > to [root.war] (unpacked) > > [INFO] Copying artifact > > [war:org.ovirt.engine.api:restapi-webapp:3.3.0-SNAPSHOT] to [restapi.war] > > (unpacked) > > [INFO] Copying artifact > [war:org.ovirt.engine.ui:userportal:3.3.0-SNAPSHOT] > > to [userportal.war] (unpacked) > > [INFO] Copying artifact > [war:org.ovirt.engine.ui:webadmin:3.3.0-SNAPSHOT] to > > [webadmin.war] (unpacked) > > [INFO] Copying artifact > [ejb:org.ovirt.engine.core:scheduler:3.3.0-SNAPSHOT] > > to [scheduler.jar] > > [INFO] Copying artifact [ejb:org.ovirt.engine.core:bll:3.3.0-SNAPSHOT] to > > [bll.jar] > > [INFO] Copying artifact > [jar:org.ovirt.engine.core:vdsbroker:3.3.0-SNAPSHOT] > > to [lib/vdsbroker.jar] > > [INFO] Copying artifact > [jar:org.ovirt.engine.core:compat:3.3.0-SNAPSHOT] to > > [lib/compat.jar] > > [INFO] Copying artifact > [jar:org.ovirt.engine.core:common:3.3.0-SNAPSHOT] to > > [lib/common.jar] > > [INFO] Copying artifact [jar:org.hibernate:hibernate-validator: 4.0.2.GA] to > > [lib/hibernate-validator.jar] > > [INFO] Copying artifact [jar:javax.validation:validation-api: 1.0.0.GA] to > > [lib/validation-api.jar] > > [INFO] Copying artifact [jar:javax.xml.bind:jaxb-api:2.1] to > > [lib/jaxb-api.jar] > > [INFO] Copying artifact [jar:javax.xml.stream:stax-api:1.0-2] to > > [lib/stax-api.jar] > > [INFO] Copying artifact [jar:com.sun.xml.bind:jaxb-impl:2.1.3] to > > [lib/jaxb-impl.jar] > > [INFO] Copying artifact [jar:org.ovirt.engine.core:utils:3.3.0-SNAPSHOT] > to > > [lib/utils.jar] > > [INFO] Copying artifact [jar:commons-beanutils:commons-beanutils:1.8.2] > to > > [lib/commons-beanutils.jar] > > [INFO] Copying artifact [jar:org.apache.mina:mina-core:2.0.1] to > > [lib/mina-core.jar] > > [INFO] Copying artifact [jar:org.apache.sshd:sshd-core:0.7.0] to > > [lib/sshd-core.jar] > > [INFO] Copying artifact [jar:org.ovirt.otopi:otopi:1.0.0] to > [lib/otopi.jar] > > [INFO] Copying artifact > > [jar:org.ovirt.ovirt-host-deploy:ovirt-host-deploy:1.0.0] to > > [lib/ovirt-host-deploy.jar] > > [INFO] Copying artifact [jar:org.apache.commons:commons-compress:1.4.1] > to > > [lib/commons-compress.jar] > > [INFO] Copying artifact [jar:org.tukaani:xz:1.0] to [lib/xz.jar] > > [INFO] Copying artifact [jar:commons-lang:commons-lang:2.6] to > > [lib/commons-lang.jar] > > [INFO] Copying artifact [jar:commons-codec:commons-codec:1.4] to > > [lib/commons-codec.jar] > > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] to > > [lib/xmlrpc-client.jar] > > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] to > > [lib/xmlrpc-common.jar] > > [INFO] Copying artifact > > [jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to > > [lib/ws-commons-util.jar] > > [INFO] Copying artifact [jar:xml-apis:xml-apis:1.0.b2] to > [lib/xml-apis.jar] > > [INFO] Copying artifact [jar:org.ovirt.engine.core:dal:3.3.0-SNAPSHOT] to > > [lib/dal.jar] > > [INFO] Copying artifact > [jar:org.springframework:spring-jdbc:3.1.1.RELEASE] > > to [lib/spring-jdbc.jar] > > [INFO] Copying artifact > [jar:org.springframework:spring-tx:3.1.1.RELEASE] to > > [lib/spring-tx.jar] > > [INFO] Copying artifact > > [jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to > > [lib/spring-ldap-core.jar] > > [INFO] Copying artifact [jar:commons-httpclient:commons-httpclient:3.1] > to > > [lib/commons-httpclient.jar] > > [INFO] Copying artifact > [jar:commons-collections:commons-collections:3.1] to > > [lib/commons-collections.jar] > > [INFO] Copying artifact [jar:org.quartz-scheduler:quartz:2.1.2] to > > [lib/quartz.jar] > > [INFO] Copying artifact [jar:c3p0:c3p0:0.9.1.1] to [lib/c3p0.jar] > > [INFO] Copying artifact [jar:org.slf4j:slf4j-api:1.6.1] to > > [lib/slf4j-api.jar] > > [INFO] Copying artifact > > [jar:org.ovirt.engine.core:searchbackend:3.3.0-SNAPSHOT] to > > [lib/searchbackend.jar] > > [INFO] Copying artifact > > > [jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] > > to [lib/jboss-interceptors-api_1.1_spec.jar] > > [INFO] Copying artifact > [jar:org.springframework:spring-core:3.1.1.RELEASE] > > to [lib/spring-core.jar] > > [INFO] Copying artifact > [jar:org.springframework:spring-asm:3.1.1.RELEASE] to > > [lib/spring-asm.jar] > > [INFO] Copying artifact > [jar:org.springframework:spring-beans:3.1.1.RELEASE] > > to [lib/spring-beans.jar] > > [INFO] Copying artifact > > [jar:org.springframework:spring-context:3.1.1.RELEASE] to > > [lib/spring-context.jar] > > [INFO] Copying artifact > [jar:org.springframework:spring-aop:3.1.1.RELEASE] to > > [lib/spring-aop.jar] > > [INFO] Copying artifact [jar:aopalliance:aopalliance:1.0] to > > [lib/aopalliance.jar] > > [INFO] Copying artifact > > [jar:org.springframework:spring-expression:3.1.1.RELEASE] to > > [lib/spring-expression.jar] > > [INFO] Copy ear sources to /home/liqiang/ovirt-engine/ear/target/engine > > [INFO] Could not find manifest file: > > /home/liqiang/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF - > > Generating one > > [INFO] Building jar: /home/liqiang/ovirt-engine/ear/target/engine.ear > > [INFO] > > [INFO] --- maven-dependency-plugin:2.1:unpack (deploy-modules) @ > > engine-server-ear --- > > [INFO] Configured Artifact: > > org.ovirt.engine.core:dependencies:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:common:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:compat:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:dal:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:searchbackend:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:tools:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:utils:modules:3.3.0-SNAPSHOT:zip > > [INFO] Unpacking > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/dependencies/3.3.0-SNAPSHOT/dependencies-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [WARNING] Unable to expand to file > > > /usr/share/jboss-as/modules/org/apache/commons/configuration/main/module.xml > > [WARNING] Unable to expand to file > > /usr/share/java/apache-commons-configuration.jar > > [INFO] Unpacking > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/common/3.3.0-SNAPSHOT/common-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] Unpacking > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/compat/3.3.0-SNAPSHOT/compat-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] Unpacking > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/dal/3.3.0-SNAPSHOT/dal-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] Unpacking > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/searchbackend/3.3.0-SNAPSHOT/searchbackend-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] Unpacking > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/tools/3.3.0-SNAPSHOT/tools-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] Unpacking > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/utils/3.3.0-SNAPSHOT/utils-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] > > [INFO] --- maven-antrun-plugin:1.7:run (deploy-ear) @ engine-server-ear > --- > > [WARNING] Parameter tasks is deprecated, use target instead > > [INFO] Executing tasks > > > > main: > > [echo] *** Copying updated files to > > /usr/share/jboss-as/standalone/deployments/engine.ear/... > > [unjar] Expanding: /home/liqiang/ovirt-engine/ear/target/engine.ear into > > /usr/share/jboss-as/standalone/deployments/engine.ear > > [echo] *** Touching > > > /usr/share/jboss-as/standalone/deployments/engine.ear/META-INF/application.xml > > to force redeployment of engine.ear... > > [echo] *** Touching engine.ear.dodeploy to force deployment of > engine.ear... > > [INFO] Executed tasks > > [INFO] > > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ > > engine-server-ear --- > > [INFO] Installing /home/liqiang/ovirt-engine/ear/target/engine.ear to > > > /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear > > [INFO] Installing /home/liqiang/ovirt-engine/ear/pom.xml to > > > /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] BUILD SUCCESS > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] Total time: 54.354s > > [INFO] Finished at: Fri Apr 19 10:48:39 EDT 2013 > > [INFO] Final Memory: 14M/191M > > [INFO] > > ------------------------------------------------------------------------ > > ++++++++++++++++++++++ > > > > > > engine-upgrade > > COMMAND MESSAGE: > > ------------------------------------ > > [root at engine ~]# engine-upgrade > > > > Checking for updates... (This may take several minutes)...[ DONE ] > > 8 Updates available: > > * ovirt-engine-3.2.1-1.fc18.noarch > > * ovirt-engine-tools-3.2.1-1.fc18.noarch > > * ovirt-engine-backend-3.2.1-1.fc18.noarch > > * ovirt-engine-dbscripts-3.2.1-1.fc18.noarch > > * ovirt-engine-genericapi-3.2.1-1.fc18.noarch > > * ovirt-engine-restapi-3.2.1-1.fc18.noarch > > * ovirt-engine-userportal-3.2.1-1.fc18.noarch > > * ovirt-engine-webadmin-portal-3.2.1-1.fc18.noarch > > > > During the upgrade process, oVirt Engine will not be accessible. > > All existing running virtual machines will continue but you will not be > able > > to > > start or stop any new virtual machines during the process. > > > > Would you like to proceed? (yes|no): yes > > Stopping ovirt-engine service... [ DONE ] > > Stopping DB related services... [ DONE ] > > Pre-upgrade validations... [ DONE ] > > Backing Up Database... [ DONE ] > > Rename Database... [ DONE ] > > Updating rpms... [ DONE ] > > Updating Database... [ DONE ] > > Restore Database name... [ DONE ] > > Preparing CA... [ DONE ] > > Running post install configuration... [ DONE ] > > Starting ovirt-engine service... [ DONE ] > > > > oVirt Engine upgrade completed successfully! > > > > * Upgrade log available at > > /var/log/ovirt-engine/ovirt-engine-upgrade_2013_04_19_10_39_54.log > > * DB Backup available at > > > /var/lib/ovirt-engine/backups/ovirt-engine_db_backup_2013_04_19_10_39_54.sql > > ------------------------------------ > > > > > > > > _______________________________________________ > > 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: From liqiang.net at gmail.com Sat Apr 20 02:10:13 2013 From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=) Date: Sat, 20 Apr 2013 10:10:13 +0800 Subject: [Engine-devel] Why deploy failed? Please help me, thanks. In-Reply-To: References: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> Message-ID: I have ERROR and Please help me ,thanks The first Upgrade is SUCCESS. Please look the info. But engine-set is ERROR. AIO: Adding Local Datacenter and cluster... [ ERROR ] Error: could not create ovirtsdk API object Please check log file /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log for more information ========================================================== [root at engine noarch]# rpm -Uvh *.rpm Preparing... ################################# [100%] Updating / installing... 1:ovirt-engine-sdk-3.3.0.1-1.201304################################# [ 3%] 2:ovirt-image-uploader-3.3.0-0.0.ma################################# [ 7%] 3:ovirt-iso-uploader-3.3.0-0.0.mast################################# [ 10%] 4:ovirt-log-collector-3.3.0-0.0.mas################################# [ 14%] 5:ovirt-engine-backend-3.3.0-0.2.ma################################# [ 17%] 6:ovirt-engine-dbscripts-3.3.0-0.2.################################# [ 21%] 7:ovirt-engine-restapi-3.3.0-0.2.ma################################# [ 24%] 8:ovirt-engine-setup-3.3.0-0.2.mastwarning: /etc/firewalld/services/ovirt.xml created as /etc/firewalld/services/ovirt.xml.rpmnew ################################# [ 28%] 9:ovirt-engine-tools-3.3.0-0.2.mast################################# [ 31%] 10:ovirt-engine-userportal-3.3.0-0.2################################# [ 34%] 11:ovirt-engine-webadmin-portal-3.3.################################# [ 38%] 12:ovirt-engine-3.3.0-0.2.master.201################################# [ 41%] 13:ovirt-host-deploy-offline-1.1.0-0################################# [ 45%] 14:ovirt-engine-setup-plugin-allinon################################# [ 48%] Cleaning up / removing... 15:ovirt-engine-backend-3.2.0-4.fc18################################# [ 52%] 16:ovirt-engine-config-3.2.0-4.fc18 ################################# [ 55%] 17:ovirt-engine-dbscripts-3.2.0-4.fc################################# [ 59%] 18:ovirt-engine-genericapi-3.2.0-4.f################################# [ 62%] 19:ovirt-engine-tools-common-3.2.0-4################################# [ 66%] 20:ovirt-engine-notification-service################################# [ 69%] 21:ovirt-engine-restapi-3.2.0-4.fc18################################# [ 72%] 22:ovirt-engine-setup-3.2.0-4.fc18 ################################# [ 76%] 23:ovirt-engine-userportal-3.2.0-4.f################################# [ 79%] 24:ovirt-engine-webadmin-portal-3.2.################################# [ 83%] 25:ovirt-engine-3.2.0-4.fc18 warning: /etc/sysconfig/ovirt-engine saved as /etc/sysconfig/ovirt-engine.rpmsave ################################# [ 86%] 26:ovirt-image-uploader-3.2.0-1.fc18################################# [ 90%] 27:ovirt-iso-uploader-3.2.0-1.fc18 ################################# [ 93%] 28:ovirt-log-collector-3.2.0-1.fc18 ################################# [ 97%] 29:ovirt-engine-sdk-3.2.0.9-1.fc18 ################################# [100%] ========================================================== ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ [root at engine ~]# engine-setup Welcome to oVirt Engine setup utility WARNING: oVirt Engine setup has already been run on this host. To remove all configuration and reset oVirt Engine please run engine-cleanup. Please be advised that executing engine-setup without cleanup is not supported. Would you like to proceed? (yes|no): yes In order to proceed the installer must stop the ovirt-engine service Would you like to stop the ovirt-engine service? (yes|no): yes oVirt Engine uses httpd to proxy requests to the application server. It looks like the httpd installed locally is being actively used. The installer can override current configuration . Alternatively you can use JBoss directly (on ports higher than 1024) Do you wish to override current httpd configuration and restart the service? ['yes'| 'no'] [yes] : HTTP Port [80] : HTTPS Port [443] : Setup can configure server default page to launch oVirt Engine. Do you wish to do so? ['yes'| 'no'] [yes] : Host fully qualified domain name. Note: this name should be fully resolvable [engine.startn.com] : The IP 192.168.11.12 does not hold a PTR record for the FQDN: engine.startn.com User input failed validation, do you still wish to use it? (yes|no): yes Enter a password for an internal oVirt Engine administrator user (admin at internal) : Warning: Weak Password. Confirm password : Organization Name for the Certificate [startn.com] : The engine can be configured to present the UI in three different application modes. virt [Manage virtualization only], gluster [Manage gluster storage only], and both [Manage virtualization as well as gluster storage] ['virt'| 'gluster'| 'both'] [both] : The default storage type you will be using ['NFS'| 'FC'| 'ISCSI'| 'POSIXFS'] [NFS] : Enter DB type for installation ['remote'| 'local'] [local] : Enter a password for a local oVirt Engine DB admin user (engine) : Warning: Weak Password. Confirm password : Local ISO domain path [/var/lib/exports/iso_2013_04_19_21_46_58] : Firewall ports need to be opened. The installer can configure firewall automatically overriding the current configuration. The old configuration will be backed up. Alternately you can configure the firewall later using an example file selecting None. Which firewall manager do you wish to use? ['None'| 'Firewalld'| 'iptables']: None Configure VDSM on this host? ['yes'| 'no'] [yes] : Local storage domain path [/var/lib/images_2013_04_19_21_46_58] : Confirm root password : oVirt Engine will be installed using the following configuration: ================================================================= override-httpd-config: yes http-port: 80 https-port: 443 override-httpd-root: yes host-fqdn: engine.startn.com auth-pass: ******** org-name: startn.com application-mode: both default-dc-type: NFS db-remote-install: local db-local-pass: ******** nfs-mp: /var/lib/exports/iso_2013_04_19_21_46_58 firewall-manager: None config-allinone: yes storage-path: /var/lib/images_2013_04_19_21_46_58 superuser-pass: ******** Proceed with the configuration listed above? (yes|no): yes Installing: AIO: Validating CPU Compatibility... [ DONE ] AIO: Adding firewall rules... [ DONE ] Configuring oVirt Engine... [ DONE ] Configuring JVM... [ DONE ] Creating CA... [ DONE ] Updating ovirt-engine service... [ DONE ] Setting Database Configuration... [ DONE ] Setting Database Security... [ DONE ] Upgrading Database Schema... [ DONE ] Editing oVirt Engine Configuration... [ DONE ] Editing Postgresql Configuration... [ DONE ] Configuring the Default ISO Domain... [ DONE ] Configuring Firewall... [ DONE ] Starting ovirt-engine Service... [ DONE ] Configuring HTTPD... [ DONE ] AIO: Creating storage directory... [ DONE ] AIO: Adding Local Datacenter and cluster... [ ERROR ] Error: could not create ovirtsdk API object Please check log file /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log for more information ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ cat /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 2013-04-19 21:48:39::DEBUG::setup_sequences::59::root:: running _setupVarPrivileges 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command --> 'chown -Rh ovirt:ovirt /var/lib/ovirt-engine/deployments' in working directory '/root' 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 2013-04-19 21:48:39::DEBUG::setup_sequences::59::root:: running _startEngine 2013-04-19 21:48:39::DEBUG::engine-setup::1787::root:: using chkconfig to enable engine to load on system startup. 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command --> '/sbin/chkconfig ovirt-engine on' in working directory '/root' 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = Note: Forwarding request to 'systemctl enable ovirt-engine.service'. 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 2013-04-19 21:48:39::DEBUG::common_utils::1285::root:: stopping ovirt-engine 2013-04-19 21:48:39::DEBUG::common_utils::1322::root:: executing action ovirt-engine on service stop 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command --> '/sbin/service ovirt-engine stop' in working directory '/root' 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = Redirecting to /bin/systemctl stop ovirt-engine.service 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 2013-04-19 21:48:39::DEBUG::common_utils::1275::root:: starting ovirt-engine 2013-04-19 21:48:39::DEBUG::common_utils::1322::root:: executing action ovirt-engine on service start 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command --> '/sbin/service ovirt-engine start' in working directory '/root' 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = Redirecting to /bin/systemctl start ovirt-engine.service 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 2013-04-19 21:48:39::DEBUG::setup_sequences::59::root:: running _configureSelinuxBoolean 2013-04-19 21:48:39::DEBUG::engine-setup::742::root:: Enable httpd_can_network_connect boolean 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command --> '/usr/sbin/semanage boolean --modify --on httpd_can_network_connect' in working directory '/root' 2013-04-19 21:48:52::DEBUG::common_utils::494::root:: output = 2013-04-19 21:48:52::DEBUG::common_utils::495::root:: stderr = 2013-04-19 21:48:52::DEBUG::common_utils::496::root:: retcode = 0 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running _backupOldHttpdConfig 2013-04-19 21:48:52::DEBUG::engine-setup::728::root:: Backup old httpd configuration files 2013-04-19 21:48:52::DEBUG::engine-setup::732::root:: Backing up /etc/httpd/conf/httpd.conf into /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 2013-04-19 21:48:52::DEBUG::common_utils::729::root:: successfully copied file /etc/httpd/conf/httpd.conf to target destination /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 2013-04-19 21:48:52::DEBUG::common_utils::737::root:: setting file /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 uid/gid ownership 2013-04-19 21:48:52::DEBUG::common_utils::740::root:: setting file /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 mode to -1 2013-04-19 21:48:52::DEBUG::engine-setup::737::root:: Backing up /etc/httpd/conf.d/ssl.conf into /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 2013-04-19 21:48:52::DEBUG::common_utils::729::root:: successfully copied file /etc/httpd/conf.d/ssl.conf to target destination /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 2013-04-19 21:48:52::DEBUG::common_utils::737::root:: setting file /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 uid/gid ownership 2013-04-19 21:48:52::DEBUG::common_utils::740::root:: setting file /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 mode to -1 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running _configureHttpdSslKeys 2013-04-19 21:48:52::DEBUG::engine-setup::754::root:: Update /etc/httpd/conf.d/ssl.conf to use engine private key in mod_ssl directives 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running _configureHttpdPort 2013-04-19 21:48:52::DEBUG::engine-setup::786::root:: Update /etc/httpd/conf/httpd.conf to listen in the new HTTP port 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running _configureHttpdSslPort 2013-04-19 21:48:52::DEBUG::engine-setup::798::root:: Update /etc/httpd/conf.d/ssl.conf to listen in the new HTTPS port 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running _redirectUrl 2013-04-19 21:48:52::DEBUG::common_utils::84::root:: Processing template /usr/share/ovirt-engine/conf/ovirt-engine-proxy.conf.in to /etc/httpd/conf.d/z-ovirt-engine-proxy.conf vars {'@JBOSS_AJP_PORT@': '8702'} 2013-04-19 21:48:52::DEBUG::common_utils::729::root:: successfully copied file /usr/share/ovirt-engine/conf/ovirt-engine-root-redirect.conf.in to target destination /etc/httpd/conf.d/ovirt-engine-root-redirect.conf 2013-04-19 21:48:52::DEBUG::common_utils::737::root:: setting file /etc/httpd/conf.d/ovirt-engine-root-redirect.conf uid/gid ownership 2013-04-19 21:48:52::DEBUG::common_utils::740::root:: setting file /etc/httpd/conf.d/ovirt-engine-root-redirect.conf mode to -1 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running _startHttpd 2013-04-19 21:48:52::DEBUG::engine-setup::1769::root:: Handling the httpd service 2013-04-19 21:48:52::DEBUG::common_utils::456::root:: Executing command --> '/sbin/chkconfig httpd on' in working directory '/root' 2013-04-19 21:48:52::DEBUG::common_utils::494::root:: output = 2013-04-19 21:48:52::DEBUG::common_utils::495::root:: stderr = Note: Forwarding request to 'systemctl enable httpd.service'. 2013-04-19 21:48:52::DEBUG::common_utils::496::root:: retcode = 0 2013-04-19 21:48:52::DEBUG::common_utils::1285::root:: stopping httpd 2013-04-19 21:48:52::DEBUG::common_utils::1322::root:: executing action httpd on service stop 2013-04-19 21:48:52::DEBUG::common_utils::456::root:: Executing command --> '/sbin/service httpd stop' in working directory '/root' 2013-04-19 21:48:52::DEBUG::common_utils::494::root:: output = 2013-04-19 21:48:52::DEBUG::common_utils::495::root:: stderr = Redirecting to /bin/systemctl stop httpd.service 2013-04-19 21:48:52::DEBUG::common_utils::496::root:: retcode = 0 2013-04-19 21:48:52::DEBUG::common_utils::1275::root:: starting httpd 2013-04-19 21:48:52::DEBUG::common_utils::1322::root:: executing action httpd on service start 2013-04-19 21:48:52::DEBUG::common_utils::456::root:: Executing command --> '/sbin/service httpd start' in working directory '/root' 2013-04-19 21:48:54::DEBUG::common_utils::494::root:: output = 2013-04-19 21:48:54::DEBUG::common_utils::495::root:: stderr = Redirecting to /bin/systemctl start httpd.service 2013-04-19 21:48:54::DEBUG::common_utils::496::root:: retcode = 0 2013-04-19 21:48:54::DEBUG::setup_sequences::59::root:: running makeStorageDir 2013-04-19 21:48:54::DEBUG::all_in_one_100::374::root:: Creating/Verifying local domain path 2013-04-19 21:48:54::DEBUG::all_in_one_100::377::root:: Creating directory /var/lib/images_2013_04_19_21_46_58 2013-04-19 21:48:54::DEBUG::all_in_one_100::380::root:: Setting selinux context 2013-04-19 21:48:54::DEBUG::nfsutils::119::root:: setting selinux context for /var/lib/images_2013_04_19_21_46_58 2013-04-19 21:48:54::DEBUG::common_utils::456::root:: Executing command --> '/usr/sbin/semanage fcontext -a -t public_content_rw_t /var/lib/images_2013_04_19_21_46_58(/.*)?' in working directory '/root' 2013-04-19 21:48:55::DEBUG::common_utils::494::root:: output = 2013-04-19 21:48:55::DEBUG::common_utils::495::root:: stderr = 2013-04-19 21:48:55::DEBUG::common_utils::496::root:: retcode = 0 2013-04-19 21:48:55::DEBUG::common_utils::456::root:: Executing command --> '/sbin/restorecon -r /var/lib/images_2013_04_19_21_46_58' in working directory '/root' 2013-04-19 21:48:55::DEBUG::common_utils::494::root:: output = 2013-04-19 21:48:55::DEBUG::common_utils::495::root:: stderr = 2013-04-19 21:48:55::DEBUG::common_utils::496::root:: retcode = 0 2013-04-19 21:48:55::DEBUG::setup_sequences::59::root:: running waitForJbossUp 2013-04-19 21:48:55::DEBUG::all_in_one_100::451::root:: Checking JBoss status. 2013-04-19 21:48:55::INFO::all_in_one_100::454::root:: JBoss is up and running. 2013-04-19 21:48:55::DEBUG::setup_sequences::59::root:: running initAPI 2013-04-19 21:48:55::DEBUG::all_in_one_100::240::root:: Initiating the API object 2013-04-19 21:48:56::ERROR::all_in_one_100::251::root:: Traceback (most recent call last): File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line 248, in initAPI ca_file=basedefs.FILE_CA_CRT_SRC, File "/usr/lib/python2.7/site-packages/ovirtsdk/api.py", line 119, in __init__ url='/api' File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line 112, in request persistent_auth=self._persistent_auth) File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line 134, in __doRequest persistent_auth=persistent_auth File "/usr/lib/python2.7/site-packages/ovirtsdk/web/connection.py", line 133, in doRequest raise RequestError, response RequestError: status: 401 reason: Unauthorized detail: HTTP Status 401 2013-04-19 21:48:56::DEBUG::setup_sequences::62::root:: Traceback (most recent call last): File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, in run function() File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line 252, in initAPI raise Exception(ERROR_CREATE_API_OBJECT) Exception: Error: could not create ovirtsdk API object 2013-04-19 21:48:56::DEBUG::engine-setup::2064::root:: *** The following params were used as user input: 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: override-httpd-config: yes 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: http-port: 80 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: https-port: 443 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: override-httpd-root: yes 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: random-passwords: no 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: mac-range: 00:1A:4A:A8:C3:00-00:1A:4A:A8:C3:FF 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: host-fqdn: engine.startn.com 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: auth-pass: ******** 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: org-name: startn.com 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: application-mode: both 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: default-dc-type: NFS 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: db-remote-install: local 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: db-host: localhost 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: db-local-pass: ******** 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: nfs-mp: /var/lib/exports/iso_2013_04_19_21_46_58 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: iso-domain-name: ISO_DOMAIN 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: config-nfs: yes 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: firewall-manager: None 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: config-allinone: yes 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: storage-path: /var/lib/images_2013_04_19_21_46_58 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: superuser-pass: ******** 2013-04-19 21:48:56::ERROR::engine-setup::2504::root:: Traceback (most recent call last): File "/usr/bin/engine-setup", line 2498, in main(confFile) File "/usr/bin/engine-setup", line 2265, in main runSequences() File "/usr/bin/engine-setup", line 2184, in runSequences controller.runAllSequences() File "/usr/share/ovirt-engine/scripts/setup_controller.py", line 54, in runAllSequences sequence.run() File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 154, in run step.run() File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, in run function() File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line 252, in initAPI raise Exception(ERROR_CREATE_API_OBJECT) Exception: Error: could not create ovirtsdk API object ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ HI?All ????? --- ??????????? ?? ------------------------------------------------------------------------------ + ????????????????(????1:1) + ------------------------------------------------------------------------------ 2013/4/20 ?? > HI?Alon > > Thank your help, > > The question: > 1,Your email "Close the repository", What does it mean? > > 2,Your email "Alternatively, you can try out soon to be merged > development environment[1][2]" > Is it stable? > Can be used in a production environment? > > Thanks again your help, > > > HI?All > > ????? > > --- > ??????????? > ?? > > ------------------------------------------------------------------------------ > > > + ????????????????(????1:1) + > > ------------------------------------------------------------------------------ > > > 2013/4/19 Alon Bar-Lev > >> Please try setup product without tweaks if you don't have real reason to. >> >> Close the repository, then: >> $ make tarball >> $ rpmbuild -t >> >> Then install the result rpms as usual. >> >> Alternatively, you can try out soon to be merged development >> environment[1][2] >> >> [1] https://github.com/alonbl/ovirt-engine/tree/otopi >> [2] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer >> >> >> ----- Original Message ----- >> > From: "??" >> > To: engine-devel at ovirt.org >> > Sent: Friday, April 19, 2013 6:18:24 PM >> > Subject: [Engine-devel] Why deploy failed? Please help me, thanks. >> > >> > >> > HI?All >> > >> > OS:F18 >> > Ovirt engine version: >> > the first is 3.2.0 >> > update to 3.2.1 >> > and now I compile the source to other language. >> > MEM:8G >> > CPU:I7 >> > DISK:60G >> > >> > >> > I will use chinese language for ovirt engine, >> > but rpm have not chinese language for default install. >> > >> > So I git clone source, that I compile the source success. >> > From link: >> > http://www.ovirt.org/Building_oVirt_engine >> > >> > COMPILE COMMAND >> > mvn clean install -Pdep,gwt-admin,gwt-user,all-langs >> > and show message: >> > ------------------------ >> > >> > ------------------------ >> > >> > I deploy: >> > DEPLOY COMMAND: >> > cd ear && mvn clean install -Pdep >> > >> > QUESTION: >> > 1, >> > I open the first page that it show >> > ------------------ >> > Welcome to Open Virtualization Manager. >> > Version 3.2.1- >> > ------------------ >> > Source shoule be 3.3.0? >> > If souce version 3.3.0,then I deploy is not invalid. >> > >> > 2, >> > Change language is failed and is still englist. >> > Other language is invalid. >> > COMMAND DEPLOY: >> > ++++++++++++++++++++++ >> > [liqiang at engine ear]$ mvn clean install -Pdep >> > [INFO] Scanning for projects... >> > [WARNING] >> > [WARNING] Some problems were encountered while building the effective >> model >> > for org.ovirt.engine:engine-server-ear:ear:3.3.0-SNAPSHOT >> > [WARNING] ' distributionManagement.repository.id ' must not be >> 'local', this >> > identifier is reserved for the local repository, using it for other >> > repositories will corrupt your repository metadata. @ line 18, column 11 >> > [WARNING] >> > [WARNING] It is highly recommended to fix these problems because they >> > threaten the stability of your build. >> > [WARNING] >> > [WARNING] For this reason, future Maven versions might no longer support >> > building such malformed projects. >> > [WARNING] >> > [INFO] >> > [INFO] >> > ------------------------------------------------------------------------ >> > [INFO] Building oVirt Server EAR 3.3.0-SNAPSHOT >> > [INFO] >> > ------------------------------------------------------------------------ >> > [INFO] >> > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ >> engine-server-ear >> > --- >> > [INFO] Deleting /home/liqiang/ovirt-engine/ear/target >> > [INFO] >> > [INFO] --- maven-antrun-plugin:1.7:run (undeploy-ear) @ >> engine-server-ear --- >> > [WARNING] Parameter tasks is deprecated, use target instead >> > [INFO] Executing tasks >> > >> > main: >> > [echo] *** Deleting >> /usr/share/jboss-as/standalone/deployments/engine.ear/... >> > [delete] Deleting directory >> > /usr/share/jboss-as/standalone/deployments/engine.ear >> > [INFO] Executed tasks >> > [INFO] >> > [INFO] --- maven-ear-plugin:2.8:generate-application-xml >> > (default-generate-application-xml) @ engine-server-ear --- >> > [INFO] Generating application.xml >> > [INFO] >> > [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ >> > engine-server-ear --- >> > [INFO] Using 'UTF-8' encoding to copy filtered resources. >> > [INFO] skip non existing resourceDirectory >> > /home/liqiang/ovirt-engine/ear/src/main/java >> > [INFO] Copying 1 resource >> > [INFO] >> > [INFO] --- maven-ear-plugin:2.8:ear (default-ear) @ engine-server-ear >> --- >> > [INFO] Copying artifact >> [war:org.ovirt.engine.core:root-war:3.3.0-SNAPSHOT] >> > to [root.war] (unpacked) >> > [INFO] Copying artifact >> > [war:org.ovirt.engine.api:restapi-webapp:3.3.0-SNAPSHOT] to >> [restapi.war] >> > (unpacked) >> > [INFO] Copying artifact >> [war:org.ovirt.engine.ui:userportal:3.3.0-SNAPSHOT] >> > to [userportal.war] (unpacked) >> > [INFO] Copying artifact >> [war:org.ovirt.engine.ui:webadmin:3.3.0-SNAPSHOT] to >> > [webadmin.war] (unpacked) >> > [INFO] Copying artifact >> [ejb:org.ovirt.engine.core:scheduler:3.3.0-SNAPSHOT] >> > to [scheduler.jar] >> > [INFO] Copying artifact [ejb:org.ovirt.engine.core:bll:3.3.0-SNAPSHOT] >> to >> > [bll.jar] >> > [INFO] Copying artifact >> [jar:org.ovirt.engine.core:vdsbroker:3.3.0-SNAPSHOT] >> > to [lib/vdsbroker.jar] >> > [INFO] Copying artifact >> [jar:org.ovirt.engine.core:compat:3.3.0-SNAPSHOT] to >> > [lib/compat.jar] >> > [INFO] Copying artifact >> [jar:org.ovirt.engine.core:common:3.3.0-SNAPSHOT] to >> > [lib/common.jar] >> > [INFO] Copying artifact [jar:org.hibernate:hibernate-validator: >> 4.0.2.GA ] to >> > [lib/hibernate-validator.jar] >> > [INFO] Copying artifact [jar:javax.validation:validation-api: 1.0.0.GA] to >> > [lib/validation-api.jar] >> > [INFO] Copying artifact [jar:javax.xml.bind:jaxb-api:2.1] to >> > [lib/jaxb-api.jar] >> > [INFO] Copying artifact [jar:javax.xml.stream:stax-api:1.0-2] to >> > [lib/stax-api.jar] >> > [INFO] Copying artifact [jar:com.sun.xml.bind:jaxb-impl:2.1.3] to >> > [lib/jaxb-impl.jar] >> > [INFO] Copying artifact >> [jar:org.ovirt.engine.core:utils:3.3.0-SNAPSHOT] to >> > [lib/utils.jar] >> > [INFO] Copying artifact [jar:commons-beanutils:commons-beanutils:1.8.2] >> to >> > [lib/commons-beanutils.jar] >> > [INFO] Copying artifact [jar:org.apache.mina:mina-core:2.0.1] to >> > [lib/mina-core.jar] >> > [INFO] Copying artifact [jar:org.apache.sshd:sshd-core:0.7.0] to >> > [lib/sshd-core.jar] >> > [INFO] Copying artifact [jar:org.ovirt.otopi:otopi:1.0.0] to >> [lib/otopi.jar] >> > [INFO] Copying artifact >> > [jar:org.ovirt.ovirt-host-deploy:ovirt-host-deploy:1.0.0] to >> > [lib/ovirt-host-deploy.jar] >> > [INFO] Copying artifact [jar:org.apache.commons:commons-compress:1.4.1] >> to >> > [lib/commons-compress.jar] >> > [INFO] Copying artifact [jar:org.tukaani:xz:1.0] to [lib/xz.jar] >> > [INFO] Copying artifact [jar:commons-lang:commons-lang:2.6] to >> > [lib/commons-lang.jar] >> > [INFO] Copying artifact [jar:commons-codec:commons-codec:1.4] to >> > [lib/commons-codec.jar] >> > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] to >> > [lib/xmlrpc-client.jar] >> > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] to >> > [lib/xmlrpc-common.jar] >> > [INFO] Copying artifact >> > [jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to >> > [lib/ws-commons-util.jar] >> > [INFO] Copying artifact [jar:xml-apis:xml-apis:1.0.b2] to >> [lib/xml-apis.jar] >> > [INFO] Copying artifact [jar:org.ovirt.engine.core:dal:3.3.0-SNAPSHOT] >> to >> > [lib/dal.jar] >> > [INFO] Copying artifact >> [jar:org.springframework:spring-jdbc:3.1.1.RELEASE] >> > to [lib/spring-jdbc.jar] >> > [INFO] Copying artifact >> [jar:org.springframework:spring-tx:3.1.1.RELEASE] to >> > [lib/spring-tx.jar] >> > [INFO] Copying artifact >> > [jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to >> > [lib/spring-ldap-core.jar] >> > [INFO] Copying artifact [jar:commons-httpclient:commons-httpclient:3.1] >> to >> > [lib/commons-httpclient.jar] >> > [INFO] Copying artifact >> [jar:commons-collections:commons-collections:3.1] to >> > [lib/commons-collections.jar] >> > [INFO] Copying artifact [jar:org.quartz-scheduler:quartz:2.1.2] to >> > [lib/quartz.jar] >> > [INFO] Copying artifact [jar:c3p0:c3p0:0.9.1.1] to [lib/c3p0.jar] >> > [INFO] Copying artifact [jar:org.slf4j:slf4j-api:1.6.1] to >> > [lib/slf4j-api.jar] >> > [INFO] Copying artifact >> > [jar:org.ovirt.engine.core:searchbackend:3.3.0-SNAPSHOT] to >> > [lib/searchbackend.jar] >> > [INFO] Copying artifact >> > >> [jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] >> > to [lib/jboss-interceptors-api_1.1_spec.jar] >> > [INFO] Copying artifact >> [jar:org.springframework:spring-core:3.1.1.RELEASE] >> > to [lib/spring-core.jar] >> > [INFO] Copying artifact >> [jar:org.springframework:spring-asm:3.1.1.RELEASE] to >> > [lib/spring-asm.jar] >> > [INFO] Copying artifact >> [jar:org.springframework:spring-beans:3.1.1.RELEASE] >> > to [lib/spring-beans.jar] >> > [INFO] Copying artifact >> > [jar:org.springframework:spring-context:3.1.1.RELEASE] to >> > [lib/spring-context.jar] >> > [INFO] Copying artifact >> [jar:org.springframework:spring-aop:3.1.1.RELEASE] to >> > [lib/spring-aop.jar] >> > [INFO] Copying artifact [jar:aopalliance:aopalliance:1.0] to >> > [lib/aopalliance.jar] >> > [INFO] Copying artifact >> > [jar:org.springframework:spring-expression:3.1.1.RELEASE] to >> > [lib/spring-expression.jar] >> > [INFO] Copy ear sources to /home/liqiang/ovirt-engine/ear/target/engine >> > [INFO] Could not find manifest file: >> > /home/liqiang/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF - >> > Generating one >> > [INFO] Building jar: /home/liqiang/ovirt-engine/ear/target/engine.ear >> > [INFO] >> > [INFO] --- maven-dependency-plugin:2.1:unpack (deploy-modules) @ >> > engine-server-ear --- >> > [INFO] Configured Artifact: >> > org.ovirt.engine.core:dependencies:modules:3.3.0-SNAPSHOT:zip >> > [INFO] Configured Artifact: >> > org.ovirt.engine.core:common:modules:3.3.0-SNAPSHOT:zip >> > [INFO] Configured Artifact: >> > org.ovirt.engine.core:compat:modules:3.3.0-SNAPSHOT:zip >> > [INFO] Configured Artifact: >> > org.ovirt.engine.core:dal:modules:3.3.0-SNAPSHOT:zip >> > [INFO] Configured Artifact: >> > org.ovirt.engine.core:searchbackend:modules:3.3.0-SNAPSHOT:zip >> > [INFO] Configured Artifact: >> > org.ovirt.engine.core:tools:modules:3.3.0-SNAPSHOT:zip >> > [INFO] Configured Artifact: >> > org.ovirt.engine.core:utils:modules:3.3.0-SNAPSHOT:zip >> > [INFO] Unpacking >> > >> /home/liqiang/.m2/repository/org/ovirt/engine/core/dependencies/3.3.0-SNAPSHOT/dependencies-3.3.0-SNAPSHOT-modules.zip >> > to >> > /usr/share/jboss-as/modules >> > with includes null and excludes:null >> > [WARNING] Unable to expand to file >> > >> /usr/share/jboss-as/modules/org/apache/commons/configuration/main/module.xml >> > [WARNING] Unable to expand to file >> > /usr/share/java/apache-commons-configuration.jar >> > [INFO] Unpacking >> > >> /home/liqiang/.m2/repository/org/ovirt/engine/core/common/3.3.0-SNAPSHOT/common-3.3.0-SNAPSHOT-modules.zip >> > to >> > /usr/share/jboss-as/modules >> > with includes null and excludes:null >> > [INFO] Unpacking >> > >> /home/liqiang/.m2/repository/org/ovirt/engine/core/compat/3.3.0-SNAPSHOT/compat-3.3.0-SNAPSHOT-modules.zip >> > to >> > /usr/share/jboss-as/modules >> > with includes null and excludes:null >> > [INFO] Unpacking >> > >> /home/liqiang/.m2/repository/org/ovirt/engine/core/dal/3.3.0-SNAPSHOT/dal-3.3.0-SNAPSHOT-modules.zip >> > to >> > /usr/share/jboss-as/modules >> > with includes null and excludes:null >> > [INFO] Unpacking >> > >> /home/liqiang/.m2/repository/org/ovirt/engine/core/searchbackend/3.3.0-SNAPSHOT/searchbackend-3.3.0-SNAPSHOT-modules.zip >> > to >> > /usr/share/jboss-as/modules >> > with includes null and excludes:null >> > [INFO] Unpacking >> > >> /home/liqiang/.m2/repository/org/ovirt/engine/core/tools/3.3.0-SNAPSHOT/tools-3.3.0-SNAPSHOT-modules.zip >> > to >> > /usr/share/jboss-as/modules >> > with includes null and excludes:null >> > [INFO] Unpacking >> > >> /home/liqiang/.m2/repository/org/ovirt/engine/core/utils/3.3.0-SNAPSHOT/utils-3.3.0-SNAPSHOT-modules.zip >> > to >> > /usr/share/jboss-as/modules >> > with includes null and excludes:null >> > [INFO] >> > [INFO] --- maven-antrun-plugin:1.7:run (deploy-ear) @ engine-server-ear >> --- >> > [WARNING] Parameter tasks is deprecated, use target instead >> > [INFO] Executing tasks >> > >> > main: >> > [echo] *** Copying updated files to >> > /usr/share/jboss-as/standalone/deployments/engine.ear/... >> > [unjar] Expanding: /home/liqiang/ovirt-engine/ear/target/engine.ear into >> > /usr/share/jboss-as/standalone/deployments/engine.ear >> > [echo] *** Touching >> > >> /usr/share/jboss-as/standalone/deployments/engine.ear/META-INF/application.xml >> > to force redeployment of engine.ear... >> > [echo] *** Touching engine.ear.dodeploy to force deployment of >> engine.ear... >> > [INFO] Executed tasks >> > [INFO] >> > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ >> > engine-server-ear --- >> > [INFO] Installing /home/liqiang/ovirt-engine/ear/target/engine.ear to >> > >> /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear >> > [INFO] Installing /home/liqiang/ovirt-engine/ear/pom.xml to >> > >> /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom >> > [INFO] >> > ------------------------------------------------------------------------ >> > [INFO] BUILD SUCCESS >> > [INFO] >> > ------------------------------------------------------------------------ >> > [INFO] Total time: 54.354s >> > [INFO] Finished at: Fri Apr 19 10:48:39 EDT 2013 >> > [INFO] Final Memory: 14M/191M >> > [INFO] >> > ------------------------------------------------------------------------ >> > ++++++++++++++++++++++ >> > >> > >> > engine-upgrade >> > COMMAND MESSAGE: >> > ------------------------------------ >> > [root at engine ~]# engine-upgrade >> > >> > Checking for updates... (This may take several minutes)...[ DONE ] >> > 8 Updates available: >> > * ovirt-engine-3.2.1-1.fc18.noarch >> > * ovirt-engine-tools-3.2.1-1.fc18.noarch >> > * ovirt-engine-backend-3.2.1-1.fc18.noarch >> > * ovirt-engine-dbscripts-3.2.1-1.fc18.noarch >> > * ovirt-engine-genericapi-3.2.1-1.fc18.noarch >> > * ovirt-engine-restapi-3.2.1-1.fc18.noarch >> > * ovirt-engine-userportal-3.2.1-1.fc18.noarch >> > * ovirt-engine-webadmin-portal-3.2.1-1.fc18.noarch >> > >> > During the upgrade process, oVirt Engine will not be accessible. >> > All existing running virtual machines will continue but you will not be >> able >> > to >> > start or stop any new virtual machines during the process. >> > >> > Would you like to proceed? (yes|no): yes >> > Stopping ovirt-engine service... [ DONE ] >> > Stopping DB related services... [ DONE ] >> > Pre-upgrade validations... [ DONE ] >> > Backing Up Database... [ DONE ] >> > Rename Database... [ DONE ] >> > Updating rpms... [ DONE ] >> > Updating Database... [ DONE ] >> > Restore Database name... [ DONE ] >> > Preparing CA... [ DONE ] >> > Running post install configuration... [ DONE ] >> > Starting ovirt-engine service... [ DONE ] >> > >> > oVirt Engine upgrade completed successfully! >> > >> > * Upgrade log available at >> > /var/log/ovirt-engine/ovirt-engine-upgrade_2013_04_19_10_39_54.log >> > * DB Backup available at >> > >> /var/lib/ovirt-engine/backups/ovirt-engine_db_backup_2013_04_19_10_39_54.sql >> > ------------------------------------ >> > >> > >> > >> > _______________________________________________ >> > 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: From liqiang.net at gmail.com Sat Apr 20 02:36:27 2013 From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=) Date: Sat, 20 Apr 2013 10:36:27 +0800 Subject: [Engine-devel] Why deploy failed? Please help me, thanks. In-Reply-To: References: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> Message-ID: My process: ps -ax ========================== [root at engine ~]# ps -ax PID TTY STAT TIME COMMAND 1 ? Ss 0:03 /usr/lib/systemd/systemd --system --deserialize 20 2 ? S 0:00 [kthreadd] 3 ? S 0:00 [ksoftirqd/0] 5 ? S< 0:00 [kworker/0:0H] 6 ? S 0:00 [kworker/u:0] 7 ? S< 0:00 [kworker/u:0H] 8 ? S 0:02 [migration/0] 9 ? S 0:00 [rcu_bh] 10 ? S 0:01 [rcu_sched] 11 ? S 0:00 [watchdog/0] 12 ? S 0:00 [watchdog/1] 13 ? S 0:00 [ksoftirqd/1] 14 ? S 0:01 [migration/1] 15 ? S 0:00 [kworker/1:0] 16 ? S< 0:00 [kworker/1:0H] 17 ? S 0:00 [watchdog/2] 18 ? S 0:00 [ksoftirqd/2] 19 ? S 0:04 [migration/2] 21 ? S< 0:00 [kworker/2:0H] 22 ? S 0:00 [watchdog/3] 23 ? S 0:00 [ksoftirqd/3] 24 ? S 0:02 [migration/3] 26 ? S< 0:00 [kworker/3:0H] 27 ? S< 0:00 [cpuset] 28 ? S< 0:00 [khelper] 29 ? S 0:00 [kdevtmpfs] 30 ? S< 0:00 [netns] 31 ? S 0:00 [bdi-default] 32 ? S< 0:00 [kintegrityd] 33 ? S< 0:00 [kblockd] 34 ? S< 0:00 [ata_sff] 35 ? S 0:00 [khubd] 36 ? S< 0:00 [md] 44 ? S 0:01 [kworker/u:1] 62 ? S 0:00 [kswapd0] 63 ? SN 0:00 [ksmd] 64 ? SN 0:00 [khugepaged] 65 ? S 0:00 [fsnotify_mark] 66 ? S< 0:00 [crypto] 74 ? S< 0:00 [kthrotld] 77 ? S 0:00 [scsi_eh_0] 78 ? S 0:00 [scsi_eh_1] 80 ? S< 0:00 [kpsmoused] 81 ? S 0:00 [kworker/0:2] 82 ? S 0:00 [kworker/2:1] 83 ? S< 0:00 [deferwq] 97 ? S 0:00 [kauditd] 180 ? S< 0:00 [mpt_poll_0] 181 ? S< 0:00 [mpt/0] 189 ? S 0:00 [scsi_eh_2] 190 ? S< 0:00 [ttm_swap] 192 ? S< 0:01 [kworker/1:1H] 197 ? S 0:00 [kworker/1:2] 199 ? S< 0:01 [kworker/3:1H] 200 ? S 0:08 [kworker/3:2] 234 ? S< 0:01 [kworker/2:1H] 237 ? S< 0:00 [kdmflush] 239 ? S< 0:00 [kdmflush] 266 ? S< 0:00 [kworker/0:1H] 286 ? S 0:02 [jbd2/dm-1-8] 287 ? S< 0:00 [ext4-dio-unwrit] 330 ? Ss 0:00 /usr/lib/systemd/systemd-udevd 333 ? Ss 0:00 /usr/lib/systemd/systemd-journald 334 ? S 0:03 [flush-253:1] 368 ? S< 0:00 [rpciod] 569 ? S 0:00 [jbd2/sda1-8] 570 ? S< 0:00 [ext4-dio-unwrit] 580 ? S< 0:00 [kmpathd] 581 ? S< 0:00 [kmpath_handlerd] 586 ? S< 0:00 [kdmflush] 605 ? S 0:00 [jbd2/dm-2-8] 606 ? S< 0:00 [ext4-dio-unwrit] 641 ? SLl 0:00 /sbin/multipathd 642 ? Ss 0:00 /sbin/iprinit --daemon 643 ? Ss 0:00 /sbin/iprupdate --daemon 664 ? Ss 0:00 /usr/lib/systemd/systemd-logind 666 ? Ssl 0:00 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation 682 tty1 Ss+ 0:00 /sbin/agetty --noclear tty1 38400 linux 687 ? S< 0:00 [iscsi_eh] 689 ? S< 0:00 [ib_mcast] 690 ? S< 0:00 [ib_cm] 691 ? S< 0:00 [iw_cm_wq] 692 ? S< 0:00 [ib_addr] 693 ? S< 0:00 [rdma_cm] 695 ? Ss 0:00 /sbin/iprdump --daemon 701 ? Ss 0:00 /usr/sbin/ntpd -u ntp:ntp -g 703 ? S 0:00 /bin/bash /usr/sbin/ksmtuned 709 ? S< 0:00 [cxgb4] 712 ? S< 0:00 [cnic_wq] 713 ? S< 0:00 [bnx2i_thread/0] 714 ? S< 0:00 [bnx2i_thread/1] 715 ? S< 0:00 [bnx2i_thread/2] 716 ? S< 0:00 [bnx2i_thread/3] 730 ? Ssl 0:00 iscsiuio 739 ? Ss 0:00 iscsid 740 ? S > I have ERROR and Please help me ,thanks > > The first Upgrade is SUCCESS. > Please look the info. > > But engine-set is ERROR. > AIO: Adding Local Datacenter and cluster... [ ERROR ] > Error: could not create ovirtsdk API object > Please check log file > /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log for more > information > > > ========================================================== > [root at engine noarch]# rpm -Uvh *.rpm > Preparing... ################################# > [100%] > Updating / installing... > 1:ovirt-engine-sdk-3.3.0.1-1.201304################################# [ > 3%] > 2:ovirt-image-uploader-3.3.0-0.0.ma#################################[ 7%] > 3:ovirt-iso-uploader-3.3.0-0.0.mast################################# [ > 10%] > 4:ovirt-log-collector-3.3.0-0.0.mas################################# [ > 14%] > 5:ovirt-engine-backend-3.3.0-0.2.ma#################################[ 17%] > 6:ovirt-engine-dbscripts-3.3.0-0.2.################################# [ > 21%] > 7:ovirt-engine-restapi-3.3.0-0.2.ma#################################[ 24%] > 8:ovirt-engine-setup-3.3.0-0.2.mastwarning: > /etc/firewalld/services/ovirt.xml created as > /etc/firewalld/services/ovirt.xml.rpmnew > ################################# [ 28%] > 9:ovirt-engine-tools-3.3.0-0.2.mast################################# [ > 31%] > 10:ovirt-engine-userportal-3.3.0-0.2################################# [ > 34%] > 11:ovirt-engine-webadmin-portal-3.3.################################# [ > 38%] > 12:ovirt-engine-3.3.0-0.2.master.201################################# [ > 41%] > 13:ovirt-host-deploy-offline-1.1.0-0################################# [ > 45%] > 14:ovirt-engine-setup-plugin-allinon################################# [ > 48%] > Cleaning up / removing... > 15:ovirt-engine-backend-3.2.0-4.fc18################################# [ > 52%] > 16:ovirt-engine-config-3.2.0-4.fc18 ################################# [ > 55%] > 17:ovirt-engine-dbscripts-3.2.0-4.fc################################# [ > 59%] > 18:ovirt-engine-genericapi-3.2.0-4.f################################# [ > 62%] > 19:ovirt-engine-tools-common-3.2.0-4################################# [ > 66%] > 20:ovirt-engine-notification-service################################# [ > 69%] > 21:ovirt-engine-restapi-3.2.0-4.fc18################################# [ > 72%] > 22:ovirt-engine-setup-3.2.0-4.fc18 ################################# [ > 76%] > 23:ovirt-engine-userportal-3.2.0-4.f################################# [ > 79%] > 24:ovirt-engine-webadmin-portal-3.2.################################# [ > 83%] > 25:ovirt-engine-3.2.0-4.fc18 warning: /etc/sysconfig/ovirt-engine > saved as /etc/sysconfig/ovirt-engine.rpmsave > ################################# [ 86%] > 26:ovirt-image-uploader-3.2.0-1.fc18################################# [ > 90%] > 27:ovirt-iso-uploader-3.2.0-1.fc18 ################################# [ > 93%] > 28:ovirt-log-collector-3.2.0-1.fc18 ################################# [ > 97%] > 29:ovirt-engine-sdk-3.2.0.9-1.fc18 ################################# > [100%] > ========================================================== > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > [root at engine ~]# engine-setup > Welcome to oVirt Engine setup utility > > WARNING: oVirt Engine setup has already been run on this host. > To remove all configuration and reset oVirt Engine please run > engine-cleanup. > Please be advised that executing engine-setup without cleanup is not > supported. > Would you like to proceed? (yes|no): yes > > In order to proceed the installer must stop the ovirt-engine service > Would you like to stop the ovirt-engine service? (yes|no): yes > oVirt Engine uses httpd to proxy requests to the application server. > It looks like the httpd installed locally is being actively used. > The installer can override current configuration . > Alternatively you can use JBoss directly (on ports higher than 1024) > Do you wish to override current httpd configuration and restart the > service? ['yes'| 'no'] [yes] : > HTTP Port [80] : > HTTPS Port [443] : > Setup can configure server default page to launch oVirt Engine. Do you > wish to do so? ['yes'| 'no'] [yes] : > Host fully qualified domain name. Note: this name should be fully > resolvable [engine.startn.com] : > The IP 192.168.11.12 does not hold a PTR record for the FQDN: > engine.startn.com > User input failed validation, do you still wish to use it? (yes|no): yes > Enter a password for an internal oVirt Engine administrator user > (admin at internal) : > Warning: Weak Password. > Confirm password : > Organization Name for the Certificate [startn.com] : > The engine can be configured to present the UI in three different > application modes. virt [Manage virtualization only], gluster [Manage > gluster storage only], and both [Manage virtualization as well as gluster > storage] ['virt'| 'gluster'| 'both'] [both] : > The default storage type you will be using ['NFS'| 'FC'| 'ISCSI'| > 'POSIXFS'] [NFS] : > Enter DB type for installation ['remote'| 'local'] [local] : > Enter a password for a local oVirt Engine DB admin user (engine) : > Warning: Weak Password. > Confirm password : > Local ISO domain path [/var/lib/exports/iso_2013_04_19_21_46_58] : > Firewall ports need to be opened. > The installer can configure firewall automatically overriding the current > configuration. The old configuration will be backed up. > Alternately you can configure the firewall later using an example file > selecting None. > Which firewall manager do you wish to use? ['None'| 'Firewalld'| > 'iptables']: None > Configure VDSM on this host? ['yes'| 'no'] [yes] : > Local storage domain path [/var/lib/images_2013_04_19_21_46_58] : > Confirm root password : > > oVirt Engine will be installed using the following configuration: > ================================================================= > override-httpd-config: yes > http-port: 80 > https-port: 443 > override-httpd-root: yes > host-fqdn: engine.startn.com > auth-pass: ******** > org-name: startn.com > application-mode: both > default-dc-type: NFS > db-remote-install: local > db-local-pass: ******** > nfs-mp: /var/lib/exports/iso_2013_04_19_21_46_58 > firewall-manager: None > config-allinone: yes > storage-path: /var/lib/images_2013_04_19_21_46_58 > superuser-pass: ******** > Proceed with the configuration listed above? (yes|no): yes > > Installing: > AIO: Validating CPU Compatibility... [ DONE ] > AIO: Adding firewall rules... [ DONE ] > Configuring oVirt Engine... [ DONE ] > Configuring JVM... [ DONE ] > Creating CA... [ DONE ] > Updating ovirt-engine service... [ DONE ] > Setting Database Configuration... [ DONE ] > Setting Database Security... [ DONE ] > Upgrading Database Schema... [ DONE ] > Editing oVirt Engine Configuration... [ DONE ] > Editing Postgresql Configuration... [ DONE ] > Configuring the Default ISO Domain... [ DONE ] > Configuring Firewall... [ DONE ] > Starting ovirt-engine Service... [ DONE ] > Configuring HTTPD... [ DONE ] > AIO: Creating storage directory... [ DONE ] > AIO: Adding Local Datacenter and cluster... [ ERROR ] > Error: could not create ovirtsdk API object > Please check log file > /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log for more > information > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > cat /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = > 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:39::DEBUG::setup_sequences::59::root:: running > _setupVarPrivileges > 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command > --> 'chown -Rh ovirt:ovirt /var/lib/ovirt-engine/deployments' in working > directory '/root' > 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = > 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:39::DEBUG::setup_sequences::59::root:: running > _startEngine > 2013-04-19 21:48:39::DEBUG::engine-setup::1787::root:: using chkconfig to > enable engine to load on system startup. > 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command > --> '/sbin/chkconfig ovirt-engine on' in working directory '/root' > 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = Note: > Forwarding request to 'systemctl enable ovirt-engine.service'. > > 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:39::DEBUG::common_utils::1285::root:: stopping > ovirt-engine > 2013-04-19 21:48:39::DEBUG::common_utils::1322::root:: executing action > ovirt-engine on service stop > 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command > --> '/sbin/service ovirt-engine stop' in working directory '/root' > 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = Redirecting > to /bin/systemctl stop ovirt-engine.service > > 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:39::DEBUG::common_utils::1275::root:: starting > ovirt-engine > 2013-04-19 21:48:39::DEBUG::common_utils::1322::root:: executing action > ovirt-engine on service start > 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command > --> '/sbin/service ovirt-engine start' in working directory '/root' > 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = Redirecting > to /bin/systemctl start ovirt-engine.service > > 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:39::DEBUG::setup_sequences::59::root:: running > _configureSelinuxBoolean > 2013-04-19 21:48:39::DEBUG::engine-setup::742::root:: Enable > httpd_can_network_connect boolean > 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command > --> '/usr/sbin/semanage boolean --modify --on httpd_can_network_connect' in > working directory '/root' > 2013-04-19 21:48:52::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:52::DEBUG::common_utils::495::root:: stderr = > 2013-04-19 21:48:52::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running > _backupOldHttpdConfig > 2013-04-19 21:48:52::DEBUG::engine-setup::728::root:: Backup old httpd > configuration files > 2013-04-19 21:48:52::DEBUG::engine-setup::732::root:: Backing up > /etc/httpd/conf/httpd.conf into > /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 > 2013-04-19 21:48:52::DEBUG::common_utils::729::root:: successfully copied > file /etc/httpd/conf/httpd.conf to target destination > /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 > 2013-04-19 21:48:52::DEBUG::common_utils::737::root:: setting file > /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 uid/gid ownership > 2013-04-19 21:48:52::DEBUG::common_utils::740::root:: setting file > /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 mode to -1 > 2013-04-19 21:48:52::DEBUG::engine-setup::737::root:: Backing up > /etc/httpd/conf.d/ssl.conf into > /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 > 2013-04-19 21:48:52::DEBUG::common_utils::729::root:: successfully copied > file /etc/httpd/conf.d/ssl.conf to target destination > /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 > 2013-04-19 21:48:52::DEBUG::common_utils::737::root:: setting file > /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 uid/gid ownership > 2013-04-19 21:48:52::DEBUG::common_utils::740::root:: setting file > /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 mode to -1 > 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running > _configureHttpdSslKeys > 2013-04-19 21:48:52::DEBUG::engine-setup::754::root:: Update > /etc/httpd/conf.d/ssl.conf to use engine private key in mod_ssl directives > 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running > _configureHttpdPort > 2013-04-19 21:48:52::DEBUG::engine-setup::786::root:: Update > /etc/httpd/conf/httpd.conf to listen in the new HTTP port > 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running > _configureHttpdSslPort > 2013-04-19 21:48:52::DEBUG::engine-setup::798::root:: Update > /etc/httpd/conf.d/ssl.conf to listen in the new HTTPS port > 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running > _redirectUrl > 2013-04-19 21:48:52::DEBUG::common_utils::84::root:: Processing template > /usr/share/ovirt-engine/conf/ovirt-engine-proxy.conf.in to > /etc/httpd/conf.d/z-ovirt-engine-proxy.conf vars {'@JBOSS_AJP_PORT@': > '8702'} > 2013-04-19 21:48:52::DEBUG::common_utils::729::root:: successfully copied > file /usr/share/ovirt-engine/conf/ovirt-engine-root-redirect.conf.in to > target destination /etc/httpd/conf.d/ovirt-engine-root-redirect.conf > 2013-04-19 21:48:52::DEBUG::common_utils::737::root:: setting file > /etc/httpd/conf.d/ovirt-engine-root-redirect.conf uid/gid ownership > 2013-04-19 21:48:52::DEBUG::common_utils::740::root:: setting file > /etc/httpd/conf.d/ovirt-engine-root-redirect.conf mode to -1 > 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running _startHttpd > 2013-04-19 21:48:52::DEBUG::engine-setup::1769::root:: Handling the httpd > service > 2013-04-19 21:48:52::DEBUG::common_utils::456::root:: Executing command > --> '/sbin/chkconfig httpd on' in working directory '/root' > 2013-04-19 21:48:52::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:52::DEBUG::common_utils::495::root:: stderr = Note: > Forwarding request to 'systemctl enable httpd.service'. > > 2013-04-19 21:48:52::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:52::DEBUG::common_utils::1285::root:: stopping httpd > 2013-04-19 21:48:52::DEBUG::common_utils::1322::root:: executing action > httpd on service stop > 2013-04-19 21:48:52::DEBUG::common_utils::456::root:: Executing command > --> '/sbin/service httpd stop' in working directory '/root' > 2013-04-19 21:48:52::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:52::DEBUG::common_utils::495::root:: stderr = Redirecting > to /bin/systemctl stop httpd.service > > 2013-04-19 21:48:52::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:52::DEBUG::common_utils::1275::root:: starting httpd > 2013-04-19 21:48:52::DEBUG::common_utils::1322::root:: executing action > httpd on service start > 2013-04-19 21:48:52::DEBUG::common_utils::456::root:: Executing command > --> '/sbin/service httpd start' in working directory '/root' > 2013-04-19 21:48:54::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:54::DEBUG::common_utils::495::root:: stderr = Redirecting > to /bin/systemctl start httpd.service > > 2013-04-19 21:48:54::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:54::DEBUG::setup_sequences::59::root:: running > makeStorageDir > 2013-04-19 21:48:54::DEBUG::all_in_one_100::374::root:: Creating/Verifying > local domain path > 2013-04-19 21:48:54::DEBUG::all_in_one_100::377::root:: Creating directory > /var/lib/images_2013_04_19_21_46_58 > 2013-04-19 21:48:54::DEBUG::all_in_one_100::380::root:: Setting selinux > context > 2013-04-19 21:48:54::DEBUG::nfsutils::119::root:: setting selinux context > for /var/lib/images_2013_04_19_21_46_58 > 2013-04-19 21:48:54::DEBUG::common_utils::456::root:: Executing command > --> '/usr/sbin/semanage fcontext -a -t public_content_rw_t > /var/lib/images_2013_04_19_21_46_58(/.*)?' in working directory '/root' > 2013-04-19 21:48:55::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:55::DEBUG::common_utils::495::root:: stderr = > 2013-04-19 21:48:55::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:55::DEBUG::common_utils::456::root:: Executing command > --> '/sbin/restorecon -r /var/lib/images_2013_04_19_21_46_58' in working > directory '/root' > 2013-04-19 21:48:55::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:55::DEBUG::common_utils::495::root:: stderr = > 2013-04-19 21:48:55::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:55::DEBUG::setup_sequences::59::root:: running > waitForJbossUp > 2013-04-19 21:48:55::DEBUG::all_in_one_100::451::root:: Checking JBoss > status. > 2013-04-19 21:48:55::INFO::all_in_one_100::454::root:: JBoss is up and > running. > 2013-04-19 21:48:55::DEBUG::setup_sequences::59::root:: running initAPI > 2013-04-19 21:48:55::DEBUG::all_in_one_100::240::root:: Initiating the API > object > 2013-04-19 21:48:56::ERROR::all_in_one_100::251::root:: Traceback (most > recent call last): > File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line > 248, in initAPI > ca_file=basedefs.FILE_CA_CRT_SRC, > File "/usr/lib/python2.7/site-packages/ovirtsdk/api.py", line 119, in > __init__ > url='/api' > File > "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line > 112, in request > persistent_auth=self._persistent_auth) > File > "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line > 134, in __doRequest > persistent_auth=persistent_auth > File "/usr/lib/python2.7/site-packages/ovirtsdk/web/connection.py", > line 133, in doRequest > raise RequestError, response > RequestError: > status: 401 > reason: Unauthorized > detail: HTTP Status 401 > > 2013-04-19 21:48:56::DEBUG::setup_sequences::62::root:: Traceback (most > recent call last): > File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, in > run > function() > File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line > 252, in initAPI > raise Exception(ERROR_CREATE_API_OBJECT) > Exception: Error: could not create ovirtsdk API object > > 2013-04-19 21:48:56::DEBUG::engine-setup::2064::root:: *** The following > params were used as user input: > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: > override-httpd-config: yes > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: http-port: 80 > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: https-port: 443 > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: > override-httpd-root: yes > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: random-passwords: no > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: mac-range: > 00:1A:4A:A8:C3:00-00:1A:4A:A8:C3:FF > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: host-fqdn: > engine.startn.com > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: auth-pass: ******** > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: org-name: > startn.com > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: application-mode: > both > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: default-dc-type: NFS > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: db-remote-install: > local > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: db-host: localhost > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: db-local-pass: > ******** > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: nfs-mp: > /var/lib/exports/iso_2013_04_19_21_46_58 > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: iso-domain-name: > ISO_DOMAIN > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: config-nfs: yes > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: firewall-manager: > None > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: config-allinone: yes > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: storage-path: > /var/lib/images_2013_04_19_21_46_58 > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: superuser-pass: > ******** > 2013-04-19 21:48:56::ERROR::engine-setup::2504::root:: Traceback (most > recent call last): > File "/usr/bin/engine-setup", line 2498, in > main(confFile) > File "/usr/bin/engine-setup", line 2265, in main > runSequences() > File "/usr/bin/engine-setup", line 2184, in runSequences > controller.runAllSequences() > File "/usr/share/ovirt-engine/scripts/setup_controller.py", line 54, in > runAllSequences > sequence.run() > File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 154, in > run > step.run() > File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, in > run > function() > File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line > 252, in initAPI > raise Exception(ERROR_CREATE_API_OBJECT) > Exception: Error: could not create ovirtsdk API object > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > HI?All > > ????? > > --- > ??????????? > ?? > > ------------------------------------------------------------------------------ > > > + ????????????????(????1:1) + > > ------------------------------------------------------------------------------ > > > 2013/4/20 ?? > >> HI?Alon >> >> Thank your help, >> >> The question: >> 1,Your email "Close the repository", What does it mean? >> >> 2,Your email "Alternatively, you can try out soon to be merged >> development environment[1][2]" >> Is it stable? >> Can be used in a production environment? >> >> Thanks again your help, >> >> >> HI?All >> >> ????? >> >> --- >> ??????????? >> ?? >> >> ------------------------------------------------------------------------------ >> >> >> + ????????????????(????1:1) + >> >> ------------------------------------------------------------------------------ >> >> >> 2013/4/19 Alon Bar-Lev >> >>> Please try setup product without tweaks if you don't have real reason to. >>> >>> Close the repository, then: >>> $ make tarball >>> $ rpmbuild -t >>> >>> Then install the result rpms as usual. >>> >>> Alternatively, you can try out soon to be merged development >>> environment[1][2] >>> >>> [1] https://github.com/alonbl/ovirt-engine/tree/otopi >>> [2] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer >>> >>> >>> ----- Original Message ----- >>> > From: "??" >>> > To: engine-devel at ovirt.org >>> > Sent: Friday, April 19, 2013 6:18:24 PM >>> > Subject: [Engine-devel] Why deploy failed? Please help me, thanks. >>> > >>> > >>> > HI?All >>> > >>> > OS:F18 >>> > Ovirt engine version: >>> > the first is 3.2.0 >>> > update to 3.2.1 >>> > and now I compile the source to other language. >>> > MEM:8G >>> > CPU:I7 >>> > DISK:60G >>> > >>> > >>> > I will use chinese language for ovirt engine, >>> > but rpm have not chinese language for default install. >>> > >>> > So I git clone source, that I compile the source success. >>> > From link: >>> > http://www.ovirt.org/Building_oVirt_engine >>> > >>> > COMPILE COMMAND >>> > mvn clean install -Pdep,gwt-admin,gwt-user,all-langs >>> > and show message: >>> > ------------------------ >>> > >>> > ------------------------ >>> > >>> > I deploy: >>> > DEPLOY COMMAND: >>> > cd ear && mvn clean install -Pdep >>> > >>> > QUESTION: >>> > 1, >>> > I open the first page that it show >>> > ------------------ >>> > Welcome to Open Virtualization Manager. >>> > Version 3.2.1- >>> > ------------------ >>> > Source shoule be 3.3.0? >>> > If souce version 3.3.0,then I deploy is not invalid. >>> > >>> > 2, >>> > Change language is failed and is still englist. >>> > Other language is invalid. >>> > COMMAND DEPLOY: >>> > ++++++++++++++++++++++ >>> > [liqiang at engine ear]$ mvn clean install -Pdep >>> > [INFO] Scanning for projects... >>> > [WARNING] >>> > [WARNING] Some problems were encountered while building the effective >>> model >>> > for org.ovirt.engine:engine-server-ear:ear:3.3.0-SNAPSHOT >>> > [WARNING] ' distributionManagement.repository.id ' must not be >>> 'local', this >>> > identifier is reserved for the local repository, using it for other >>> > repositories will corrupt your repository metadata. @ line 18, column >>> 11 >>> > [WARNING] >>> > [WARNING] It is highly recommended to fix these problems because they >>> > threaten the stability of your build. >>> > [WARNING] >>> > [WARNING] For this reason, future Maven versions might no longer >>> support >>> > building such malformed projects. >>> > [WARNING] >>> > [INFO] >>> > [INFO] >>> > >>> ------------------------------------------------------------------------ >>> > [INFO] Building oVirt Server EAR 3.3.0-SNAPSHOT >>> > [INFO] >>> > >>> ------------------------------------------------------------------------ >>> > [INFO] >>> > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ >>> engine-server-ear >>> > --- >>> > [INFO] Deleting /home/liqiang/ovirt-engine/ear/target >>> > [INFO] >>> > [INFO] --- maven-antrun-plugin:1.7:run (undeploy-ear) @ >>> engine-server-ear --- >>> > [WARNING] Parameter tasks is deprecated, use target instead >>> > [INFO] Executing tasks >>> > >>> > main: >>> > [echo] *** Deleting >>> /usr/share/jboss-as/standalone/deployments/engine.ear/... >>> > [delete] Deleting directory >>> > /usr/share/jboss-as/standalone/deployments/engine.ear >>> > [INFO] Executed tasks >>> > [INFO] >>> > [INFO] --- maven-ear-plugin:2.8:generate-application-xml >>> > (default-generate-application-xml) @ engine-server-ear --- >>> > [INFO] Generating application.xml >>> > [INFO] >>> > [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ >>> > engine-server-ear --- >>> > [INFO] Using 'UTF-8' encoding to copy filtered resources. >>> > [INFO] skip non existing resourceDirectory >>> > /home/liqiang/ovirt-engine/ear/src/main/java >>> > [INFO] Copying 1 resource >>> > [INFO] >>> > [INFO] --- maven-ear-plugin:2.8:ear (default-ear) @ engine-server-ear >>> --- >>> > [INFO] Copying artifact >>> [war:org.ovirt.engine.core:root-war:3.3.0-SNAPSHOT] >>> > to [root.war] (unpacked) >>> > [INFO] Copying artifact >>> > [war:org.ovirt.engine.api:restapi-webapp:3.3.0-SNAPSHOT] to >>> [restapi.war] >>> > (unpacked) >>> > [INFO] Copying artifact >>> [war:org.ovirt.engine.ui:userportal:3.3.0-SNAPSHOT] >>> > to [userportal.war] (unpacked) >>> > [INFO] Copying artifact >>> [war:org.ovirt.engine.ui:webadmin:3.3.0-SNAPSHOT] to >>> > [webadmin.war] (unpacked) >>> > [INFO] Copying artifact >>> [ejb:org.ovirt.engine.core:scheduler:3.3.0-SNAPSHOT] >>> > to [scheduler.jar] >>> > [INFO] Copying artifact [ejb:org.ovirt.engine.core:bll:3.3.0-SNAPSHOT] >>> to >>> > [bll.jar] >>> > [INFO] Copying artifact >>> [jar:org.ovirt.engine.core:vdsbroker:3.3.0-SNAPSHOT] >>> > to [lib/vdsbroker.jar] >>> > [INFO] Copying artifact >>> [jar:org.ovirt.engine.core:compat:3.3.0-SNAPSHOT] to >>> > [lib/compat.jar] >>> > [INFO] Copying artifact >>> [jar:org.ovirt.engine.core:common:3.3.0-SNAPSHOT] to >>> > [lib/common.jar] >>> > [INFO] Copying artifact [jar:org.hibernate:hibernate-validator: >>> 4.0.2.GA ] to >>> > [lib/hibernate-validator.jar] >>> > [INFO] Copying artifact [jar:javax.validation:validation-api: 1.0.0.GA] to >>> > [lib/validation-api.jar] >>> > [INFO] Copying artifact [jar:javax.xml.bind:jaxb-api:2.1] to >>> > [lib/jaxb-api.jar] >>> > [INFO] Copying artifact [jar:javax.xml.stream:stax-api:1.0-2] to >>> > [lib/stax-api.jar] >>> > [INFO] Copying artifact [jar:com.sun.xml.bind:jaxb-impl:2.1.3] to >>> > [lib/jaxb-impl.jar] >>> > [INFO] Copying artifact >>> [jar:org.ovirt.engine.core:utils:3.3.0-SNAPSHOT] to >>> > [lib/utils.jar] >>> > [INFO] Copying artifact >>> [jar:commons-beanutils:commons-beanutils:1.8.2] to >>> > [lib/commons-beanutils.jar] >>> > [INFO] Copying artifact [jar:org.apache.mina:mina-core:2.0.1] to >>> > [lib/mina-core.jar] >>> > [INFO] Copying artifact [jar:org.apache.sshd:sshd-core:0.7.0] to >>> > [lib/sshd-core.jar] >>> > [INFO] Copying artifact [jar:org.ovirt.otopi:otopi:1.0.0] to >>> [lib/otopi.jar] >>> > [INFO] Copying artifact >>> > [jar:org.ovirt.ovirt-host-deploy:ovirt-host-deploy:1.0.0] to >>> > [lib/ovirt-host-deploy.jar] >>> > [INFO] Copying artifact >>> [jar:org.apache.commons:commons-compress:1.4.1] to >>> > [lib/commons-compress.jar] >>> > [INFO] Copying artifact [jar:org.tukaani:xz:1.0] to [lib/xz.jar] >>> > [INFO] Copying artifact [jar:commons-lang:commons-lang:2.6] to >>> > [lib/commons-lang.jar] >>> > [INFO] Copying artifact [jar:commons-codec:commons-codec:1.4] to >>> > [lib/commons-codec.jar] >>> > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] to >>> > [lib/xmlrpc-client.jar] >>> > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] to >>> > [lib/xmlrpc-common.jar] >>> > [INFO] Copying artifact >>> > [jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to >>> > [lib/ws-commons-util.jar] >>> > [INFO] Copying artifact [jar:xml-apis:xml-apis:1.0.b2] to >>> [lib/xml-apis.jar] >>> > [INFO] Copying artifact [jar:org.ovirt.engine.core:dal:3.3.0-SNAPSHOT] >>> to >>> > [lib/dal.jar] >>> > [INFO] Copying artifact >>> [jar:org.springframework:spring-jdbc:3.1.1.RELEASE] >>> > to [lib/spring-jdbc.jar] >>> > [INFO] Copying artifact >>> [jar:org.springframework:spring-tx:3.1.1.RELEASE] to >>> > [lib/spring-tx.jar] >>> > [INFO] Copying artifact >>> > [jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to >>> > [lib/spring-ldap-core.jar] >>> > [INFO] Copying artifact >>> [jar:commons-httpclient:commons-httpclient:3.1] to >>> > [lib/commons-httpclient.jar] >>> > [INFO] Copying artifact >>> [jar:commons-collections:commons-collections:3.1] to >>> > [lib/commons-collections.jar] >>> > [INFO] Copying artifact [jar:org.quartz-scheduler:quartz:2.1.2] to >>> > [lib/quartz.jar] >>> > [INFO] Copying artifact [jar:c3p0:c3p0:0.9.1.1] to [lib/c3p0.jar] >>> > [INFO] Copying artifact [jar:org.slf4j:slf4j-api:1.6.1] to >>> > [lib/slf4j-api.jar] >>> > [INFO] Copying artifact >>> > [jar:org.ovirt.engine.core:searchbackend:3.3.0-SNAPSHOT] to >>> > [lib/searchbackend.jar] >>> > [INFO] Copying artifact >>> > >>> [jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] >>> > to [lib/jboss-interceptors-api_1.1_spec.jar] >>> > [INFO] Copying artifact >>> [jar:org.springframework:spring-core:3.1.1.RELEASE] >>> > to [lib/spring-core.jar] >>> > [INFO] Copying artifact >>> [jar:org.springframework:spring-asm:3.1.1.RELEASE] to >>> > [lib/spring-asm.jar] >>> > [INFO] Copying artifact >>> [jar:org.springframework:spring-beans:3.1.1.RELEASE] >>> > to [lib/spring-beans.jar] >>> > [INFO] Copying artifact >>> > [jar:org.springframework:spring-context:3.1.1.RELEASE] to >>> > [lib/spring-context.jar] >>> > [INFO] Copying artifact >>> [jar:org.springframework:spring-aop:3.1.1.RELEASE] to >>> > [lib/spring-aop.jar] >>> > [INFO] Copying artifact [jar:aopalliance:aopalliance:1.0] to >>> > [lib/aopalliance.jar] >>> > [INFO] Copying artifact >>> > [jar:org.springframework:spring-expression:3.1.1.RELEASE] to >>> > [lib/spring-expression.jar] >>> > [INFO] Copy ear sources to /home/liqiang/ovirt-engine/ear/target/engine >>> > [INFO] Could not find manifest file: >>> > /home/liqiang/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF - >>> > Generating one >>> > [INFO] Building jar: /home/liqiang/ovirt-engine/ear/target/engine.ear >>> > [INFO] >>> > [INFO] --- maven-dependency-plugin:2.1:unpack (deploy-modules) @ >>> > engine-server-ear --- >>> > [INFO] Configured Artifact: >>> > org.ovirt.engine.core:dependencies:modules:3.3.0-SNAPSHOT:zip >>> > [INFO] Configured Artifact: >>> > org.ovirt.engine.core:common:modules:3.3.0-SNAPSHOT:zip >>> > [INFO] Configured Artifact: >>> > org.ovirt.engine.core:compat:modules:3.3.0-SNAPSHOT:zip >>> > [INFO] Configured Artifact: >>> > org.ovirt.engine.core:dal:modules:3.3.0-SNAPSHOT:zip >>> > [INFO] Configured Artifact: >>> > org.ovirt.engine.core:searchbackend:modules:3.3.0-SNAPSHOT:zip >>> > [INFO] Configured Artifact: >>> > org.ovirt.engine.core:tools:modules:3.3.0-SNAPSHOT:zip >>> > [INFO] Configured Artifact: >>> > org.ovirt.engine.core:utils:modules:3.3.0-SNAPSHOT:zip >>> > [INFO] Unpacking >>> > >>> /home/liqiang/.m2/repository/org/ovirt/engine/core/dependencies/3.3.0-SNAPSHOT/dependencies-3.3.0-SNAPSHOT-modules.zip >>> > to >>> > /usr/share/jboss-as/modules >>> > with includes null and excludes:null >>> > [WARNING] Unable to expand to file >>> > >>> /usr/share/jboss-as/modules/org/apache/commons/configuration/main/module.xml >>> > [WARNING] Unable to expand to file >>> > /usr/share/java/apache-commons-configuration.jar >>> > [INFO] Unpacking >>> > >>> /home/liqiang/.m2/repository/org/ovirt/engine/core/common/3.3.0-SNAPSHOT/common-3.3.0-SNAPSHOT-modules.zip >>> > to >>> > /usr/share/jboss-as/modules >>> > with includes null and excludes:null >>> > [INFO] Unpacking >>> > >>> /home/liqiang/.m2/repository/org/ovirt/engine/core/compat/3.3.0-SNAPSHOT/compat-3.3.0-SNAPSHOT-modules.zip >>> > to >>> > /usr/share/jboss-as/modules >>> > with includes null and excludes:null >>> > [INFO] Unpacking >>> > >>> /home/liqiang/.m2/repository/org/ovirt/engine/core/dal/3.3.0-SNAPSHOT/dal-3.3.0-SNAPSHOT-modules.zip >>> > to >>> > /usr/share/jboss-as/modules >>> > with includes null and excludes:null >>> > [INFO] Unpacking >>> > >>> /home/liqiang/.m2/repository/org/ovirt/engine/core/searchbackend/3.3.0-SNAPSHOT/searchbackend-3.3.0-SNAPSHOT-modules.zip >>> > to >>> > /usr/share/jboss-as/modules >>> > with includes null and excludes:null >>> > [INFO] Unpacking >>> > >>> /home/liqiang/.m2/repository/org/ovirt/engine/core/tools/3.3.0-SNAPSHOT/tools-3.3.0-SNAPSHOT-modules.zip >>> > to >>> > /usr/share/jboss-as/modules >>> > with includes null and excludes:null >>> > [INFO] Unpacking >>> > >>> /home/liqiang/.m2/repository/org/ovirt/engine/core/utils/3.3.0-SNAPSHOT/utils-3.3.0-SNAPSHOT-modules.zip >>> > to >>> > /usr/share/jboss-as/modules >>> > with includes null and excludes:null >>> > [INFO] >>> > [INFO] --- maven-antrun-plugin:1.7:run (deploy-ear) @ >>> engine-server-ear --- >>> > [WARNING] Parameter tasks is deprecated, use target instead >>> > [INFO] Executing tasks >>> > >>> > main: >>> > [echo] *** Copying updated files to >>> > /usr/share/jboss-as/standalone/deployments/engine.ear/... >>> > [unjar] Expanding: /home/liqiang/ovirt-engine/ear/target/engine.ear >>> into >>> > /usr/share/jboss-as/standalone/deployments/engine.ear >>> > [echo] *** Touching >>> > >>> /usr/share/jboss-as/standalone/deployments/engine.ear/META-INF/application.xml >>> > to force redeployment of engine.ear... >>> > [echo] *** Touching engine.ear.dodeploy to force deployment of >>> engine.ear... >>> > [INFO] Executed tasks >>> > [INFO] >>> > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ >>> > engine-server-ear --- >>> > [INFO] Installing /home/liqiang/ovirt-engine/ear/target/engine.ear to >>> > >>> /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear >>> > [INFO] Installing /home/liqiang/ovirt-engine/ear/pom.xml to >>> > >>> /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom >>> > [INFO] >>> > >>> ------------------------------------------------------------------------ >>> > [INFO] BUILD SUCCESS >>> > [INFO] >>> > >>> ------------------------------------------------------------------------ >>> > [INFO] Total time: 54.354s >>> > [INFO] Finished at: Fri Apr 19 10:48:39 EDT 2013 >>> > [INFO] Final Memory: 14M/191M >>> > [INFO] >>> > >>> ------------------------------------------------------------------------ >>> > ++++++++++++++++++++++ >>> > >>> > >>> > engine-upgrade >>> > COMMAND MESSAGE: >>> > ------------------------------------ >>> > [root at engine ~]# engine-upgrade >>> > >>> > Checking for updates... (This may take several minutes)...[ DONE ] >>> > 8 Updates available: >>> > * ovirt-engine-3.2.1-1.fc18.noarch >>> > * ovirt-engine-tools-3.2.1-1.fc18.noarch >>> > * ovirt-engine-backend-3.2.1-1.fc18.noarch >>> > * ovirt-engine-dbscripts-3.2.1-1.fc18.noarch >>> > * ovirt-engine-genericapi-3.2.1-1.fc18.noarch >>> > * ovirt-engine-restapi-3.2.1-1.fc18.noarch >>> > * ovirt-engine-userportal-3.2.1-1.fc18.noarch >>> > * ovirt-engine-webadmin-portal-3.2.1-1.fc18.noarch >>> > >>> > During the upgrade process, oVirt Engine will not be accessible. >>> > All existing running virtual machines will continue but you will not >>> be able >>> > to >>> > start or stop any new virtual machines during the process. >>> > >>> > Would you like to proceed? (yes|no): yes >>> > Stopping ovirt-engine service... [ DONE ] >>> > Stopping DB related services... [ DONE ] >>> > Pre-upgrade validations... [ DONE ] >>> > Backing Up Database... [ DONE ] >>> > Rename Database... [ DONE ] >>> > Updating rpms... [ DONE ] >>> > Updating Database... [ DONE ] >>> > Restore Database name... [ DONE ] >>> > Preparing CA... [ DONE ] >>> > Running post install configuration... [ DONE ] >>> > Starting ovirt-engine service... [ DONE ] >>> > >>> > oVirt Engine upgrade completed successfully! >>> > >>> > * Upgrade log available at >>> > /var/log/ovirt-engine/ovirt-engine-upgrade_2013_04_19_10_39_54.log >>> > * DB Backup available at >>> > >>> /var/lib/ovirt-engine/backups/ovirt-engine_db_backup_2013_04_19_10_39_54.sql >>> > ------------------------------------ >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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: From liqiang.net at gmail.com Sat Apr 20 02:37:41 2013 From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=) Date: Sat, 20 Apr 2013 10:37:41 +0800 Subject: [Engine-devel] Why deploy failed? Please help me, thanks. In-Reply-To: References: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> Message-ID: [root at engine ~]# rpm -qa | grep ^ovi* ovirt-engine-backend-3.3.0-0.2.master.20130419160733.fc18.noarch ovirt-host-deploy-offline-1.1.0-0.0.master.20130418.git827d30b.fc18.noarch ovirt-engine-setup-3.3.0-0.2.master.20130419160733.fc18.noarch ovirt-engine-sdk-3.3.0.1-1.20130418.gitfc5985e.fc18.noarch ovirt-host-deploy-java-1.0.1-1.fc18.noarch ovirt-iso-uploader-3.3.0-0.0.master.20130318.gitec3e5e7.fc18.noarch ovirt-engine-restapi-3.3.0-0.2.master.20130419160733.fc18.noarch ovirt-engine-webadmin-portal-3.3.0-0.2.master.20130419160733.fc18.noarch ovirt-image-uploader-3.3.0-0.0.master.20130417.git13f9ba3.fc18.noarch ovirt-engine-dbscripts-3.3.0-0.2.master.20130419160733.fc18.noarch ovirt-engine-userportal-3.3.0-0.2.master.20130419160733.fc18.noarch ovirt-engine-setup-plugin-allinone-3.3.0-0.2.master.20130419160733.fc18.noarch ovirt-host-deploy-1.0.1-1.fc18.noarch ovirt-engine-tools-3.3.0-0.2.master.20130419160733.fc18.noarch ovirt-log-collector-3.3.0-0.0.master.20130417.git6a09d06.fc18.noarch ovirt-engine-3.3.0-0.2.master.20130419160733.fc18.noarch ovirt-engine-cli-3.2.0.11-1.fc18.noarch ovirt-release-fedora-5-3.noarch HI?All ????? --- ??????????? ?? ------------------------------------------------------------------------------ + ????????????????(????1:1) + ------------------------------------------------------------------------------ 2013/4/20 ?? > My process: > ps -ax > ========================== > [root at engine ~]# ps -ax > PID TTY STAT TIME COMMAND > 1 ? Ss 0:03 /usr/lib/systemd/systemd --system --deserialize > 20 > 2 ? S 0:00 [kthreadd] > 3 ? S 0:00 [ksoftirqd/0] > 5 ? S< 0:00 [kworker/0:0H] > 6 ? S 0:00 [kworker/u:0] > 7 ? S< 0:00 [kworker/u:0H] > 8 ? S 0:02 [migration/0] > 9 ? S 0:00 [rcu_bh] > 10 ? S 0:01 [rcu_sched] > 11 ? S 0:00 [watchdog/0] > 12 ? S 0:00 [watchdog/1] > 13 ? S 0:00 [ksoftirqd/1] > 14 ? S 0:01 [migration/1] > 15 ? S 0:00 [kworker/1:0] > 16 ? S< 0:00 [kworker/1:0H] > 17 ? S 0:00 [watchdog/2] > 18 ? S 0:00 [ksoftirqd/2] > 19 ? S 0:04 [migration/2] > 21 ? S< 0:00 [kworker/2:0H] > 22 ? S 0:00 [watchdog/3] > 23 ? S 0:00 [ksoftirqd/3] > 24 ? S 0:02 [migration/3] > 26 ? S< 0:00 [kworker/3:0H] > 27 ? S< 0:00 [cpuset] > 28 ? S< 0:00 [khelper] > 29 ? S 0:00 [kdevtmpfs] > 30 ? S< 0:00 [netns] > 31 ? S 0:00 [bdi-default] > 32 ? S< 0:00 [kintegrityd] > 33 ? S< 0:00 [kblockd] > 34 ? S< 0:00 [ata_sff] > 35 ? S 0:00 [khubd] > 36 ? S< 0:00 [md] > 44 ? S 0:01 [kworker/u:1] > 62 ? S 0:00 [kswapd0] > 63 ? SN 0:00 [ksmd] > 64 ? SN 0:00 [khugepaged] > 65 ? S 0:00 [fsnotify_mark] > 66 ? S< 0:00 [crypto] > 74 ? S< 0:00 [kthrotld] > 77 ? S 0:00 [scsi_eh_0] > 78 ? S 0:00 [scsi_eh_1] > 80 ? S< 0:00 [kpsmoused] > 81 ? S 0:00 [kworker/0:2] > 82 ? S 0:00 [kworker/2:1] > 83 ? S< 0:00 [deferwq] > 97 ? S 0:00 [kauditd] > 180 ? S< 0:00 [mpt_poll_0] > 181 ? S< 0:00 [mpt/0] > 189 ? S 0:00 [scsi_eh_2] > 190 ? S< 0:00 [ttm_swap] > 192 ? S< 0:01 [kworker/1:1H] > 197 ? S 0:00 [kworker/1:2] > 199 ? S< 0:01 [kworker/3:1H] > 200 ? S 0:08 [kworker/3:2] > 234 ? S< 0:01 [kworker/2:1H] > 237 ? S< 0:00 [kdmflush] > 239 ? S< 0:00 [kdmflush] > 266 ? S< 0:00 [kworker/0:1H] > 286 ? S 0:02 [jbd2/dm-1-8] > 287 ? S< 0:00 [ext4-dio-unwrit] > 330 ? Ss 0:00 /usr/lib/systemd/systemd-udevd > 333 ? Ss 0:00 /usr/lib/systemd/systemd-journald > 334 ? S 0:03 [flush-253:1] > 368 ? S< 0:00 [rpciod] > 569 ? S 0:00 [jbd2/sda1-8] > 570 ? S< 0:00 [ext4-dio-unwrit] > 580 ? S< 0:00 [kmpathd] > 581 ? S< 0:00 [kmpath_handlerd] > 586 ? S< 0:00 [kdmflush] > 605 ? S 0:00 [jbd2/dm-2-8] > 606 ? S< 0:00 [ext4-dio-unwrit] > 641 ? SLl 0:00 /sbin/multipathd > 642 ? Ss 0:00 /sbin/iprinit --daemon > 643 ? Ss 0:00 /sbin/iprupdate --daemon > 664 ? Ss 0:00 /usr/lib/systemd/systemd-logind > 666 ? Ssl 0:00 /bin/dbus-daemon --system --address=systemd: > --nofork --nopidfile --systemd-activation > 682 tty1 Ss+ 0:00 /sbin/agetty --noclear tty1 38400 linux > 687 ? S< 0:00 [iscsi_eh] > 689 ? S< 0:00 [ib_mcast] > 690 ? S< 0:00 [ib_cm] > 691 ? S< 0:00 [iw_cm_wq] > 692 ? S< 0:00 [ib_addr] > 693 ? S< 0:00 [rdma_cm] > 695 ? Ss 0:00 /sbin/iprdump --daemon > 701 ? Ss 0:00 /usr/sbin/ntpd -u ntp:ntp -g > 703 ? S 0:00 /bin/bash /usr/sbin/ksmtuned > 709 ? S< 0:00 [cxgb4] > 712 ? S< 0:00 [cnic_wq] > 713 ? S< 0:00 [bnx2i_thread/0] > 714 ? S< 0:00 [bnx2i_thread/1] > 715 ? S< 0:00 [bnx2i_thread/2] > 716 ? S< 0:00 [bnx2i_thread/3] > 730 ? Ssl 0:00 iscsiuio > 739 ? Ss 0:00 iscsid > 740 ? S 752 ? Ssl 0:00 /usr/sbin/NetworkManager --no-daemon > 885 ? SLs 0:00 wdmd -G sanlock > 915 ? SLsl 0:00 sanlock daemon -U sanlock -G sanlock > 916 ? S 0:00 sanlock daemon -U sanlock -G sanlock > 958 ? Ssl 0:00 /usr/lib/polkit-1/polkitd --no-debug > 1189 ? S 0:00 /sbin/dhclient -d -sf > /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-eth0.pid -lf > /var/lib/NetworkManager/dhcli > 1191 ? S 0:00 /sbin/dhclient -d -sf > /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-eth1.pid -lf > /var/lib/NetworkManager/dhcli > 1223 ? Ssl 0:01 /usr/sbin/libvirtd --listen > 1248 ? Ss 0:00 /usr/sbin/sshd -D > 1482 ? S< 0:00 [bond0] > 1497 ? S< 0:00 [bond4] > 1499 ? S< 0:00 [bond1] > 1500 ? S< 0:00 [bond2] > 1501 ? S< 0:00 [bond3] > 1566 ? S< 0:00 /bin/bash -e /usr/share/vdsm/respawn > --minlifetime 10 --daemon --masterpid /var/run/vdsm/respawn.pid > /usr/share/vdsm/vdsm > 1570 ? S 1589 ? S< 0:00 /usr/bin/sudo -n /usr/bin/python > /usr/share/vdsm/supervdsmServer.py 2057b468-002a-489c-a6dd-7a980cb95b3a > 1570 /var/run/vd > 1590 ? S /usr/share/vdsm/supervdsmServer.py 2057b468-002a-489c-a6dd-7a980cb95b3a > 1570 /var/run/vdsm/svdsm.pid /var > 1598 ? Ss 0:00 sshd: root at pts/0 > 1626 pts/0 Ss 0:00 -bash > 1762 ? Rs 0:00 sshd: root at pts/1 > 1766 pts/1 Ss 0:00 -bash > 4521 ? S 0:02 [kworker/3:1] > 9054 ? Ss 0:06 sshd: root at pts/2 > 9058 pts/2 Ss+ 0:00 -bash > 11471 ? S 0:00 [kworker/0:1] > 11646 ? S 0:00 [kworker/2:2] > 11652 ? Ss 0:00 /usr/sbin/crond -n > 12569 ? S 0:00 [flush-8:0] > 12618 ? S 0:00 /usr/bin/postgres -D /var/lib/pgsql/data -p 5432 > 12619 ? Ss 0:00 postgres: logger process > 12621 ? Ss 0:00 postgres: checkpointer process > 12622 ? Ss 0:00 postgres: writer process > 12623 ? Ss 0:00 postgres: wal writer process > 12624 ? Ss 0:00 postgres: autovacuum launcher process > 12625 ? Ss 0:00 postgres: stats collector process > 12657 ? Ssl 0:00 /usr/sbin/named -u named > 12691 ? Ss 0:00 sendmail: accepting connections > 12719 ? Ss 0:00 sendmail: Queue runner at 01:00:00 for > /var/spool/clientmqueue > 12764 ? Ss 0:00 /bin/sh /usr/share/jboss-as/bin/standalone.sh > -c standalone.xml -b 0.0.0.0 > 12816 ? Sl 0:07 java -D[Standalone] -server > -XX:+UseCompressedOops -XX:+TieredCompilation -Xms64m -Xmx512m > -XX:MaxPermSize=256m -Djava.ne > 12985 ? Ss 0:00 /usr/bin/python /usr/sbin/firewalld --nofork > 13318 ? S 13363 ? Ssl 0:00 /sbin/rsyslogd -n > 20734 ? S 0:00 [kworker/0:0] > 20896 pts/0 Sl+ 0:01 /usr/bin/python /usr/bin/engine-setup > 22780 ? Ss 0:00 /sbin/rpcbind -w > 22805 ? Ss 0:00 /usr/bin/python > /usr/share/ovirt-engine/service/engine-service.py start > 22807 ? Sl 0:12 engine-service -server -XX:+TieredCompilation > -Xms1g -Xmx1g -XX:PermSize=256m -XX:MaxPermSize=256m -Djava.net.preferIPv4S > 22876 ? Ss 0:00 postgres: engine engine 127.0.0.1(44637) idle > 22889 ? Ss 0:00 postgres: engine engine 127.0.0.1(44638) idle > 22892 ? Ss 0:00 postgres: engine engine 127.0.0.1(44639) idle > 22920 ? Ss 0:00 /usr/sbin/httpd -DFOREGROUND > 22922 ? S 0:00 /usr/sbin/httpd -DFOREGROUND > 22923 ? S 0:00 /usr/sbin/httpd -DFOREGROUND > 22924 ? S 0:00 /usr/sbin/httpd -DFOREGROUND > 22925 ? S 0:00 /usr/sbin/httpd -DFOREGROUND > 22926 ? S 0:00 /usr/sbin/httpd -DFOREGROUND > 22945 ? S 0:00 sleep 60 > 22946 pts/1 R+ 0:00 ps -ax > [root at engine ~]# > ========================== > > and I run : > yum update and setup still is ERROR. > > Please help my ,thanks, > > HI?All > > ????? > > --- > ??????????? > ?? > > ------------------------------------------------------------------------------ > > > + ????????????????(????1:1) + > > ------------------------------------------------------------------------------ > > > 2013/4/20 ?? > >> I have ERROR and Please help me ,thanks >> >> The first Upgrade is SUCCESS. >> Please look the info. >> >> But engine-set is ERROR. >> AIO: Adding Local Datacenter and cluster... [ ERROR ] >> Error: could not create ovirtsdk API object >> Please check log file >> /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log for more >> information >> >> >> ========================================================== >> [root at engine noarch]# rpm -Uvh *.rpm >> Preparing... ################################# >> [100%] >> Updating / installing... >> 1:ovirt-engine-sdk-3.3.0.1-1.201304################################# [ >> 3%] >> 2:ovirt-image-uploader-3.3.0-0.0.ma#################################[ 7%] >> 3:ovirt-iso-uploader-3.3.0-0.0.mast################################# [ >> 10%] >> 4:ovirt-log-collector-3.3.0-0.0.mas################################# [ >> 14%] >> 5:ovirt-engine-backend-3.3.0-0.2.ma#################################[ 17%] >> 6:ovirt-engine-dbscripts-3.3.0-0.2.################################# [ >> 21%] >> 7:ovirt-engine-restapi-3.3.0-0.2.ma#################################[ 24%] >> 8:ovirt-engine-setup-3.3.0-0.2.mastwarning: >> /etc/firewalld/services/ovirt.xml created as >> /etc/firewalld/services/ovirt.xml.rpmnew >> ################################# [ 28%] >> 9:ovirt-engine-tools-3.3.0-0.2.mast################################# [ >> 31%] >> 10:ovirt-engine-userportal-3.3.0-0.2################################# [ >> 34%] >> 11:ovirt-engine-webadmin-portal-3.3.################################# [ >> 38%] >> 12:ovirt-engine-3.3.0-0.2.master.201################################# [ >> 41%] >> 13:ovirt-host-deploy-offline-1.1.0-0################################# [ >> 45%] >> 14:ovirt-engine-setup-plugin-allinon################################# [ >> 48%] >> Cleaning up / removing... >> 15:ovirt-engine-backend-3.2.0-4.fc18################################# [ >> 52%] >> 16:ovirt-engine-config-3.2.0-4.fc18 ################################# [ >> 55%] >> 17:ovirt-engine-dbscripts-3.2.0-4.fc################################# [ >> 59%] >> 18:ovirt-engine-genericapi-3.2.0-4.f################################# [ >> 62%] >> 19:ovirt-engine-tools-common-3.2.0-4################################# [ >> 66%] >> 20:ovirt-engine-notification-service################################# [ >> 69%] >> 21:ovirt-engine-restapi-3.2.0-4.fc18################################# [ >> 72%] >> 22:ovirt-engine-setup-3.2.0-4.fc18 ################################# [ >> 76%] >> 23:ovirt-engine-userportal-3.2.0-4.f################################# [ >> 79%] >> 24:ovirt-engine-webadmin-portal-3.2.################################# [ >> 83%] >> 25:ovirt-engine-3.2.0-4.fc18 warning: >> /etc/sysconfig/ovirt-engine saved as /etc/sysconfig/ovirt-engine.rpmsave >> ################################# [ 86%] >> 26:ovirt-image-uploader-3.2.0-1.fc18################################# [ >> 90%] >> 27:ovirt-iso-uploader-3.2.0-1.fc18 ################################# [ >> 93%] >> 28:ovirt-log-collector-3.2.0-1.fc18 ################################# [ >> 97%] >> 29:ovirt-engine-sdk-3.2.0.9-1.fc18 ################################# >> [100%] >> ========================================================== >> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> [root at engine ~]# engine-setup >> Welcome to oVirt Engine setup utility >> >> WARNING: oVirt Engine setup has already been run on this host. >> To remove all configuration and reset oVirt Engine please run >> engine-cleanup. >> Please be advised that executing engine-setup without cleanup is not >> supported. >> Would you like to proceed? (yes|no): yes >> >> In order to proceed the installer must stop the ovirt-engine service >> Would you like to stop the ovirt-engine service? (yes|no): yes >> oVirt Engine uses httpd to proxy requests to the application server. >> It looks like the httpd installed locally is being actively used. >> The installer can override current configuration . >> Alternatively you can use JBoss directly (on ports higher than 1024) >> Do you wish to override current httpd configuration and restart the >> service? ['yes'| 'no'] [yes] : >> HTTP Port [80] : >> HTTPS Port [443] : >> Setup can configure server default page to launch oVirt Engine. Do you >> wish to do so? ['yes'| 'no'] [yes] : >> Host fully qualified domain name. Note: this name should be fully >> resolvable [engine.startn.com] : >> The IP 192.168.11.12 does not hold a PTR record for the FQDN: >> engine.startn.com >> User input failed validation, do you still wish to use it? (yes|no): yes >> Enter a password for an internal oVirt Engine administrator user >> (admin at internal) : >> Warning: Weak Password. >> Confirm password : >> Organization Name for the Certificate [startn.com] : >> The engine can be configured to present the UI in three different >> application modes. virt [Manage virtualization only], gluster [Manage >> gluster storage only], and both [Manage virtualization as well as gluster >> storage] ['virt'| 'gluster'| 'both'] [both] : >> The default storage type you will be using ['NFS'| 'FC'| 'ISCSI'| >> 'POSIXFS'] [NFS] : >> Enter DB type for installation ['remote'| 'local'] [local] : >> Enter a password for a local oVirt Engine DB admin user (engine) : >> Warning: Weak Password. >> Confirm password : >> Local ISO domain path [/var/lib/exports/iso_2013_04_19_21_46_58] : >> Firewall ports need to be opened. >> The installer can configure firewall automatically overriding the current >> configuration. The old configuration will be backed up. >> Alternately you can configure the firewall later using an example file >> selecting None. >> Which firewall manager do you wish to use? ['None'| 'Firewalld'| >> 'iptables']: None >> Configure VDSM on this host? ['yes'| 'no'] [yes] : >> Local storage domain path [/var/lib/images_2013_04_19_21_46_58] : >> Confirm root password : >> >> oVirt Engine will be installed using the following configuration: >> ================================================================= >> override-httpd-config: yes >> http-port: 80 >> https-port: 443 >> override-httpd-root: yes >> host-fqdn: engine.startn.com >> auth-pass: ******** >> org-name: startn.com >> application-mode: both >> default-dc-type: NFS >> db-remote-install: local >> db-local-pass: ******** >> nfs-mp: /var/lib/exports/iso_2013_04_19_21_46_58 >> firewall-manager: None >> config-allinone: yes >> storage-path: /var/lib/images_2013_04_19_21_46_58 >> superuser-pass: ******** >> Proceed with the configuration listed above? (yes|no): yes >> >> Installing: >> AIO: Validating CPU Compatibility... [ DONE ] >> AIO: Adding firewall rules... [ DONE ] >> Configuring oVirt Engine... [ DONE ] >> Configuring JVM... [ DONE ] >> Creating CA... [ DONE ] >> Updating ovirt-engine service... [ DONE ] >> Setting Database Configuration... [ DONE ] >> Setting Database Security... [ DONE ] >> Upgrading Database Schema... [ DONE ] >> Editing oVirt Engine Configuration... [ DONE ] >> Editing Postgresql Configuration... [ DONE ] >> Configuring the Default ISO Domain... [ DONE ] >> Configuring Firewall... [ DONE ] >> Starting ovirt-engine Service... [ DONE ] >> Configuring HTTPD... [ DONE ] >> AIO: Creating storage directory... [ DONE ] >> AIO: Adding Local Datacenter and cluster... [ ERROR ] >> Error: could not create ovirtsdk API object >> Please check log file >> /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log for more >> information >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> cat /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = >> 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 >> 2013-04-19 21:48:39::DEBUG::setup_sequences::59::root:: running >> _setupVarPrivileges >> 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command >> --> 'chown -Rh ovirt:ovirt /var/lib/ovirt-engine/deployments' in working >> directory '/root' >> 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = >> 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = >> 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 >> 2013-04-19 21:48:39::DEBUG::setup_sequences::59::root:: running >> _startEngine >> 2013-04-19 21:48:39::DEBUG::engine-setup::1787::root:: using chkconfig to >> enable engine to load on system startup. >> 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command >> --> '/sbin/chkconfig ovirt-engine on' in working directory '/root' >> 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = >> 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = Note: >> Forwarding request to 'systemctl enable ovirt-engine.service'. >> >> 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 >> 2013-04-19 21:48:39::DEBUG::common_utils::1285::root:: stopping >> ovirt-engine >> 2013-04-19 21:48:39::DEBUG::common_utils::1322::root:: executing action >> ovirt-engine on service stop >> 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command >> --> '/sbin/service ovirt-engine stop' in working directory '/root' >> 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = >> 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = >> Redirecting to /bin/systemctl stop ovirt-engine.service >> >> 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 >> 2013-04-19 21:48:39::DEBUG::common_utils::1275::root:: starting >> ovirt-engine >> 2013-04-19 21:48:39::DEBUG::common_utils::1322::root:: executing action >> ovirt-engine on service start >> 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command >> --> '/sbin/service ovirt-engine start' in working directory '/root' >> 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = >> 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = >> Redirecting to /bin/systemctl start ovirt-engine.service >> >> 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 >> 2013-04-19 21:48:39::DEBUG::setup_sequences::59::root:: running >> _configureSelinuxBoolean >> 2013-04-19 21:48:39::DEBUG::engine-setup::742::root:: Enable >> httpd_can_network_connect boolean >> 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command >> --> '/usr/sbin/semanage boolean --modify --on httpd_can_network_connect' in >> working directory '/root' >> 2013-04-19 21:48:52::DEBUG::common_utils::494::root:: output = >> 2013-04-19 21:48:52::DEBUG::common_utils::495::root:: stderr = >> 2013-04-19 21:48:52::DEBUG::common_utils::496::root:: retcode = 0 >> 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running >> _backupOldHttpdConfig >> 2013-04-19 21:48:52::DEBUG::engine-setup::728::root:: Backup old httpd >> configuration files >> 2013-04-19 21:48:52::DEBUG::engine-setup::732::root:: Backing up >> /etc/httpd/conf/httpd.conf into >> /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 >> 2013-04-19 21:48:52::DEBUG::common_utils::729::root:: successfully copied >> file /etc/httpd/conf/httpd.conf to target destination >> /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 >> 2013-04-19 21:48:52::DEBUG::common_utils::737::root:: setting file >> /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 uid/gid ownership >> 2013-04-19 21:48:52::DEBUG::common_utils::740::root:: setting file >> /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 mode to -1 >> 2013-04-19 21:48:52::DEBUG::engine-setup::737::root:: Backing up >> /etc/httpd/conf.d/ssl.conf into >> /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 >> 2013-04-19 21:48:52::DEBUG::common_utils::729::root:: successfully copied >> file /etc/httpd/conf.d/ssl.conf to target destination >> /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 >> 2013-04-19 21:48:52::DEBUG::common_utils::737::root:: setting file >> /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 uid/gid ownership >> 2013-04-19 21:48:52::DEBUG::common_utils::740::root:: setting file >> /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 mode to -1 >> 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running >> _configureHttpdSslKeys >> 2013-04-19 21:48:52::DEBUG::engine-setup::754::root:: Update >> /etc/httpd/conf.d/ssl.conf to use engine private key in mod_ssl directives >> 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running >> _configureHttpdPort >> 2013-04-19 21:48:52::DEBUG::engine-setup::786::root:: Update >> /etc/httpd/conf/httpd.conf to listen in the new HTTP port >> 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running >> _configureHttpdSslPort >> 2013-04-19 21:48:52::DEBUG::engine-setup::798::root:: Update >> /etc/httpd/conf.d/ssl.conf to listen in the new HTTPS port >> 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running >> _redirectUrl >> 2013-04-19 21:48:52::DEBUG::common_utils::84::root:: Processing template >> /usr/share/ovirt-engine/conf/ovirt-engine-proxy.conf.in to >> /etc/httpd/conf.d/z-ovirt-engine-proxy.conf vars {'@JBOSS_AJP_PORT@': >> '8702'} >> 2013-04-19 21:48:52::DEBUG::common_utils::729::root:: successfully copied >> file /usr/share/ovirt-engine/conf/ovirt-engine-root-redirect.conf.in to >> target destination /etc/httpd/conf.d/ovirt-engine-root-redirect.conf >> 2013-04-19 21:48:52::DEBUG::common_utils::737::root:: setting file >> /etc/httpd/conf.d/ovirt-engine-root-redirect.conf uid/gid ownership >> 2013-04-19 21:48:52::DEBUG::common_utils::740::root:: setting file >> /etc/httpd/conf.d/ovirt-engine-root-redirect.conf mode to -1 >> 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running >> _startHttpd >> 2013-04-19 21:48:52::DEBUG::engine-setup::1769::root:: Handling the httpd >> service >> 2013-04-19 21:48:52::DEBUG::common_utils::456::root:: Executing command >> --> '/sbin/chkconfig httpd on' in working directory '/root' >> 2013-04-19 21:48:52::DEBUG::common_utils::494::root:: output = >> 2013-04-19 21:48:52::DEBUG::common_utils::495::root:: stderr = Note: >> Forwarding request to 'systemctl enable httpd.service'. >> >> 2013-04-19 21:48:52::DEBUG::common_utils::496::root:: retcode = 0 >> 2013-04-19 21:48:52::DEBUG::common_utils::1285::root:: stopping httpd >> 2013-04-19 21:48:52::DEBUG::common_utils::1322::root:: executing action >> httpd on service stop >> 2013-04-19 21:48:52::DEBUG::common_utils::456::root:: Executing command >> --> '/sbin/service httpd stop' in working directory '/root' >> 2013-04-19 21:48:52::DEBUG::common_utils::494::root:: output = >> 2013-04-19 21:48:52::DEBUG::common_utils::495::root:: stderr = >> Redirecting to /bin/systemctl stop httpd.service >> >> 2013-04-19 21:48:52::DEBUG::common_utils::496::root:: retcode = 0 >> 2013-04-19 21:48:52::DEBUG::common_utils::1275::root:: starting httpd >> 2013-04-19 21:48:52::DEBUG::common_utils::1322::root:: executing action >> httpd on service start >> 2013-04-19 21:48:52::DEBUG::common_utils::456::root:: Executing command >> --> '/sbin/service httpd start' in working directory '/root' >> 2013-04-19 21:48:54::DEBUG::common_utils::494::root:: output = >> 2013-04-19 21:48:54::DEBUG::common_utils::495::root:: stderr = >> Redirecting to /bin/systemctl start httpd.service >> >> 2013-04-19 21:48:54::DEBUG::common_utils::496::root:: retcode = 0 >> 2013-04-19 21:48:54::DEBUG::setup_sequences::59::root:: running >> makeStorageDir >> 2013-04-19 21:48:54::DEBUG::all_in_one_100::374::root:: >> Creating/Verifying local domain path >> 2013-04-19 21:48:54::DEBUG::all_in_one_100::377::root:: Creating >> directory /var/lib/images_2013_04_19_21_46_58 >> 2013-04-19 21:48:54::DEBUG::all_in_one_100::380::root:: Setting selinux >> context >> 2013-04-19 21:48:54::DEBUG::nfsutils::119::root:: setting selinux context >> for /var/lib/images_2013_04_19_21_46_58 >> 2013-04-19 21:48:54::DEBUG::common_utils::456::root:: Executing command >> --> '/usr/sbin/semanage fcontext -a -t public_content_rw_t >> /var/lib/images_2013_04_19_21_46_58(/.*)?' in working directory '/root' >> 2013-04-19 21:48:55::DEBUG::common_utils::494::root:: output = >> 2013-04-19 21:48:55::DEBUG::common_utils::495::root:: stderr = >> 2013-04-19 21:48:55::DEBUG::common_utils::496::root:: retcode = 0 >> 2013-04-19 21:48:55::DEBUG::common_utils::456::root:: Executing command >> --> '/sbin/restorecon -r /var/lib/images_2013_04_19_21_46_58' in working >> directory '/root' >> 2013-04-19 21:48:55::DEBUG::common_utils::494::root:: output = >> 2013-04-19 21:48:55::DEBUG::common_utils::495::root:: stderr = >> 2013-04-19 21:48:55::DEBUG::common_utils::496::root:: retcode = 0 >> 2013-04-19 21:48:55::DEBUG::setup_sequences::59::root:: running >> waitForJbossUp >> 2013-04-19 21:48:55::DEBUG::all_in_one_100::451::root:: Checking JBoss >> status. >> 2013-04-19 21:48:55::INFO::all_in_one_100::454::root:: JBoss is up and >> running. >> 2013-04-19 21:48:55::DEBUG::setup_sequences::59::root:: running initAPI >> 2013-04-19 21:48:55::DEBUG::all_in_one_100::240::root:: Initiating the >> API object >> 2013-04-19 21:48:56::ERROR::all_in_one_100::251::root:: Traceback (most >> recent call last): >> File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line >> 248, in initAPI >> ca_file=basedefs.FILE_CA_CRT_SRC, >> File "/usr/lib/python2.7/site-packages/ovirtsdk/api.py", line 119, in >> __init__ >> url='/api' >> File >> "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line >> 112, in request >> persistent_auth=self._persistent_auth) >> File >> "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line >> 134, in __doRequest >> persistent_auth=persistent_auth >> File "/usr/lib/python2.7/site-packages/ovirtsdk/web/connection.py", >> line 133, in doRequest >> raise RequestError, response >> RequestError: >> status: 401 >> reason: Unauthorized >> detail: HTTP Status 401 >> >> 2013-04-19 21:48:56::DEBUG::setup_sequences::62::root:: Traceback (most >> recent call last): >> File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, in >> run >> function() >> File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line >> 252, in initAPI >> raise Exception(ERROR_CREATE_API_OBJECT) >> Exception: Error: could not create ovirtsdk API object >> >> 2013-04-19 21:48:56::DEBUG::engine-setup::2064::root:: *** The following >> params were used as user input: >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: >> override-httpd-config: yes >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: http-port: 80 >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: https-port: 443 >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: >> override-httpd-root: yes >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: random-passwords: >> no >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: mac-range: >> 00:1A:4A:A8:C3:00-00:1A:4A:A8:C3:FF >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: host-fqdn: >> engine.startn.com >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: auth-pass: ******** >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: org-name: >> startn.com >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: application-mode: >> both >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: default-dc-type: >> NFS >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: db-remote-install: >> local >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: db-host: localhost >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: db-local-pass: >> ******** >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: nfs-mp: >> /var/lib/exports/iso_2013_04_19_21_46_58 >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: iso-domain-name: >> ISO_DOMAIN >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: config-nfs: yes >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: firewall-manager: >> None >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: config-allinone: >> yes >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: storage-path: >> /var/lib/images_2013_04_19_21_46_58 >> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: superuser-pass: >> ******** >> 2013-04-19 21:48:56::ERROR::engine-setup::2504::root:: Traceback (most >> recent call last): >> File "/usr/bin/engine-setup", line 2498, in >> main(confFile) >> File "/usr/bin/engine-setup", line 2265, in main >> runSequences() >> File "/usr/bin/engine-setup", line 2184, in runSequences >> controller.runAllSequences() >> File "/usr/share/ovirt-engine/scripts/setup_controller.py", line 54, in >> runAllSequences >> sequence.run() >> File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 154, in >> run >> step.run() >> File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, in >> run >> function() >> File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line >> 252, in initAPI >> raise Exception(ERROR_CREATE_API_OBJECT) >> Exception: Error: could not create ovirtsdk API object >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> >> HI?All >> >> ????? >> >> --- >> ??????????? >> ?? >> >> ------------------------------------------------------------------------------ >> >> >> + ????????????????(????1:1) + >> >> ------------------------------------------------------------------------------ >> >> >> 2013/4/20 ?? >> >>> HI?Alon >>> >>> Thank your help, >>> >>> The question: >>> 1,Your email "Close the repository", What does it mean? >>> >>> 2,Your email "Alternatively, you can try out soon to be merged >>> development environment[1][2]" >>> Is it stable? >>> Can be used in a production environment? >>> >>> Thanks again your help, >>> >>> >>> HI?All >>> >>> ????? >>> >>> --- >>> ??????????? >>> ?? >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> + ????????????????(????1:1) + >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> 2013/4/19 Alon Bar-Lev >>> >>>> Please try setup product without tweaks if you don't have real reason >>>> to. >>>> >>>> Close the repository, then: >>>> $ make tarball >>>> $ rpmbuild -t >>>> >>>> Then install the result rpms as usual. >>>> >>>> Alternatively, you can try out soon to be merged development >>>> environment[1][2] >>>> >>>> [1] https://github.com/alonbl/ovirt-engine/tree/otopi >>>> [2] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer >>>> >>>> >>>> ----- Original Message ----- >>>> > From: "??" >>>> > To: engine-devel at ovirt.org >>>> > Sent: Friday, April 19, 2013 6:18:24 PM >>>> > Subject: [Engine-devel] Why deploy failed? Please help me, thanks. >>>> > >>>> > >>>> > HI?All >>>> > >>>> > OS:F18 >>>> > Ovirt engine version: >>>> > the first is 3.2.0 >>>> > update to 3.2.1 >>>> > and now I compile the source to other language. >>>> > MEM:8G >>>> > CPU:I7 >>>> > DISK:60G >>>> > >>>> > >>>> > I will use chinese language for ovirt engine, >>>> > but rpm have not chinese language for default install. >>>> > >>>> > So I git clone source, that I compile the source success. >>>> > From link: >>>> > http://www.ovirt.org/Building_oVirt_engine >>>> > >>>> > COMPILE COMMAND >>>> > mvn clean install -Pdep,gwt-admin,gwt-user,all-langs >>>> > and show message: >>>> > ------------------------ >>>> > >>>> > ------------------------ >>>> > >>>> > I deploy: >>>> > DEPLOY COMMAND: >>>> > cd ear && mvn clean install -Pdep >>>> > >>>> > QUESTION: >>>> > 1, >>>> > I open the first page that it show >>>> > ------------------ >>>> > Welcome to Open Virtualization Manager. >>>> > Version 3.2.1- >>>> > ------------------ >>>> > Source shoule be 3.3.0? >>>> > If souce version 3.3.0,then I deploy is not invalid. >>>> > >>>> > 2, >>>> > Change language is failed and is still englist. >>>> > Other language is invalid. >>>> > COMMAND DEPLOY: >>>> > ++++++++++++++++++++++ >>>> > [liqiang at engine ear]$ mvn clean install -Pdep >>>> > [INFO] Scanning for projects... >>>> > [WARNING] >>>> > [WARNING] Some problems were encountered while building the effective >>>> model >>>> > for org.ovirt.engine:engine-server-ear:ear:3.3.0-SNAPSHOT >>>> > [WARNING] ' distributionManagement.repository.id ' must not be >>>> 'local', this >>>> > identifier is reserved for the local repository, using it for other >>>> > repositories will corrupt your repository metadata. @ line 18, column >>>> 11 >>>> > [WARNING] >>>> > [WARNING] It is highly recommended to fix these problems because they >>>> > threaten the stability of your build. >>>> > [WARNING] >>>> > [WARNING] For this reason, future Maven versions might no longer >>>> support >>>> > building such malformed projects. >>>> > [WARNING] >>>> > [INFO] >>>> > [INFO] >>>> > >>>> ------------------------------------------------------------------------ >>>> > [INFO] Building oVirt Server EAR 3.3.0-SNAPSHOT >>>> > [INFO] >>>> > >>>> ------------------------------------------------------------------------ >>>> > [INFO] >>>> > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ >>>> engine-server-ear >>>> > --- >>>> > [INFO] Deleting /home/liqiang/ovirt-engine/ear/target >>>> > [INFO] >>>> > [INFO] --- maven-antrun-plugin:1.7:run (undeploy-ear) @ >>>> engine-server-ear --- >>>> > [WARNING] Parameter tasks is deprecated, use target instead >>>> > [INFO] Executing tasks >>>> > >>>> > main: >>>> > [echo] *** Deleting >>>> /usr/share/jboss-as/standalone/deployments/engine.ear/... >>>> > [delete] Deleting directory >>>> > /usr/share/jboss-as/standalone/deployments/engine.ear >>>> > [INFO] Executed tasks >>>> > [INFO] >>>> > [INFO] --- maven-ear-plugin:2.8:generate-application-xml >>>> > (default-generate-application-xml) @ engine-server-ear --- >>>> > [INFO] Generating application.xml >>>> > [INFO] >>>> > [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) >>>> @ >>>> > engine-server-ear --- >>>> > [INFO] Using 'UTF-8' encoding to copy filtered resources. >>>> > [INFO] skip non existing resourceDirectory >>>> > /home/liqiang/ovirt-engine/ear/src/main/java >>>> > [INFO] Copying 1 resource >>>> > [INFO] >>>> > [INFO] --- maven-ear-plugin:2.8:ear (default-ear) @ engine-server-ear >>>> --- >>>> > [INFO] Copying artifact >>>> [war:org.ovirt.engine.core:root-war:3.3.0-SNAPSHOT] >>>> > to [root.war] (unpacked) >>>> > [INFO] Copying artifact >>>> > [war:org.ovirt.engine.api:restapi-webapp:3.3.0-SNAPSHOT] to >>>> [restapi.war] >>>> > (unpacked) >>>> > [INFO] Copying artifact >>>> [war:org.ovirt.engine.ui:userportal:3.3.0-SNAPSHOT] >>>> > to [userportal.war] (unpacked) >>>> > [INFO] Copying artifact >>>> [war:org.ovirt.engine.ui:webadmin:3.3.0-SNAPSHOT] to >>>> > [webadmin.war] (unpacked) >>>> > [INFO] Copying artifact >>>> [ejb:org.ovirt.engine.core:scheduler:3.3.0-SNAPSHOT] >>>> > to [scheduler.jar] >>>> > [INFO] Copying artifact >>>> [ejb:org.ovirt.engine.core:bll:3.3.0-SNAPSHOT] to >>>> > [bll.jar] >>>> > [INFO] Copying artifact >>>> [jar:org.ovirt.engine.core:vdsbroker:3.3.0-SNAPSHOT] >>>> > to [lib/vdsbroker.jar] >>>> > [INFO] Copying artifact >>>> [jar:org.ovirt.engine.core:compat:3.3.0-SNAPSHOT] to >>>> > [lib/compat.jar] >>>> > [INFO] Copying artifact >>>> [jar:org.ovirt.engine.core:common:3.3.0-SNAPSHOT] to >>>> > [lib/common.jar] >>>> > [INFO] Copying artifact [jar:org.hibernate:hibernate-validator: >>>> 4.0.2.GA ] to >>>> > [lib/hibernate-validator.jar] >>>> > [INFO] Copying artifact [jar:javax.validation:validation-api: >>>> 1.0.0.GA ] to >>>> > [lib/validation-api.jar] >>>> > [INFO] Copying artifact [jar:javax.xml.bind:jaxb-api:2.1] to >>>> > [lib/jaxb-api.jar] >>>> > [INFO] Copying artifact [jar:javax.xml.stream:stax-api:1.0-2] to >>>> > [lib/stax-api.jar] >>>> > [INFO] Copying artifact [jar:com.sun.xml.bind:jaxb-impl:2.1.3] to >>>> > [lib/jaxb-impl.jar] >>>> > [INFO] Copying artifact >>>> [jar:org.ovirt.engine.core:utils:3.3.0-SNAPSHOT] to >>>> > [lib/utils.jar] >>>> > [INFO] Copying artifact >>>> [jar:commons-beanutils:commons-beanutils:1.8.2] to >>>> > [lib/commons-beanutils.jar] >>>> > [INFO] Copying artifact [jar:org.apache.mina:mina-core:2.0.1] to >>>> > [lib/mina-core.jar] >>>> > [INFO] Copying artifact [jar:org.apache.sshd:sshd-core:0.7.0] to >>>> > [lib/sshd-core.jar] >>>> > [INFO] Copying artifact [jar:org.ovirt.otopi:otopi:1.0.0] to >>>> [lib/otopi.jar] >>>> > [INFO] Copying artifact >>>> > [jar:org.ovirt.ovirt-host-deploy:ovirt-host-deploy:1.0.0] to >>>> > [lib/ovirt-host-deploy.jar] >>>> > [INFO] Copying artifact >>>> [jar:org.apache.commons:commons-compress:1.4.1] to >>>> > [lib/commons-compress.jar] >>>> > [INFO] Copying artifact [jar:org.tukaani:xz:1.0] to [lib/xz.jar] >>>> > [INFO] Copying artifact [jar:commons-lang:commons-lang:2.6] to >>>> > [lib/commons-lang.jar] >>>> > [INFO] Copying artifact [jar:commons-codec:commons-codec:1.4] to >>>> > [lib/commons-codec.jar] >>>> > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] to >>>> > [lib/xmlrpc-client.jar] >>>> > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] to >>>> > [lib/xmlrpc-common.jar] >>>> > [INFO] Copying artifact >>>> > [jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to >>>> > [lib/ws-commons-util.jar] >>>> > [INFO] Copying artifact [jar:xml-apis:xml-apis:1.0.b2] to >>>> [lib/xml-apis.jar] >>>> > [INFO] Copying artifact >>>> [jar:org.ovirt.engine.core:dal:3.3.0-SNAPSHOT] to >>>> > [lib/dal.jar] >>>> > [INFO] Copying artifact >>>> [jar:org.springframework:spring-jdbc:3.1.1.RELEASE] >>>> > to [lib/spring-jdbc.jar] >>>> > [INFO] Copying artifact >>>> [jar:org.springframework:spring-tx:3.1.1.RELEASE] to >>>> > [lib/spring-tx.jar] >>>> > [INFO] Copying artifact >>>> > [jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to >>>> > [lib/spring-ldap-core.jar] >>>> > [INFO] Copying artifact >>>> [jar:commons-httpclient:commons-httpclient:3.1] to >>>> > [lib/commons-httpclient.jar] >>>> > [INFO] Copying artifact >>>> [jar:commons-collections:commons-collections:3.1] to >>>> > [lib/commons-collections.jar] >>>> > [INFO] Copying artifact [jar:org.quartz-scheduler:quartz:2.1.2] to >>>> > [lib/quartz.jar] >>>> > [INFO] Copying artifact [jar:c3p0:c3p0:0.9.1.1] to [lib/c3p0.jar] >>>> > [INFO] Copying artifact [jar:org.slf4j:slf4j-api:1.6.1] to >>>> > [lib/slf4j-api.jar] >>>> > [INFO] Copying artifact >>>> > [jar:org.ovirt.engine.core:searchbackend:3.3.0-SNAPSHOT] to >>>> > [lib/searchbackend.jar] >>>> > [INFO] Copying artifact >>>> > >>>> [jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] >>>> > to [lib/jboss-interceptors-api_1.1_spec.jar] >>>> > [INFO] Copying artifact >>>> [jar:org.springframework:spring-core:3.1.1.RELEASE] >>>> > to [lib/spring-core.jar] >>>> > [INFO] Copying artifact >>>> [jar:org.springframework:spring-asm:3.1.1.RELEASE] to >>>> > [lib/spring-asm.jar] >>>> > [INFO] Copying artifact >>>> [jar:org.springframework:spring-beans:3.1.1.RELEASE] >>>> > to [lib/spring-beans.jar] >>>> > [INFO] Copying artifact >>>> > [jar:org.springframework:spring-context:3.1.1.RELEASE] to >>>> > [lib/spring-context.jar] >>>> > [INFO] Copying artifact >>>> [jar:org.springframework:spring-aop:3.1.1.RELEASE] to >>>> > [lib/spring-aop.jar] >>>> > [INFO] Copying artifact [jar:aopalliance:aopalliance:1.0] to >>>> > [lib/aopalliance.jar] >>>> > [INFO] Copying artifact >>>> > [jar:org.springframework:spring-expression:3.1.1.RELEASE] to >>>> > [lib/spring-expression.jar] >>>> > [INFO] Copy ear sources to >>>> /home/liqiang/ovirt-engine/ear/target/engine >>>> > [INFO] Could not find manifest file: >>>> > /home/liqiang/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF - >>>> > Generating one >>>> > [INFO] Building jar: /home/liqiang/ovirt-engine/ear/target/engine.ear >>>> > [INFO] >>>> > [INFO] --- maven-dependency-plugin:2.1:unpack (deploy-modules) @ >>>> > engine-server-ear --- >>>> > [INFO] Configured Artifact: >>>> > org.ovirt.engine.core:dependencies:modules:3.3.0-SNAPSHOT:zip >>>> > [INFO] Configured Artifact: >>>> > org.ovirt.engine.core:common:modules:3.3.0-SNAPSHOT:zip >>>> > [INFO] Configured Artifact: >>>> > org.ovirt.engine.core:compat:modules:3.3.0-SNAPSHOT:zip >>>> > [INFO] Configured Artifact: >>>> > org.ovirt.engine.core:dal:modules:3.3.0-SNAPSHOT:zip >>>> > [INFO] Configured Artifact: >>>> > org.ovirt.engine.core:searchbackend:modules:3.3.0-SNAPSHOT:zip >>>> > [INFO] Configured Artifact: >>>> > org.ovirt.engine.core:tools:modules:3.3.0-SNAPSHOT:zip >>>> > [INFO] Configured Artifact: >>>> > org.ovirt.engine.core:utils:modules:3.3.0-SNAPSHOT:zip >>>> > [INFO] Unpacking >>>> > >>>> /home/liqiang/.m2/repository/org/ovirt/engine/core/dependencies/3.3.0-SNAPSHOT/dependencies-3.3.0-SNAPSHOT-modules.zip >>>> > to >>>> > /usr/share/jboss-as/modules >>>> > with includes null and excludes:null >>>> > [WARNING] Unable to expand to file >>>> > >>>> /usr/share/jboss-as/modules/org/apache/commons/configuration/main/module.xml >>>> > [WARNING] Unable to expand to file >>>> > /usr/share/java/apache-commons-configuration.jar >>>> > [INFO] Unpacking >>>> > >>>> /home/liqiang/.m2/repository/org/ovirt/engine/core/common/3.3.0-SNAPSHOT/common-3.3.0-SNAPSHOT-modules.zip >>>> > to >>>> > /usr/share/jboss-as/modules >>>> > with includes null and excludes:null >>>> > [INFO] Unpacking >>>> > >>>> /home/liqiang/.m2/repository/org/ovirt/engine/core/compat/3.3.0-SNAPSHOT/compat-3.3.0-SNAPSHOT-modules.zip >>>> > to >>>> > /usr/share/jboss-as/modules >>>> > with includes null and excludes:null >>>> > [INFO] Unpacking >>>> > >>>> /home/liqiang/.m2/repository/org/ovirt/engine/core/dal/3.3.0-SNAPSHOT/dal-3.3.0-SNAPSHOT-modules.zip >>>> > to >>>> > /usr/share/jboss-as/modules >>>> > with includes null and excludes:null >>>> > [INFO] Unpacking >>>> > >>>> /home/liqiang/.m2/repository/org/ovirt/engine/core/searchbackend/3.3.0-SNAPSHOT/searchbackend-3.3.0-SNAPSHOT-modules.zip >>>> > to >>>> > /usr/share/jboss-as/modules >>>> > with includes null and excludes:null >>>> > [INFO] Unpacking >>>> > >>>> /home/liqiang/.m2/repository/org/ovirt/engine/core/tools/3.3.0-SNAPSHOT/tools-3.3.0-SNAPSHOT-modules.zip >>>> > to >>>> > /usr/share/jboss-as/modules >>>> > with includes null and excludes:null >>>> > [INFO] Unpacking >>>> > >>>> /home/liqiang/.m2/repository/org/ovirt/engine/core/utils/3.3.0-SNAPSHOT/utils-3.3.0-SNAPSHOT-modules.zip >>>> > to >>>> > /usr/share/jboss-as/modules >>>> > with includes null and excludes:null >>>> > [INFO] >>>> > [INFO] --- maven-antrun-plugin:1.7:run (deploy-ear) @ >>>> engine-server-ear --- >>>> > [WARNING] Parameter tasks is deprecated, use target instead >>>> > [INFO] Executing tasks >>>> > >>>> > main: >>>> > [echo] *** Copying updated files to >>>> > /usr/share/jboss-as/standalone/deployments/engine.ear/... >>>> > [unjar] Expanding: /home/liqiang/ovirt-engine/ear/target/engine.ear >>>> into >>>> > /usr/share/jboss-as/standalone/deployments/engine.ear >>>> > [echo] *** Touching >>>> > >>>> /usr/share/jboss-as/standalone/deployments/engine.ear/META-INF/application.xml >>>> > to force redeployment of engine.ear... >>>> > [echo] *** Touching engine.ear.dodeploy to force deployment of >>>> engine.ear... >>>> > [INFO] Executed tasks >>>> > [INFO] >>>> > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ >>>> > engine-server-ear --- >>>> > [INFO] Installing /home/liqiang/ovirt-engine/ear/target/engine.ear to >>>> > >>>> /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear >>>> > [INFO] Installing /home/liqiang/ovirt-engine/ear/pom.xml to >>>> > >>>> /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom >>>> > [INFO] >>>> > >>>> ------------------------------------------------------------------------ >>>> > [INFO] BUILD SUCCESS >>>> > [INFO] >>>> > >>>> ------------------------------------------------------------------------ >>>> > [INFO] Total time: 54.354s >>>> > [INFO] Finished at: Fri Apr 19 10:48:39 EDT 2013 >>>> > [INFO] Final Memory: 14M/191M >>>> > [INFO] >>>> > >>>> ------------------------------------------------------------------------ >>>> > ++++++++++++++++++++++ >>>> > >>>> > >>>> > engine-upgrade >>>> > COMMAND MESSAGE: >>>> > ------------------------------------ >>>> > [root at engine ~]# engine-upgrade >>>> > >>>> > Checking for updates... (This may take several minutes)...[ DONE ] >>>> > 8 Updates available: >>>> > * ovirt-engine-3.2.1-1.fc18.noarch >>>> > * ovirt-engine-tools-3.2.1-1.fc18.noarch >>>> > * ovirt-engine-backend-3.2.1-1.fc18.noarch >>>> > * ovirt-engine-dbscripts-3.2.1-1.fc18.noarch >>>> > * ovirt-engine-genericapi-3.2.1-1.fc18.noarch >>>> > * ovirt-engine-restapi-3.2.1-1.fc18.noarch >>>> > * ovirt-engine-userportal-3.2.1-1.fc18.noarch >>>> > * ovirt-engine-webadmin-portal-3.2.1-1.fc18.noarch >>>> > >>>> > During the upgrade process, oVirt Engine will not be accessible. >>>> > All existing running virtual machines will continue but you will not >>>> be able >>>> > to >>>> > start or stop any new virtual machines during the process. >>>> > >>>> > Would you like to proceed? (yes|no): yes >>>> > Stopping ovirt-engine service... [ DONE ] >>>> > Stopping DB related services... [ DONE ] >>>> > Pre-upgrade validations... [ DONE ] >>>> > Backing Up Database... [ DONE ] >>>> > Rename Database... [ DONE ] >>>> > Updating rpms... [ DONE ] >>>> > Updating Database... [ DONE ] >>>> > Restore Database name... [ DONE ] >>>> > Preparing CA... [ DONE ] >>>> > Running post install configuration... [ DONE ] >>>> > Starting ovirt-engine service... [ DONE ] >>>> > >>>> > oVirt Engine upgrade completed successfully! >>>> > >>>> > * Upgrade log available at >>>> > /var/log/ovirt-engine/ovirt-engine-upgrade_2013_04_19_10_39_54.log >>>> > * DB Backup available at >>>> > >>>> /var/lib/ovirt-engine/backups/ovirt-engine_db_backup_2013_04_19_10_39_54.sql >>>> > ------------------------------------ >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > 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: From iheim at redhat.com Sat Apr 20 13:31:14 2013 From: iheim at redhat.com (Itamar Heim) Date: Sat, 20 Apr 2013 16:31:14 +0300 Subject: [Engine-devel] Why deploy failed? Please help me, thanks. In-Reply-To: References: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> Message-ID: <517298A2.9080103@redhat.com> On 04/20/2013 05:10 AM, ?? wrote: > I have ERROR and Please help me ,thanks sounds similar to: Bug 918742 - Ovirt 3.2 all in one problem install in Fedora 18 to workaround and just get the engine installed (without the all-in-one first), please reply 'no' to the this question: Configure VDSM on this host? ['yes'| 'no'] [yes] then please try to collaborate with sandro on the bug to resolve the issue. thanks, Itamar > > The first Upgrade is SUCCESS. > Please look the info. > > But engine-set is ERROR. > AIO: Adding Local Datacenter and cluster... [ ERROR ] > Error: could not create ovirtsdk API object > Please check log file > /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log for more > information > > > ========================================================== > [root at engine noarch]# rpm -Uvh *.rpm > Preparing... ################################# > [100%] > Updating / installing... > 1:ovirt-engine-sdk-3.3.0.1-1.201304################################# > [ 3%] > 2:ovirt-image-uploader-3.3.0-0.0.ma################################# > > [ 7%] > 3:ovirt-iso-uploader-3.3.0-0.0.mast################################# > [ 10%] > 4:ovirt-log-collector-3.3.0-0.0.mas################################# > [ 14%] > 5:ovirt-engine-backend-3.3.0-0.2.ma################################# > > [ 17%] > 6:ovirt-engine-dbscripts-3.3.0-0.2.################################# > [ 21%] > 7:ovirt-engine-restapi-3.3.0-0.2.ma################################# > > [ 24%] > 8:ovirt-engine-setup-3.3.0-0.2.mastwarning: > /etc/firewalld/services/ovirt.xml created as > /etc/firewalld/services/ovirt.xml.rpmnew > ################################# [ 28%] > 9:ovirt-engine-tools-3.3.0-0.2.mast################################# > [ 31%] > 10:ovirt-engine-userportal-3.3.0-0.2################################# > [ 34%] > 11:ovirt-engine-webadmin-portal-3.3.################################# > [ 38%] > 12:ovirt-engine-3.3.0-0.2.master.201################################# > [ 41%] > 13:ovirt-host-deploy-offline-1.1.0-0################################# > [ 45%] > 14:ovirt-engine-setup-plugin-allinon################################# > [ 48%] > Cleaning up / removing... > 15:ovirt-engine-backend-3.2.0-4.fc18################################# > [ 52%] > 16:ovirt-engine-config-3.2.0-4.fc18 ################################# > [ 55%] > 17:ovirt-engine-dbscripts-3.2.0-4.fc################################# > [ 59%] > 18:ovirt-engine-genericapi-3.2.0-4.f################################# > [ 62%] > 19:ovirt-engine-tools-common-3.2.0-4################################# > [ 66%] > 20:ovirt-engine-notification-service################################# > [ 69%] > 21:ovirt-engine-restapi-3.2.0-4.fc18################################# > [ 72%] > 22:ovirt-engine-setup-3.2.0-4.fc18 ################################# > [ 76%] > 23:ovirt-engine-userportal-3.2.0-4.f################################# > [ 79%] > 24:ovirt-engine-webadmin-portal-3.2.################################# > [ 83%] > 25:ovirt-engine-3.2.0-4.fc18 warning: > /etc/sysconfig/ovirt-engine saved as /etc/sysconfig/ovirt-engine.rpmsave > ################################# [ 86%] > 26:ovirt-image-uploader-3.2.0-1.fc18################################# > [ 90%] > 27:ovirt-iso-uploader-3.2.0-1.fc18 ################################# > [ 93%] > 28:ovirt-log-collector-3.2.0-1.fc18 ################################# > [ 97%] > 29:ovirt-engine-sdk-3.2.0.9-1.fc18 ################################# > [100%] > ========================================================== > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > [root at engine ~]# engine-setup > Welcome to oVirt Engine setup utility > > WARNING: oVirt Engine setup has already been run on this host. > To remove all configuration and reset oVirt Engine please run > engine-cleanup. > Please be advised that executing engine-setup without cleanup is not > supported. > Would you like to proceed? (yes|no): yes > > In order to proceed the installer must stop the ovirt-engine service > Would you like to stop the ovirt-engine service? (yes|no): yes > oVirt Engine uses httpd to proxy requests to the application server. > It looks like the httpd installed locally is being actively used. > The installer can override current configuration . > Alternatively you can use JBoss directly (on ports higher than 1024) > Do you wish to override current httpd configuration and restart the > service? ['yes'| 'no'] [yes] : > HTTP Port [80] : > HTTPS Port [443] : > Setup can configure server default page to launch oVirt Engine. Do you > wish to do so? ['yes'| 'no'] [yes] : > Host fully qualified domain name. Note: this name should be fully > resolvable [engine.startn.com ] : > The IP 192.168.11.12 does not hold a PTR record for the FQDN: > engine.startn.com > User input failed validation, do you still wish to use it? (yes|no): yes > Enter a password for an internal oVirt Engine administrator user > (admin at internal) : > Warning: Weak Password. > Confirm password : > Organization Name for the Certificate [startn.com ] : > The engine can be configured to present the UI in three different > application modes. virt [Manage virtualization only], gluster [Manage > gluster storage only], and both [Manage virtualization as well as > gluster storage] ['virt'| 'gluster'| 'both'] [both] : > The default storage type you will be using ['NFS'| 'FC'| 'ISCSI'| > 'POSIXFS'] [NFS] : > Enter DB type for installation ['remote'| 'local'] [local] : > Enter a password for a local oVirt Engine DB admin user (engine) : > Warning: Weak Password. > Confirm password : > Local ISO domain path [/var/lib/exports/iso_2013_04_19_21_46_58] : > Firewall ports need to be opened. > The installer can configure firewall automatically overriding the > current configuration. The old configuration will be backed up. > Alternately you can configure the firewall later using an example file > selecting None. > Which firewall manager do you wish to use? ['None'| 'Firewalld'| > 'iptables']: None > Configure VDSM on this host? ['yes'| 'no'] [yes] : > Local storage domain path [/var/lib/images_2013_04_19_21_46_58] : > Confirm root password : > > oVirt Engine will be installed using the following configuration: > ================================================================= > override-httpd-config: yes > http-port: 80 > https-port: 443 > override-httpd-root: yes > host-fqdn: engine.startn.com > auth-pass: ******** > org-name: startn.com > application-mode: both > default-dc-type: NFS > db-remote-install: local > db-local-pass: ******** > nfs-mp: /var/lib/exports/iso_2013_04_19_21_46_58 > firewall-manager: None > config-allinone: yes > storage-path: /var/lib/images_2013_04_19_21_46_58 > superuser-pass: ******** > Proceed with the configuration listed above? (yes|no): yes > > Installing: > AIO: Validating CPU Compatibility... [ DONE ] > AIO: Adding firewall rules... [ DONE ] > Configuring oVirt Engine... [ DONE ] > Configuring JVM... [ DONE ] > Creating CA... [ DONE ] > Updating ovirt-engine service... [ DONE ] > Setting Database Configuration... [ DONE ] > Setting Database Security... [ DONE ] > Upgrading Database Schema... [ DONE ] > Editing oVirt Engine Configuration... [ DONE ] > Editing Postgresql Configuration... [ DONE ] > Configuring the Default ISO Domain... [ DONE ] > Configuring Firewall... [ DONE ] > Starting ovirt-engine Service... [ DONE ] > Configuring HTTPD... [ DONE ] > AIO: Creating storage directory... [ DONE ] > AIO: Adding Local Datacenter and cluster... [ ERROR ] > Error: could not create ovirtsdk API object > Please check log file > /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log for more > information > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > cat /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = > 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:39::DEBUG::setup_sequences::59::root:: running > _setupVarPrivileges > 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command > --> 'chown -Rh ovirt:ovirt /var/lib/ovirt-engine/deployments' in working > directory '/root' > 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = > 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:39::DEBUG::setup_sequences::59::root:: running _startEngine > 2013-04-19 21:48:39::DEBUG::engine-setup::1787::root:: using chkconfig > to enable engine to load on system startup. > 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command > --> '/sbin/chkconfig ovirt-engine on' in working directory '/root' > 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = Note: > Forwarding request to 'systemctl enable ovirt-engine.service'. > > 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:39::DEBUG::common_utils::1285::root:: stopping ovirt-engine > 2013-04-19 21:48:39::DEBUG::common_utils::1322::root:: executing action > ovirt-engine on service stop > 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command > --> '/sbin/service ovirt-engine stop' in working directory '/root' > 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = > Redirecting to /bin/systemctl stop ovirt-engine.service > > 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:39::DEBUG::common_utils::1275::root:: starting ovirt-engine > 2013-04-19 21:48:39::DEBUG::common_utils::1322::root:: executing action > ovirt-engine on service start > 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command > --> '/sbin/service ovirt-engine start' in working directory '/root' > 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = > Redirecting to /bin/systemctl start ovirt-engine.service > > 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:39::DEBUG::setup_sequences::59::root:: running > _configureSelinuxBoolean > 2013-04-19 21:48:39::DEBUG::engine-setup::742::root:: Enable > httpd_can_network_connect boolean > 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command > --> '/usr/sbin/semanage boolean --modify --on httpd_can_network_connect' > in working directory '/root' > 2013-04-19 21:48:52::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:52::DEBUG::common_utils::495::root:: stderr = > 2013-04-19 21:48:52::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running > _backupOldHttpdConfig > 2013-04-19 21:48:52::DEBUG::engine-setup::728::root:: Backup old httpd > configuration files > 2013-04-19 21:48:52::DEBUG::engine-setup::732::root:: Backing up > /etc/httpd/conf/httpd.conf into > /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 > 2013-04-19 21:48:52::DEBUG::common_utils::729::root:: successfully > copied file /etc/httpd/conf/httpd.conf to target destination > /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 > 2013-04-19 21:48:52::DEBUG::common_utils::737::root:: setting file > /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 uid/gid ownership > 2013-04-19 21:48:52::DEBUG::common_utils::740::root:: setting file > /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 mode to -1 > 2013-04-19 21:48:52::DEBUG::engine-setup::737::root:: Backing up > /etc/httpd/conf.d/ssl.conf into > /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 > 2013-04-19 21:48:52::DEBUG::common_utils::729::root:: successfully > copied file /etc/httpd/conf.d/ssl.conf to target destination > /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 > 2013-04-19 21:48:52::DEBUG::common_utils::737::root:: setting file > /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 uid/gid ownership > 2013-04-19 21:48:52::DEBUG::common_utils::740::root:: setting file > /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 mode to -1 > 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running > _configureHttpdSslKeys > 2013-04-19 21:48:52::DEBUG::engine-setup::754::root:: Update > /etc/httpd/conf.d/ssl.conf to use engine private key in mod_ssl directives > 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running > _configureHttpdPort > 2013-04-19 21:48:52::DEBUG::engine-setup::786::root:: Update > /etc/httpd/conf/httpd.conf to listen in the new HTTP port > 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running > _configureHttpdSslPort > 2013-04-19 21:48:52::DEBUG::engine-setup::798::root:: Update > /etc/httpd/conf.d/ssl.conf to listen in the new HTTPS port > 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running _redirectUrl > 2013-04-19 21:48:52::DEBUG::common_utils::84::root:: Processing template > /usr/share/ovirt-engine/conf/ovirt-engine-proxy.conf.in > to > /etc/httpd/conf.d/z-ovirt-engine-proxy.conf vars {'@JBOSS_AJP_PORT@': > '8702'} > 2013-04-19 21:48:52::DEBUG::common_utils::729::root:: successfully > copied file > /usr/share/ovirt-engine/conf/ovirt-engine-root-redirect.conf.in > to target destination > /etc/httpd/conf.d/ovirt-engine-root-redirect.conf > 2013-04-19 21:48:52::DEBUG::common_utils::737::root:: setting file > /etc/httpd/conf.d/ovirt-engine-root-redirect.conf uid/gid ownership > 2013-04-19 21:48:52::DEBUG::common_utils::740::root:: setting file > /etc/httpd/conf.d/ovirt-engine-root-redirect.conf mode to -1 > 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running _startHttpd > 2013-04-19 21:48:52::DEBUG::engine-setup::1769::root:: Handling the > httpd service > 2013-04-19 21:48:52::DEBUG::common_utils::456::root:: Executing command > --> '/sbin/chkconfig httpd on' in working directory '/root' > 2013-04-19 21:48:52::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:52::DEBUG::common_utils::495::root:: stderr = Note: > Forwarding request to 'systemctl enable httpd.service'. > > 2013-04-19 21:48:52::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:52::DEBUG::common_utils::1285::root:: stopping httpd > 2013-04-19 21:48:52::DEBUG::common_utils::1322::root:: executing action > httpd on service stop > 2013-04-19 21:48:52::DEBUG::common_utils::456::root:: Executing command > --> '/sbin/service httpd stop' in working directory '/root' > 2013-04-19 21:48:52::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:52::DEBUG::common_utils::495::root:: stderr = > Redirecting to /bin/systemctl stop httpd.service > > 2013-04-19 21:48:52::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:52::DEBUG::common_utils::1275::root:: starting httpd > 2013-04-19 21:48:52::DEBUG::common_utils::1322::root:: executing action > httpd on service start > 2013-04-19 21:48:52::DEBUG::common_utils::456::root:: Executing command > --> '/sbin/service httpd start' in working directory '/root' > 2013-04-19 21:48:54::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:54::DEBUG::common_utils::495::root:: stderr = > Redirecting to /bin/systemctl start httpd.service > > 2013-04-19 21:48:54::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:54::DEBUG::setup_sequences::59::root:: running > makeStorageDir > 2013-04-19 21:48:54::DEBUG::all_in_one_100::374::root:: > Creating/Verifying local domain path > 2013-04-19 21:48:54::DEBUG::all_in_one_100::377::root:: Creating > directory /var/lib/images_2013_04_19_21_46_58 > 2013-04-19 21:48:54::DEBUG::all_in_one_100::380::root:: Setting selinux > context > 2013-04-19 21:48:54::DEBUG::nfsutils::119::root:: setting selinux > context for /var/lib/images_2013_04_19_21_46_58 > 2013-04-19 21:48:54::DEBUG::common_utils::456::root:: Executing command > --> '/usr/sbin/semanage fcontext -a -t public_content_rw_t > /var/lib/images_2013_04_19_21_46_58(/.*)?' in working directory '/root' > 2013-04-19 21:48:55::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:55::DEBUG::common_utils::495::root:: stderr = > 2013-04-19 21:48:55::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:55::DEBUG::common_utils::456::root:: Executing command > --> '/sbin/restorecon -r /var/lib/images_2013_04_19_21_46_58' in working > directory '/root' > 2013-04-19 21:48:55::DEBUG::common_utils::494::root:: output = > 2013-04-19 21:48:55::DEBUG::common_utils::495::root:: stderr = > 2013-04-19 21:48:55::DEBUG::common_utils::496::root:: retcode = 0 > 2013-04-19 21:48:55::DEBUG::setup_sequences::59::root:: running > waitForJbossUp > 2013-04-19 21:48:55::DEBUG::all_in_one_100::451::root:: Checking JBoss > status. > 2013-04-19 21:48:55::INFO::all_in_one_100::454::root:: JBoss is up and > running. > 2013-04-19 21:48:55::DEBUG::setup_sequences::59::root:: running initAPI > 2013-04-19 21:48:55::DEBUG::all_in_one_100::240::root:: Initiating the > API object > 2013-04-19 21:48:56::ERROR::all_in_one_100::251::root:: Traceback (most > recent call last): > File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", > line 248, in initAPI > ca_file=basedefs.FILE_CA_CRT_SRC, > File "/usr/lib/python2.7/site-packages/ovirtsdk/api.py", line 119, in > __init__ > url='/api' > File > "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", > line 112, in request > persistent_auth=self._persistent_auth) > File > "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", > line 134, in __doRequest > persistent_auth=persistent_auth > File "/usr/lib/python2.7/site-packages/ovirtsdk/web/connection.py", > line 133, in doRequest > raise RequestError, response > RequestError: > status: 401 > reason: Unauthorized > detail: HTTP Status 401 > > 2013-04-19 21:48:56::DEBUG::setup_sequences::62::root:: Traceback (most > recent call last): > File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, > in run > function() > File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", > line 252, in initAPI > raise Exception(ERROR_CREATE_API_OBJECT) > Exception: Error: could not create ovirtsdk API object > > 2013-04-19 21:48:56::DEBUG::engine-setup::2064::root:: *** The following > params were used as user input: > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: > override-httpd-config: yes > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: http-port: 80 > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: https-port: 443 > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: > override-httpd-root: yes > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: random-passwords: no > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: mac-range: > 00:1A:4A:A8:C3:00-00:1A:4A:A8:C3:FF > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: host-fqdn: > engine.startn.com > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: auth-pass: ******** > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: org-name: > startn.com > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: application-mode: > both > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: default-dc-type: NFS > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: > db-remote-install: local > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: db-host: localhost > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: db-local-pass: > ******** > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: nfs-mp: > /var/lib/exports/iso_2013_04_19_21_46_58 > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: iso-domain-name: > ISO_DOMAIN > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: config-nfs: yes > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: firewall-manager: > None > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: config-allinone: yes > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: storage-path: > /var/lib/images_2013_04_19_21_46_58 > 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: superuser-pass: > ******** > 2013-04-19 21:48:56::ERROR::engine-setup::2504::root:: Traceback (most > recent call last): > File "/usr/bin/engine-setup", line 2498, in > main(confFile) > File "/usr/bin/engine-setup", line 2265, in main > runSequences() > File "/usr/bin/engine-setup", line 2184, in runSequences > controller.runAllSequences() > File "/usr/share/ovirt-engine/scripts/setup_controller.py", line 54, > in runAllSequences > sequence.run() > File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 154, > in run > step.run() > File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, > in run > function() > File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", > line 252, in initAPI > raise Exception(ERROR_CREATE_API_OBJECT) > Exception: Error: could not create ovirtsdk API object > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > HI?All > > ????? > > --- > ??????????? > ?? > > ------------------------------------------------------------------------------ > > > + ????????????????(????1:1) + > ------------------------------------------------------------------------------ > > > 2013/4/20 ?? > > > HI?Alon > > Thank your help, > > The question: > 1,Your email "Close the repository", What does it mean? > > 2,Your email "Alternatively, you can try out soon to be merged > development environment[1][2]" > Is it stable? > Can be used in a production environment? > > Thanks again your help, > > > HI?All > > ????? > > --- > ??????????? > ?? > > ------------------------------------------------------------------------------ > > > + ????????????????(????1:1) + > ------------------------------------------------------------------------------ > > > 2013/4/19 Alon Bar-Lev > > > Please try setup product without tweaks if you don't have real > reason to. > > Close the repository, then: > $ make tarball > $ rpmbuild -t > > Then install the result rpms as usual. > > Alternatively, you can try out soon to be merged development > environment[1][2] > > [1] https://github.com/alonbl/ovirt-engine/tree/otopi > [2] > https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer > > > ----- Original Message ----- > > From: "??" > > > To: engine-devel at ovirt.org > > Sent: Friday, April 19, 2013 6:18:24 PM > > Subject: [Engine-devel] Why deploy failed? Please help me, > thanks. > > > > > > HI?All > > > > OS:F18 > > Ovirt engine version: > > the first is 3.2.0 > > update to 3.2.1 > > and now I compile the source to other language. > > MEM:8G > > CPU:I7 > > DISK:60G > > > > > > I will use chinese language for ovirt engine, > > but rpm have not chinese language for default install. > > > > So I git clone source, that I compile the source success. > > From link: > > http://www.ovirt.org/Building_oVirt_engine > > > > COMPILE COMMAND > > mvn clean install -Pdep,gwt-admin,gwt-user,all-langs > > and show message: > > ------------------------ > > > > ------------------------ > > > > I deploy: > > DEPLOY COMMAND: > > cd ear && mvn clean install -Pdep > > > > QUESTION: > > 1, > > I open the first page that it show > > ------------------ > > Welcome to Open Virtualization Manager. > > Version 3.2.1- > > ------------------ > > Source shoule be 3.3.0? > > If souce version 3.3.0,then I deploy is not invalid. > > > > 2, > > Change language is failed and is still englist. > > Other language is invalid. > > COMMAND DEPLOY: > > ++++++++++++++++++++++ > > [liqiang at engine ear]$ mvn clean install -Pdep > > [INFO] Scanning for projects... > > [WARNING] > > [WARNING] Some problems were encountered while building the > effective model > > for org.ovirt.engine:engine-server-ear:ear:3.3.0-SNAPSHOT > > [WARNING] ' distributionManagement.repository.id > ' must not be > 'local', this > > identifier is reserved for the local repository, using it for > other > > repositories will corrupt your repository metadata. @ line > 18, column 11 > > [WARNING] > > [WARNING] It is highly recommended to fix these problems > because they > > threaten the stability of your build. > > [WARNING] > > [WARNING] For this reason, future Maven versions might no > longer support > > building such malformed projects. > > [WARNING] > > [INFO] > > [INFO] > > > ------------------------------------------------------------------------ > > [INFO] Building oVirt Server EAR 3.3.0-SNAPSHOT > > [INFO] > > > ------------------------------------------------------------------------ > > [INFO] > > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ > engine-server-ear > > --- > > [INFO] Deleting /home/liqiang/ovirt-engine/ear/target > > [INFO] > > [INFO] --- maven-antrun-plugin:1.7:run (undeploy-ear) @ > engine-server-ear --- > > [WARNING] Parameter tasks is deprecated, use target instead > > [INFO] Executing tasks > > > > main: > > [echo] *** Deleting > /usr/share/jboss-as/standalone/deployments/engine.ear/... > > [delete] Deleting directory > > /usr/share/jboss-as/standalone/deployments/engine.ear > > [INFO] Executed tasks > > [INFO] > > [INFO] --- maven-ear-plugin:2.8:generate-application-xml > > (default-generate-application-xml) @ engine-server-ear --- > > [INFO] Generating application.xml > > [INFO] > > [INFO] --- maven-resources-plugin:2.4.3:resources > (default-resources) @ > > engine-server-ear --- > > [INFO] Using 'UTF-8' encoding to copy filtered resources. > > [INFO] skip non existing resourceDirectory > > /home/liqiang/ovirt-engine/ear/src/main/java > > [INFO] Copying 1 resource > > [INFO] > > [INFO] --- maven-ear-plugin:2.8:ear (default-ear) @ > engine-server-ear --- > > [INFO] Copying artifact > [war:org.ovirt.engine.core:root-war:3.3.0-SNAPSHOT] > > to [root.war] (unpacked) > > [INFO] Copying artifact > > [war:org.ovirt.engine.api:restapi-webapp:3.3.0-SNAPSHOT] to > [restapi.war] > > (unpacked) > > [INFO] Copying artifact > [war:org.ovirt.engine.ui:userportal:3.3.0-SNAPSHOT] > > to [userportal.war] (unpacked) > > [INFO] Copying artifact > [war:org.ovirt.engine.ui:webadmin:3.3.0-SNAPSHOT] to > > [webadmin.war] (unpacked) > > [INFO] Copying artifact > [ejb:org.ovirt.engine.core:scheduler:3.3.0-SNAPSHOT] > > to [scheduler.jar] > > [INFO] Copying artifact > [ejb:org.ovirt.engine.core:bll:3.3.0-SNAPSHOT] to > > [bll.jar] > > [INFO] Copying artifact > [jar:org.ovirt.engine.core:vdsbroker:3.3.0-SNAPSHOT] > > to [lib/vdsbroker.jar] > > [INFO] Copying artifact > [jar:org.ovirt.engine.core:compat:3.3.0-SNAPSHOT] to > > [lib/compat.jar] > > [INFO] Copying artifact > [jar:org.ovirt.engine.core:common:3.3.0-SNAPSHOT] to > > [lib/common.jar] > > [INFO] Copying artifact > [jar:org.hibernate:hibernate-validator: 4.0.2.GA > ] to > > [lib/hibernate-validator.jar] > > [INFO] Copying artifact [jar:javax.validation:validation-api: > 1.0.0.GA ] to > > [lib/validation-api.jar] > > [INFO] Copying artifact [jar:javax.xml.bind:jaxb-api:2.1] to > > [lib/jaxb-api.jar] > > [INFO] Copying artifact [jar:javax.xml.stream:stax-api:1.0-2] to > > [lib/stax-api.jar] > > [INFO] Copying artifact [jar:com.sun.xml.bind:jaxb-impl:2.1.3] to > > [lib/jaxb-impl.jar] > > [INFO] Copying artifact > [jar:org.ovirt.engine.core:utils:3.3.0-SNAPSHOT] to > > [lib/utils.jar] > > [INFO] Copying artifact > [jar:commons-beanutils:commons-beanutils:1.8.2] to > > [lib/commons-beanutils.jar] > > [INFO] Copying artifact [jar:org.apache.mina:mina-core:2.0.1] to > > [lib/mina-core.jar] > > [INFO] Copying artifact [jar:org.apache.sshd:sshd-core:0.7.0] to > > [lib/sshd-core.jar] > > [INFO] Copying artifact [jar:org.ovirt.otopi:otopi:1.0.0] to > [lib/otopi.jar] > > [INFO] Copying artifact > > [jar:org.ovirt.ovirt-host-deploy:ovirt-host-deploy:1.0.0] to > > [lib/ovirt-host-deploy.jar] > > [INFO] Copying artifact > [jar:org.apache.commons:commons-compress:1.4.1] to > > [lib/commons-compress.jar] > > [INFO] Copying artifact [jar:org.tukaani:xz:1.0] to [lib/xz.jar] > > [INFO] Copying artifact [jar:commons-lang:commons-lang:2.6] to > > [lib/commons-lang.jar] > > [INFO] Copying artifact [jar:commons-codec:commons-codec:1.4] to > > [lib/commons-codec.jar] > > [INFO] Copying artifact > [jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] to > > [lib/xmlrpc-client.jar] > > [INFO] Copying artifact > [jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] to > > [lib/xmlrpc-common.jar] > > [INFO] Copying artifact > > [jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to > > [lib/ws-commons-util.jar] > > [INFO] Copying artifact [jar:xml-apis:xml-apis:1.0.b2] to > [lib/xml-apis.jar] > > [INFO] Copying artifact > [jar:org.ovirt.engine.core:dal:3.3.0-SNAPSHOT] to > > [lib/dal.jar] > > [INFO] Copying artifact > [jar:org.springframework:spring-jdbc:3.1.1.RELEASE] > > to [lib/spring-jdbc.jar] > > [INFO] Copying artifact > [jar:org.springframework:spring-tx:3.1.1.RELEASE] to > > [lib/spring-tx.jar] > > [INFO] Copying artifact > > [jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to > > [lib/spring-ldap-core.jar] > > [INFO] Copying artifact > [jar:commons-httpclient:commons-httpclient:3.1] to > > [lib/commons-httpclient.jar] > > [INFO] Copying artifact > [jar:commons-collections:commons-collections:3.1] to > > [lib/commons-collections.jar] > > [INFO] Copying artifact > [jar:org.quartz-scheduler:quartz:2.1.2] to > > [lib/quartz.jar] > > [INFO] Copying artifact [jar:c3p0:c3p0:0.9.1.1] to [lib/c3p0.jar] > > [INFO] Copying artifact [jar:org.slf4j:slf4j-api:1.6.1] to > > [lib/slf4j-api.jar] > > [INFO] Copying artifact > > [jar:org.ovirt.engine.core:searchbackend:3.3.0-SNAPSHOT] to > > [lib/searchbackend.jar] > > [INFO] Copying artifact > > > [jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] > > to [lib/jboss-interceptors-api_1.1_spec.jar] > > [INFO] Copying artifact > [jar:org.springframework:spring-core:3.1.1.RELEASE] > > to [lib/spring-core.jar] > > [INFO] Copying artifact > [jar:org.springframework:spring-asm:3.1.1.RELEASE] to > > [lib/spring-asm.jar] > > [INFO] Copying artifact > [jar:org.springframework:spring-beans:3.1.1.RELEASE] > > to [lib/spring-beans.jar] > > [INFO] Copying artifact > > [jar:org.springframework:spring-context:3.1.1.RELEASE] to > > [lib/spring-context.jar] > > [INFO] Copying artifact > [jar:org.springframework:spring-aop:3.1.1.RELEASE] to > > [lib/spring-aop.jar] > > [INFO] Copying artifact [jar:aopalliance:aopalliance:1.0] to > > [lib/aopalliance.jar] > > [INFO] Copying artifact > > [jar:org.springframework:spring-expression:3.1.1.RELEASE] to > > [lib/spring-expression.jar] > > [INFO] Copy ear sources to > /home/liqiang/ovirt-engine/ear/target/engine > > [INFO] Could not find manifest file: > > > /home/liqiang/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF - > > Generating one > > [INFO] Building jar: > /home/liqiang/ovirt-engine/ear/target/engine.ear > > [INFO] > > [INFO] --- maven-dependency-plugin:2.1:unpack (deploy-modules) @ > > engine-server-ear --- > > [INFO] Configured Artifact: > > org.ovirt.engine.core:dependencies:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:common:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:compat:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:dal:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:searchbackend:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:tools:modules:3.3.0-SNAPSHOT:zip > > [INFO] Configured Artifact: > > org.ovirt.engine.core:utils:modules:3.3.0-SNAPSHOT:zip > > [INFO] Unpacking > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/dependencies/3.3.0-SNAPSHOT/dependencies-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [WARNING] Unable to expand to file > > > /usr/share/jboss-as/modules/org/apache/commons/configuration/main/module.xml > > [WARNING] Unable to expand to file > > /usr/share/java/apache-commons-configuration.jar > > [INFO] Unpacking > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/common/3.3.0-SNAPSHOT/common-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] Unpacking > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/compat/3.3.0-SNAPSHOT/compat-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] Unpacking > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/dal/3.3.0-SNAPSHOT/dal-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] Unpacking > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/searchbackend/3.3.0-SNAPSHOT/searchbackend-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] Unpacking > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/tools/3.3.0-SNAPSHOT/tools-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] Unpacking > > > /home/liqiang/.m2/repository/org/ovirt/engine/core/utils/3.3.0-SNAPSHOT/utils-3.3.0-SNAPSHOT-modules.zip > > to > > /usr/share/jboss-as/modules > > with includes null and excludes:null > > [INFO] > > [INFO] --- maven-antrun-plugin:1.7:run (deploy-ear) @ > engine-server-ear --- > > [WARNING] Parameter tasks is deprecated, use target instead > > [INFO] Executing tasks > > > > main: > > [echo] *** Copying updated files to > > /usr/share/jboss-as/standalone/deployments/engine.ear/... > > [unjar] Expanding: > /home/liqiang/ovirt-engine/ear/target/engine.ear into > > /usr/share/jboss-as/standalone/deployments/engine.ear > > [echo] *** Touching > > > /usr/share/jboss-as/standalone/deployments/engine.ear/META-INF/application.xml > > to force redeployment of engine.ear... > > [echo] *** Touching engine.ear.dodeploy to force deployment > of engine.ear... > > [INFO] Executed tasks > > [INFO] > > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ > > engine-server-ear --- > > [INFO] Installing > /home/liqiang/ovirt-engine/ear/target/engine.ear to > > > /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear > > [INFO] Installing /home/liqiang/ovirt-engine/ear/pom.xml to > > > /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom > > [INFO] > > > ------------------------------------------------------------------------ > > [INFO] BUILD SUCCESS > > [INFO] > > > ------------------------------------------------------------------------ > > [INFO] Total time: 54.354s > > [INFO] Finished at: Fri Apr 19 10:48:39 EDT 2013 > > [INFO] Final Memory: 14M/191M > > [INFO] > > > ------------------------------------------------------------------------ > > ++++++++++++++++++++++ > > > > > > engine-upgrade > > COMMAND MESSAGE: > > ------------------------------------ > > [root at engine ~]# engine-upgrade > > > > Checking for updates... (This may take several minutes)...[ > DONE ] > > 8 Updates available: > > * ovirt-engine-3.2.1-1.fc18.noarch > > * ovirt-engine-tools-3.2.1-1.fc18.noarch > > * ovirt-engine-backend-3.2.1-1.fc18.noarch > > * ovirt-engine-dbscripts-3.2.1-1.fc18.noarch > > * ovirt-engine-genericapi-3.2.1-1.fc18.noarch > > * ovirt-engine-restapi-3.2.1-1.fc18.noarch > > * ovirt-engine-userportal-3.2.1-1.fc18.noarch > > * ovirt-engine-webadmin-portal-3.2.1-1.fc18.noarch > > > > During the upgrade process, oVirt Engine will not be accessible. > > All existing running virtual machines will continue but you > will not be able > > to > > start or stop any new virtual machines during the process. > > > > Would you like to proceed? (yes|no): yes > > Stopping ovirt-engine service... [ DONE ] > > Stopping DB related services... [ DONE ] > > Pre-upgrade validations... [ DONE ] > > Backing Up Database... [ DONE ] > > Rename Database... [ DONE ] > > Updating rpms... [ DONE ] > > Updating Database... [ DONE ] > > Restore Database name... [ DONE ] > > Preparing CA... [ DONE ] > > Running post install configuration... [ DONE ] > > Starting ovirt-engine service... [ DONE ] > > > > oVirt Engine upgrade completed successfully! > > > > * Upgrade log available at > > > /var/log/ovirt-engine/ovirt-engine-upgrade_2013_04_19_10_39_54.log > > * DB Backup available at > > > /var/lib/ovirt-engine/backups/ovirt-engine_db_backup_2013_04_19_10_39_54.sql > > ------------------------------------ > > > > > > > > _______________________________________________ > > 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 liqiang.net at gmail.com Sat Apr 20 06:32:20 2013 From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=) Date: Sat, 20 Apr 2013 14:32:20 +0800 Subject: [Engine-devel] Why deploy failed? Please help me, thanks. In-Reply-To: References: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> Message-ID: Help me,Thanks, engine-set ERROR, oVirt Engine will be installed using the following configuration: ================================================================= override-httpd-config: yes http-port: 80 https-port: 443 override-httpd-root: yes host-fqdn: ntp.startn.com auth-pass: ******** org-name: startn.com application-mode: both default-dc-type: NFS db-remote-install: local db-local-pass: ******** nfs-mp: /var/lib/exports/iso_2013_04_20_02_23_59 firewall-manager: None config-allinone: yes storage-path: /var/lib/images_2013_04_20_02_23_59 superuser-pass: ******** Proceed with the configuration listed above? (yes|no): yes Installing: AIO: Validating CPU Compatibility... [ DONE ] AIO: Adding firewall rules... [ DONE ] Configuring oVirt Engine... [ DONE ] Configuring JVM... [ DONE ] Creating CA... [ DONE ] Updating ovirt-engine service... [ DONE ] Setting Database Configuration... [ DONE ] Setting Database Security... [ DONE ] Upgrading Database Schema... [ DONE ] Editing oVirt Engine Configuration... [ DONE ] Editing Postgresql Configuration... [ DONE ] Configuring the Default ISO Domain... [ DONE ] Configuring Firewall... [ DONE ] Starting ovirt-engine Service... [ DONE ] Configuring HTTPD... [ DONE ] AIO: Creating storage directory... [ DONE ] AIO: Adding Local Datacenter and cluster... [ ERROR ] Error: could not create ovirtsdk API object Please check log file /var/log/ovirt-engine/engine-setup_2013_04_20_02_23_59.log for more information [root at engine ~]# vi /var/log/ovirt-engine/engine-setup_2013_04_20_02_23_59.log The newest log info: ==================== 2013-04-20 02:26:12::DEBUG::common_utils::496::root:: retcode = 0 2013-04-20 02:26:12::DEBUG::setup_sequences::59::root:: running makeStorageDir 2013-04-20 02:26:12::DEBUG::all_in_one_100::376::root:: Creating/Verifying local domain path 2013-04-20 02:26:12::DEBUG::all_in_one_100::379::root:: Creating directory /var/lib/images_2013_04_20_02_23_59 2013-04-20 02:26:12::DEBUG::all_in_one_100::382::root:: Setting selinux context 2013-04-20 02:26:12::DEBUG::nfsutils::119::root:: setting selinux context for /var/lib/images_2013_04_20_02_23_59 2013-04-20 02:26:12::DEBUG::common_utils::456::root:: Executing command --> '/usr/sbin/semanage fcontext -a -t public_content_rw_t /var/lib/images_2013_04_20_02_23_59(/.*)?' in working directory '/root' 2013-04-20 02:26:14::DEBUG::common_utils::494::root:: output = 2013-04-20 02:26:14::DEBUG::common_utils::495::root:: stderr = 2013-04-20 02:26:14::DEBUG::common_utils::496::root:: retcode = 0 2013-04-20 02:26:14::DEBUG::common_utils::456::root:: Executing command --> '/sbin/restorecon -r /var/lib/images_2013_04_20_02_23_59' in working directory '/root' 2013-04-20 02:26:14::DEBUG::common_utils::494::root:: output = 2013-04-20 02:26:14::DEBUG::common_utils::495::root:: stderr = 2013-04-20 02:26:14::DEBUG::common_utils::496::root:: retcode = 0 2013-04-20 02:26:14::DEBUG::setup_sequences::59::root:: running waitForJbossUp 2013-04-20 02:26:14::INFO::all_in_one_100::457::root:: JBoss is up and running. 2013-04-20 02:26:14::DEBUG::setup_sequences::59::root:: running initAPI 2013-04-20 02:26:14::DEBUG::all_in_one_100::240::root:: Initiating the API object 2013-04-20 02:26:14::DEBUG::all_in_one_100::244::root:: URL: ntp.startn.com:443 2013-04-20 02:26:15::ERROR::all_in_one_100::253::root:: Traceback (most recent call last): File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line 250, in initAPI ca_file=basedefs.FILE_CA_CRT_SRC, File "/usr/lib/python2.7/site-packages/ovirtsdk/api.py", line 119, in __init__ url='/api' File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line 112, in request persistent_auth=self._persistent_auth) File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line 134, in __doRequest persistent_auth=persistent_auth File "/usr/lib/python2.7/site-packages/ovirtsdk/web/connection.py", line 133, in doRequest raise RequestError, response RequestError: status: 401 reason: Unauthorized detail: HTTP Status 401 2013-04-20 02:26:15::DEBUG::setup_sequences::62::root:: Traceback (most recent call last): File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, in run function() File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line 254, in initAPI raise Exception(ERROR_CREATE_API_OBJECT) Exception: Error: could not create ovirtsdk API object 2013-04-20 02:26:15::DEBUG::engine-setup::2064::root:: *** The following params were used as user input: 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: override-httpd-config: yes 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: http-port: 80 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: https-port: 443 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: override-httpd-root: yes 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: random-passwords: no 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: mac-range: 00:1A:4A:A8:C3:00-00:1A:4A:A8:C3:FF 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: host-fqdn: ntp.startn.com 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: auth-pass: ******** 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: org-name: startn.com 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: application-mode: both 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: default-dc-type: NFS 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: db-remote-install: local 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: db-host: localhost 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: db-local-pass: ******** 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: nfs-mp: /var/lib/exports/iso_2013_04_20_02_23_59 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: iso-domain-name: ISO_DOMAIN 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: config-nfs: yes 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: firewall-manager: None 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: config-allinone: yes 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: storage-path: /var/lib/images_2013_04_20_02_23_59 2013-04-20 02:26:15::DEBUG::engine-setup::2069::root:: superuser-pass: ******** 2013-04-20 02:26:15::ERROR::engine-setup::2504::root:: Traceback (most recent call last): File "/usr/bin/engine-setup", line 2498, in main(confFile) File "/usr/bin/engine-setup", line 2265, in main runSequences() File "/usr/bin/engine-setup", line 2184, in runSequences controller.runAllSequences() File "/usr/share/ovirt-engine/scripts/setup_controller.py", line 54, in runAllSequences sequence.run() File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 154, in run step.run() File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, in run function() File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line 254, in initAPI raise Exception(ERROR_CREATE_API_OBJECT) Exception: Error: could not create ovirtsdk API object ============== HI?All ????? --- ??????????? ?? ------------------------------------------------------------------------------ + ????????????????(????1:1) + ------------------------------------------------------------------------------ 2013/4/20 ?? > [root at engine ~]# rpm -qa | grep ^ovi* > ovirt-engine-backend-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-host-deploy-offline-1.1.0-0.0.master.20130418.git827d30b.fc18.noarch > ovirt-engine-setup-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-engine-sdk-3.3.0.1-1.20130418.gitfc5985e.fc18.noarch > ovirt-host-deploy-java-1.0.1-1.fc18.noarch > ovirt-iso-uploader-3.3.0-0.0.master.20130318.gitec3e5e7.fc18.noarch > ovirt-engine-restapi-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-engine-webadmin-portal-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-image-uploader-3.3.0-0.0.master.20130417.git13f9ba3.fc18.noarch > ovirt-engine-dbscripts-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-engine-userportal-3.3.0-0.2.master.20130419160733.fc18.noarch > > ovirt-engine-setup-plugin-allinone-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-host-deploy-1.0.1-1.fc18.noarch > ovirt-engine-tools-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-log-collector-3.3.0-0.0.master.20130417.git6a09d06.fc18.noarch > ovirt-engine-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-engine-cli-3.2.0.11-1.fc18.noarch > ovirt-release-fedora-5-3.noarch > > HI?All > > ????? > > --- > ??????????? > ?? > > ------------------------------------------------------------------------------ > > > + ????????????????(????1:1) + > > ------------------------------------------------------------------------------ > > > 2013/4/20 ?? > >> My process: >> ps -ax >> ========================== >> [root at engine ~]# ps -ax >> PID TTY STAT TIME COMMAND >> 1 ? Ss 0:03 /usr/lib/systemd/systemd --system >> --deserialize 20 >> 2 ? S 0:00 [kthreadd] >> 3 ? S 0:00 [ksoftirqd/0] >> 5 ? S< 0:00 [kworker/0:0H] >> 6 ? S 0:00 [kworker/u:0] >> 7 ? S< 0:00 [kworker/u:0H] >> 8 ? S 0:02 [migration/0] >> 9 ? S 0:00 [rcu_bh] >> 10 ? S 0:01 [rcu_sched] >> 11 ? S 0:00 [watchdog/0] >> 12 ? S 0:00 [watchdog/1] >> 13 ? S 0:00 [ksoftirqd/1] >> 14 ? S 0:01 [migration/1] >> 15 ? S 0:00 [kworker/1:0] >> 16 ? S< 0:00 [kworker/1:0H] >> 17 ? S 0:00 [watchdog/2] >> 18 ? S 0:00 [ksoftirqd/2] >> 19 ? S 0:04 [migration/2] >> 21 ? S< 0:00 [kworker/2:0H] >> 22 ? S 0:00 [watchdog/3] >> 23 ? S 0:00 [ksoftirqd/3] >> 24 ? S 0:02 [migration/3] >> 26 ? S< 0:00 [kworker/3:0H] >> 27 ? S< 0:00 [cpuset] >> 28 ? S< 0:00 [khelper] >> 29 ? S 0:00 [kdevtmpfs] >> 30 ? S< 0:00 [netns] >> 31 ? S 0:00 [bdi-default] >> 32 ? S< 0:00 [kintegrityd] >> 33 ? S< 0:00 [kblockd] >> 34 ? S< 0:00 [ata_sff] >> 35 ? S 0:00 [khubd] >> 36 ? S< 0:00 [md] >> 44 ? S 0:01 [kworker/u:1] >> 62 ? S 0:00 [kswapd0] >> 63 ? SN 0:00 [ksmd] >> 64 ? SN 0:00 [khugepaged] >> 65 ? S 0:00 [fsnotify_mark] >> 66 ? S< 0:00 [crypto] >> 74 ? S< 0:00 [kthrotld] >> 77 ? S 0:00 [scsi_eh_0] >> 78 ? S 0:00 [scsi_eh_1] >> 80 ? S< 0:00 [kpsmoused] >> 81 ? S 0:00 [kworker/0:2] >> 82 ? S 0:00 [kworker/2:1] >> 83 ? S< 0:00 [deferwq] >> 97 ? S 0:00 [kauditd] >> 180 ? S< 0:00 [mpt_poll_0] >> 181 ? S< 0:00 [mpt/0] >> 189 ? S 0:00 [scsi_eh_2] >> 190 ? S< 0:00 [ttm_swap] >> 192 ? S< 0:01 [kworker/1:1H] >> 197 ? S 0:00 [kworker/1:2] >> 199 ? S< 0:01 [kworker/3:1H] >> 200 ? S 0:08 [kworker/3:2] >> 234 ? S< 0:01 [kworker/2:1H] >> 237 ? S< 0:00 [kdmflush] >> 239 ? S< 0:00 [kdmflush] >> 266 ? S< 0:00 [kworker/0:1H] >> 286 ? S 0:02 [jbd2/dm-1-8] >> 287 ? S< 0:00 [ext4-dio-unwrit] >> 330 ? Ss 0:00 /usr/lib/systemd/systemd-udevd >> 333 ? Ss 0:00 /usr/lib/systemd/systemd-journald >> 334 ? S 0:03 [flush-253:1] >> 368 ? S< 0:00 [rpciod] >> 569 ? S 0:00 [jbd2/sda1-8] >> 570 ? S< 0:00 [ext4-dio-unwrit] >> 580 ? S< 0:00 [kmpathd] >> 581 ? S< 0:00 [kmpath_handlerd] >> 586 ? S< 0:00 [kdmflush] >> 605 ? S 0:00 [jbd2/dm-2-8] >> 606 ? S< 0:00 [ext4-dio-unwrit] >> 641 ? SLl 0:00 /sbin/multipathd >> 642 ? Ss 0:00 /sbin/iprinit --daemon >> 643 ? Ss 0:00 /sbin/iprupdate --daemon >> 664 ? Ss 0:00 /usr/lib/systemd/systemd-logind >> 666 ? Ssl 0:00 /bin/dbus-daemon --system --address=systemd: >> --nofork --nopidfile --systemd-activation >> 682 tty1 Ss+ 0:00 /sbin/agetty --noclear tty1 38400 linux >> 687 ? S< 0:00 [iscsi_eh] >> 689 ? S< 0:00 [ib_mcast] >> 690 ? S< 0:00 [ib_cm] >> 691 ? S< 0:00 [iw_cm_wq] >> 692 ? S< 0:00 [ib_addr] >> 693 ? S< 0:00 [rdma_cm] >> 695 ? Ss 0:00 /sbin/iprdump --daemon >> 701 ? Ss 0:00 /usr/sbin/ntpd -u ntp:ntp -g >> 703 ? S 0:00 /bin/bash /usr/sbin/ksmtuned >> 709 ? S< 0:00 [cxgb4] >> 712 ? S< 0:00 [cnic_wq] >> 713 ? S< 0:00 [bnx2i_thread/0] >> 714 ? S< 0:00 [bnx2i_thread/1] >> 715 ? S< 0:00 [bnx2i_thread/2] >> 716 ? S< 0:00 [bnx2i_thread/3] >> 730 ? Ssl 0:00 iscsiuio >> 739 ? Ss 0:00 iscsid >> 740 ? S> 752 ? Ssl 0:00 /usr/sbin/NetworkManager --no-daemon >> 885 ? SLs 0:00 wdmd -G sanlock >> 915 ? SLsl 0:00 sanlock daemon -U sanlock -G sanlock >> 916 ? S 0:00 sanlock daemon -U sanlock -G sanlock >> 958 ? Ssl 0:00 /usr/lib/polkit-1/polkitd --no-debug >> 1189 ? S 0:00 /sbin/dhclient -d -sf >> /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-eth0.pid -lf >> /var/lib/NetworkManager/dhcli >> 1191 ? S 0:00 /sbin/dhclient -d -sf >> /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-eth1.pid -lf >> /var/lib/NetworkManager/dhcli >> 1223 ? Ssl 0:01 /usr/sbin/libvirtd --listen >> 1248 ? Ss 0:00 /usr/sbin/sshd -D >> 1482 ? S< 0:00 [bond0] >> 1497 ? S< 0:00 [bond4] >> 1499 ? S< 0:00 [bond1] >> 1500 ? S< 0:00 [bond2] >> 1501 ? S< 0:00 [bond3] >> 1566 ? S< 0:00 /bin/bash -e /usr/share/vdsm/respawn >> --minlifetime 10 --daemon --masterpid /var/run/vdsm/respawn.pid >> /usr/share/vdsm/vdsm >> 1570 ? S> 1589 ? S< 0:00 /usr/bin/sudo -n /usr/bin/python >> /usr/share/vdsm/supervdsmServer.py 2057b468-002a-489c-a6dd-7a980cb95b3a >> 1570 /var/run/vd >> 1590 ? S> /usr/share/vdsm/supervdsmServer.py 2057b468-002a-489c-a6dd-7a980cb95b3a >> 1570 /var/run/vdsm/svdsm.pid /var >> 1598 ? Ss 0:00 sshd: root at pts/0 >> 1626 pts/0 Ss 0:00 -bash >> 1762 ? Rs 0:00 sshd: root at pts/1 >> 1766 pts/1 Ss 0:00 -bash >> 4521 ? S 0:02 [kworker/3:1] >> 9054 ? Ss 0:06 sshd: root at pts/2 >> 9058 pts/2 Ss+ 0:00 -bash >> 11471 ? S 0:00 [kworker/0:1] >> 11646 ? S 0:00 [kworker/2:2] >> 11652 ? Ss 0:00 /usr/sbin/crond -n >> 12569 ? S 0:00 [flush-8:0] >> 12618 ? S 0:00 /usr/bin/postgres -D /var/lib/pgsql/data -p >> 5432 >> 12619 ? Ss 0:00 postgres: logger process >> >> 12621 ? Ss 0:00 postgres: checkpointer process >> >> 12622 ? Ss 0:00 postgres: writer process >> >> 12623 ? Ss 0:00 postgres: wal writer process >> >> 12624 ? Ss 0:00 postgres: autovacuum launcher process >> >> 12625 ? Ss 0:00 postgres: stats collector process >> >> 12657 ? Ssl 0:00 /usr/sbin/named -u named >> 12691 ? Ss 0:00 sendmail: accepting connections >> 12719 ? Ss 0:00 sendmail: Queue runner at 01:00:00 for >> /var/spool/clientmqueue >> 12764 ? Ss 0:00 /bin/sh /usr/share/jboss-as/bin/standalone.sh >> -c standalone.xml -b 0.0.0.0 >> 12816 ? Sl 0:07 java -D[Standalone] -server >> -XX:+UseCompressedOops -XX:+TieredCompilation -Xms64m -Xmx512m >> -XX:MaxPermSize=256m -Djava.ne >> 12985 ? Ss 0:00 /usr/bin/python /usr/sbin/firewalld --nofork >> 13318 ? S> 13363 ? Ssl 0:00 /sbin/rsyslogd -n >> 20734 ? S 0:00 [kworker/0:0] >> 20896 pts/0 Sl+ 0:01 /usr/bin/python /usr/bin/engine-setup >> 22780 ? Ss 0:00 /sbin/rpcbind -w >> 22805 ? Ss 0:00 /usr/bin/python >> /usr/share/ovirt-engine/service/engine-service.py start >> 22807 ? Sl 0:12 engine-service -server -XX:+TieredCompilation >> -Xms1g -Xmx1g -XX:PermSize=256m -XX:MaxPermSize=256m -Djava.net.preferIPv4S >> 22876 ? Ss 0:00 postgres: engine engine 127.0.0.1(44637) idle >> >> 22889 ? Ss 0:00 postgres: engine engine 127.0.0.1(44638) idle >> >> 22892 ? Ss 0:00 postgres: engine engine 127.0.0.1(44639) idle >> >> 22920 ? Ss 0:00 /usr/sbin/httpd -DFOREGROUND >> 22922 ? S 0:00 /usr/sbin/httpd -DFOREGROUND >> 22923 ? S 0:00 /usr/sbin/httpd -DFOREGROUND >> 22924 ? S 0:00 /usr/sbin/httpd -DFOREGROUND >> 22925 ? S 0:00 /usr/sbin/httpd -DFOREGROUND >> 22926 ? S 0:00 /usr/sbin/httpd -DFOREGROUND >> 22945 ? S 0:00 sleep 60 >> 22946 pts/1 R+ 0:00 ps -ax >> [root at engine ~]# >> ========================== >> >> and I run : >> yum update and setup still is ERROR. >> >> Please help my ,thanks, >> >> HI?All >> >> ????? >> >> --- >> ??????????? >> ?? >> >> ------------------------------------------------------------------------------ >> >> >> + ????????????????(????1:1) + >> >> ------------------------------------------------------------------------------ >> >> >> 2013/4/20 ?? >> >>> I have ERROR and Please help me ,thanks >>> >>> The first Upgrade is SUCCESS. >>> Please look the info. >>> >>> But engine-set is ERROR. >>> AIO: Adding Local Datacenter and cluster... [ ERROR ] >>> Error: could not create ovirtsdk API object >>> Please check log file >>> /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log for more >>> information >>> >>> >>> ========================================================== >>> [root at engine noarch]# rpm -Uvh *.rpm >>> Preparing... ################################# >>> [100%] >>> Updating / installing... >>> 1:ovirt-engine-sdk-3.3.0.1-1.201304################################# >>> [ 3%] >>> 2:ovirt-image-uploader-3.3.0-0.0.ma#################################[ 7%] >>> 3:ovirt-iso-uploader-3.3.0-0.0.mast################################# >>> [ 10%] >>> 4:ovirt-log-collector-3.3.0-0.0.mas################################# >>> [ 14%] >>> 5:ovirt-engine-backend-3.3.0-0.2.ma#################################[ 17%] >>> 6:ovirt-engine-dbscripts-3.3.0-0.2.################################# >>> [ 21%] >>> 7:ovirt-engine-restapi-3.3.0-0.2.ma#################################[ 24%] >>> 8:ovirt-engine-setup-3.3.0-0.2.mastwarning: >>> /etc/firewalld/services/ovirt.xml created as >>> /etc/firewalld/services/ovirt.xml.rpmnew >>> ################################# [ 28%] >>> 9:ovirt-engine-tools-3.3.0-0.2.mast################################# >>> [ 31%] >>> 10:ovirt-engine-userportal-3.3.0-0.2################################# >>> [ 34%] >>> 11:ovirt-engine-webadmin-portal-3.3.################################# >>> [ 38%] >>> 12:ovirt-engine-3.3.0-0.2.master.201################################# >>> [ 41%] >>> 13:ovirt-host-deploy-offline-1.1.0-0################################# >>> [ 45%] >>> 14:ovirt-engine-setup-plugin-allinon################################# >>> [ 48%] >>> Cleaning up / removing... >>> 15:ovirt-engine-backend-3.2.0-4.fc18################################# >>> [ 52%] >>> 16:ovirt-engine-config-3.2.0-4.fc18 ################################# >>> [ 55%] >>> 17:ovirt-engine-dbscripts-3.2.0-4.fc################################# >>> [ 59%] >>> 18:ovirt-engine-genericapi-3.2.0-4.f################################# >>> [ 62%] >>> 19:ovirt-engine-tools-common-3.2.0-4################################# >>> [ 66%] >>> 20:ovirt-engine-notification-service################################# >>> [ 69%] >>> 21:ovirt-engine-restapi-3.2.0-4.fc18################################# >>> [ 72%] >>> 22:ovirt-engine-setup-3.2.0-4.fc18 ################################# >>> [ 76%] >>> 23:ovirt-engine-userportal-3.2.0-4.f################################# >>> [ 79%] >>> 24:ovirt-engine-webadmin-portal-3.2.################################# >>> [ 83%] >>> 25:ovirt-engine-3.2.0-4.fc18 warning: >>> /etc/sysconfig/ovirt-engine saved as /etc/sysconfig/ovirt-engine.rpmsave >>> ################################# [ 86%] >>> 26:ovirt-image-uploader-3.2.0-1.fc18################################# >>> [ 90%] >>> 27:ovirt-iso-uploader-3.2.0-1.fc18 ################################# >>> [ 93%] >>> 28:ovirt-log-collector-3.2.0-1.fc18 ################################# >>> [ 97%] >>> 29:ovirt-engine-sdk-3.2.0.9-1.fc18 ################################# >>> [100%] >>> ========================================================== >>> >>> >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> [root at engine ~]# engine-setup >>> Welcome to oVirt Engine setup utility >>> >>> WARNING: oVirt Engine setup has already been run on this host. >>> To remove all configuration and reset oVirt Engine please run >>> engine-cleanup. >>> Please be advised that executing engine-setup without cleanup is not >>> supported. >>> Would you like to proceed? (yes|no): yes >>> >>> In order to proceed the installer must stop the ovirt-engine service >>> Would you like to stop the ovirt-engine service? (yes|no): yes >>> oVirt Engine uses httpd to proxy requests to the application server. >>> It looks like the httpd installed locally is being actively used. >>> The installer can override current configuration . >>> Alternatively you can use JBoss directly (on ports higher than 1024) >>> Do you wish to override current httpd configuration and restart the >>> service? ['yes'| 'no'] [yes] : >>> HTTP Port [80] : >>> HTTPS Port [443] : >>> Setup can configure server default page to launch oVirt Engine. Do you >>> wish to do so? ['yes'| 'no'] [yes] : >>> Host fully qualified domain name. Note: this name should be fully >>> resolvable [engine.startn.com] : >>> The IP 192.168.11.12 does not hold a PTR record for the FQDN: >>> engine.startn.com >>> User input failed validation, do you still wish to use it? (yes|no): yes >>> Enter a password for an internal oVirt Engine administrator user >>> (admin at internal) : >>> Warning: Weak Password. >>> Confirm password : >>> Organization Name for the Certificate [startn.com] : >>> The engine can be configured to present the UI in three different >>> application modes. virt [Manage virtualization only], gluster [Manage >>> gluster storage only], and both [Manage virtualization as well as gluster >>> storage] ['virt'| 'gluster'| 'both'] [both] : >>> The default storage type you will be using ['NFS'| 'FC'| 'ISCSI'| >>> 'POSIXFS'] [NFS] : >>> Enter DB type for installation ['remote'| 'local'] [local] : >>> Enter a password for a local oVirt Engine DB admin user (engine) : >>> Warning: Weak Password. >>> Confirm password : >>> Local ISO domain path [/var/lib/exports/iso_2013_04_19_21_46_58] : >>> Firewall ports need to be opened. >>> The installer can configure firewall automatically overriding the >>> current configuration. The old configuration will be backed up. >>> Alternately you can configure the firewall later using an example file >>> selecting None. >>> Which firewall manager do you wish to use? ['None'| 'Firewalld'| >>> 'iptables']: None >>> Configure VDSM on this host? ['yes'| 'no'] [yes] : >>> Local storage domain path [/var/lib/images_2013_04_19_21_46_58] : >>> Confirm root password : >>> >>> oVirt Engine will be installed using the following configuration: >>> ================================================================= >>> override-httpd-config: yes >>> http-port: 80 >>> https-port: 443 >>> override-httpd-root: yes >>> host-fqdn: engine.startn.com >>> auth-pass: ******** >>> org-name: startn.com >>> application-mode: both >>> default-dc-type: NFS >>> db-remote-install: local >>> db-local-pass: ******** >>> nfs-mp: /var/lib/exports/iso_2013_04_19_21_46_58 >>> firewall-manager: None >>> config-allinone: yes >>> storage-path: /var/lib/images_2013_04_19_21_46_58 >>> superuser-pass: ******** >>> Proceed with the configuration listed above? (yes|no): yes >>> >>> Installing: >>> AIO: Validating CPU Compatibility... [ DONE >>> ] >>> AIO: Adding firewall rules... [ DONE >>> ] >>> Configuring oVirt Engine... [ DONE >>> ] >>> Configuring JVM... [ DONE >>> ] >>> Creating CA... [ DONE >>> ] >>> Updating ovirt-engine service... [ DONE >>> ] >>> Setting Database Configuration... [ DONE >>> ] >>> Setting Database Security... [ DONE >>> ] >>> Upgrading Database Schema... [ DONE >>> ] >>> Editing oVirt Engine Configuration... [ DONE >>> ] >>> Editing Postgresql Configuration... [ DONE >>> ] >>> Configuring the Default ISO Domain... [ DONE >>> ] >>> Configuring Firewall... [ DONE >>> ] >>> Starting ovirt-engine Service... [ DONE >>> ] >>> Configuring HTTPD... [ DONE >>> ] >>> AIO: Creating storage directory... [ DONE >>> ] >>> AIO: Adding Local Datacenter and cluster... [ ERROR ] >>> Error: could not create ovirtsdk API object >>> Please check log file >>> /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log for more >>> information >>> >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> cat /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >>> 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = >>> 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 >>> 2013-04-19 21:48:39::DEBUG::setup_sequences::59::root:: running >>> _setupVarPrivileges >>> 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command >>> --> 'chown -Rh ovirt:ovirt /var/lib/ovirt-engine/deployments' in working >>> directory '/root' >>> 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = >>> 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = >>> 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 >>> 2013-04-19 21:48:39::DEBUG::setup_sequences::59::root:: running >>> _startEngine >>> 2013-04-19 21:48:39::DEBUG::engine-setup::1787::root:: using chkconfig >>> to enable engine to load on system startup. >>> 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command >>> --> '/sbin/chkconfig ovirt-engine on' in working directory '/root' >>> 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = >>> 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = Note: >>> Forwarding request to 'systemctl enable ovirt-engine.service'. >>> >>> 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 >>> 2013-04-19 21:48:39::DEBUG::common_utils::1285::root:: stopping >>> ovirt-engine >>> 2013-04-19 21:48:39::DEBUG::common_utils::1322::root:: executing action >>> ovirt-engine on service stop >>> 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command >>> --> '/sbin/service ovirt-engine stop' in working directory '/root' >>> 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = >>> 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = >>> Redirecting to /bin/systemctl stop ovirt-engine.service >>> >>> 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 >>> 2013-04-19 21:48:39::DEBUG::common_utils::1275::root:: starting >>> ovirt-engine >>> 2013-04-19 21:48:39::DEBUG::common_utils::1322::root:: executing action >>> ovirt-engine on service start >>> 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command >>> --> '/sbin/service ovirt-engine start' in working directory '/root' >>> 2013-04-19 21:48:39::DEBUG::common_utils::494::root:: output = >>> 2013-04-19 21:48:39::DEBUG::common_utils::495::root:: stderr = >>> Redirecting to /bin/systemctl start ovirt-engine.service >>> >>> 2013-04-19 21:48:39::DEBUG::common_utils::496::root:: retcode = 0 >>> 2013-04-19 21:48:39::DEBUG::setup_sequences::59::root:: running >>> _configureSelinuxBoolean >>> 2013-04-19 21:48:39::DEBUG::engine-setup::742::root:: Enable >>> httpd_can_network_connect boolean >>> 2013-04-19 21:48:39::DEBUG::common_utils::456::root:: Executing command >>> --> '/usr/sbin/semanage boolean --modify --on httpd_can_network_connect' in >>> working directory '/root' >>> 2013-04-19 21:48:52::DEBUG::common_utils::494::root:: output = >>> 2013-04-19 21:48:52::DEBUG::common_utils::495::root:: stderr = >>> 2013-04-19 21:48:52::DEBUG::common_utils::496::root:: retcode = 0 >>> 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running >>> _backupOldHttpdConfig >>> 2013-04-19 21:48:52::DEBUG::engine-setup::728::root:: Backup old httpd >>> configuration files >>> 2013-04-19 21:48:52::DEBUG::engine-setup::732::root:: Backing up >>> /etc/httpd/conf/httpd.conf into >>> /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 >>> 2013-04-19 21:48:52::DEBUG::common_utils::729::root:: successfully >>> copied file /etc/httpd/conf/httpd.conf to target destination >>> /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 >>> 2013-04-19 21:48:52::DEBUG::common_utils::737::root:: setting file >>> /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 uid/gid ownership >>> 2013-04-19 21:48:52::DEBUG::common_utils::740::root:: setting file >>> /etc/httpd/conf/httpd.conf.BACKUP.2013_04_19_21_48_52 mode to -1 >>> 2013-04-19 21:48:52::DEBUG::engine-setup::737::root:: Backing up >>> /etc/httpd/conf.d/ssl.conf into >>> /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 >>> 2013-04-19 21:48:52::DEBUG::common_utils::729::root:: successfully >>> copied file /etc/httpd/conf.d/ssl.conf to target destination >>> /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 >>> 2013-04-19 21:48:52::DEBUG::common_utils::737::root:: setting file >>> /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 uid/gid ownership >>> 2013-04-19 21:48:52::DEBUG::common_utils::740::root:: setting file >>> /etc/httpd/conf.d/ssl.conf.BACKUP.2013_04_19_21_48_52 mode to -1 >>> 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running >>> _configureHttpdSslKeys >>> 2013-04-19 21:48:52::DEBUG::engine-setup::754::root:: Update >>> /etc/httpd/conf.d/ssl.conf to use engine private key in mod_ssl directives >>> 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running >>> _configureHttpdPort >>> 2013-04-19 21:48:52::DEBUG::engine-setup::786::root:: Update >>> /etc/httpd/conf/httpd.conf to listen in the new HTTP port >>> 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running >>> _configureHttpdSslPort >>> 2013-04-19 21:48:52::DEBUG::engine-setup::798::root:: Update >>> /etc/httpd/conf.d/ssl.conf to listen in the new HTTPS port >>> 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running >>> _redirectUrl >>> 2013-04-19 21:48:52::DEBUG::common_utils::84::root:: Processing template >>> /usr/share/ovirt-engine/conf/ovirt-engine-proxy.conf.in to >>> /etc/httpd/conf.d/z-ovirt-engine-proxy.conf vars {'@JBOSS_AJP_PORT@': >>> '8702'} >>> 2013-04-19 21:48:52::DEBUG::common_utils::729::root:: successfully >>> copied file /usr/share/ovirt-engine/conf/ >>> ovirt-engine-root-redirect.conf.in to target destination >>> /etc/httpd/conf.d/ovirt-engine-root-redirect.conf >>> 2013-04-19 21:48:52::DEBUG::common_utils::737::root:: setting file >>> /etc/httpd/conf.d/ovirt-engine-root-redirect.conf uid/gid ownership >>> 2013-04-19 21:48:52::DEBUG::common_utils::740::root:: setting file >>> /etc/httpd/conf.d/ovirt-engine-root-redirect.conf mode to -1 >>> 2013-04-19 21:48:52::DEBUG::setup_sequences::59::root:: running >>> _startHttpd >>> 2013-04-19 21:48:52::DEBUG::engine-setup::1769::root:: Handling the >>> httpd service >>> 2013-04-19 21:48:52::DEBUG::common_utils::456::root:: Executing command >>> --> '/sbin/chkconfig httpd on' in working directory '/root' >>> 2013-04-19 21:48:52::DEBUG::common_utils::494::root:: output = >>> 2013-04-19 21:48:52::DEBUG::common_utils::495::root:: stderr = Note: >>> Forwarding request to 'systemctl enable httpd.service'. >>> >>> 2013-04-19 21:48:52::DEBUG::common_utils::496::root:: retcode = 0 >>> 2013-04-19 21:48:52::DEBUG::common_utils::1285::root:: stopping httpd >>> 2013-04-19 21:48:52::DEBUG::common_utils::1322::root:: executing action >>> httpd on service stop >>> 2013-04-19 21:48:52::DEBUG::common_utils::456::root:: Executing command >>> --> '/sbin/service httpd stop' in working directory '/root' >>> 2013-04-19 21:48:52::DEBUG::common_utils::494::root:: output = >>> 2013-04-19 21:48:52::DEBUG::common_utils::495::root:: stderr = >>> Redirecting to /bin/systemctl stop httpd.service >>> >>> 2013-04-19 21:48:52::DEBUG::common_utils::496::root:: retcode = 0 >>> 2013-04-19 21:48:52::DEBUG::common_utils::1275::root:: starting httpd >>> 2013-04-19 21:48:52::DEBUG::common_utils::1322::root:: executing action >>> httpd on service start >>> 2013-04-19 21:48:52::DEBUG::common_utils::456::root:: Executing command >>> --> '/sbin/service httpd start' in working directory '/root' >>> 2013-04-19 21:48:54::DEBUG::common_utils::494::root:: output = >>> 2013-04-19 21:48:54::DEBUG::common_utils::495::root:: stderr = >>> Redirecting to /bin/systemctl start httpd.service >>> >>> 2013-04-19 21:48:54::DEBUG::common_utils::496::root:: retcode = 0 >>> 2013-04-19 21:48:54::DEBUG::setup_sequences::59::root:: running >>> makeStorageDir >>> 2013-04-19 21:48:54::DEBUG::all_in_one_100::374::root:: >>> Creating/Verifying local domain path >>> 2013-04-19 21:48:54::DEBUG::all_in_one_100::377::root:: Creating >>> directory /var/lib/images_2013_04_19_21_46_58 >>> 2013-04-19 21:48:54::DEBUG::all_in_one_100::380::root:: Setting selinux >>> context >>> 2013-04-19 21:48:54::DEBUG::nfsutils::119::root:: setting selinux >>> context for /var/lib/images_2013_04_19_21_46_58 >>> 2013-04-19 21:48:54::DEBUG::common_utils::456::root:: Executing command >>> --> '/usr/sbin/semanage fcontext -a -t public_content_rw_t >>> /var/lib/images_2013_04_19_21_46_58(/.*)?' in working directory '/root' >>> 2013-04-19 21:48:55::DEBUG::common_utils::494::root:: output = >>> 2013-04-19 21:48:55::DEBUG::common_utils::495::root:: stderr = >>> 2013-04-19 21:48:55::DEBUG::common_utils::496::root:: retcode = 0 >>> 2013-04-19 21:48:55::DEBUG::common_utils::456::root:: Executing command >>> --> '/sbin/restorecon -r /var/lib/images_2013_04_19_21_46_58' in working >>> directory '/root' >>> 2013-04-19 21:48:55::DEBUG::common_utils::494::root:: output = >>> 2013-04-19 21:48:55::DEBUG::common_utils::495::root:: stderr = >>> 2013-04-19 21:48:55::DEBUG::common_utils::496::root:: retcode = 0 >>> 2013-04-19 21:48:55::DEBUG::setup_sequences::59::root:: running >>> waitForJbossUp >>> 2013-04-19 21:48:55::DEBUG::all_in_one_100::451::root:: Checking JBoss >>> status. >>> 2013-04-19 21:48:55::INFO::all_in_one_100::454::root:: JBoss is up and >>> running. >>> 2013-04-19 21:48:55::DEBUG::setup_sequences::59::root:: running initAPI >>> 2013-04-19 21:48:55::DEBUG::all_in_one_100::240::root:: Initiating the >>> API object >>> 2013-04-19 21:48:56::ERROR::all_in_one_100::251::root:: Traceback (most >>> recent call last): >>> File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line >>> 248, in initAPI >>> ca_file=basedefs.FILE_CA_CRT_SRC, >>> File "/usr/lib/python2.7/site-packages/ovirtsdk/api.py", line 119, in >>> __init__ >>> url='/api' >>> File >>> "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line >>> 112, in request >>> persistent_auth=self._persistent_auth) >>> File >>> "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line >>> 134, in __doRequest >>> persistent_auth=persistent_auth >>> File "/usr/lib/python2.7/site-packages/ovirtsdk/web/connection.py", >>> line 133, in doRequest >>> raise RequestError, response >>> RequestError: >>> status: 401 >>> reason: Unauthorized >>> detail: HTTP Status 401 >>> >>> 2013-04-19 21:48:56::DEBUG::setup_sequences::62::root:: Traceback (most >>> recent call last): >>> File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, in >>> run >>> function() >>> File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line >>> 252, in initAPI >>> raise Exception(ERROR_CREATE_API_OBJECT) >>> Exception: Error: could not create ovirtsdk API object >>> >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2064::root:: *** The following >>> params were used as user input: >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: >>> override-httpd-config: yes >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: http-port: 80 >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: https-port: 443 >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: >>> override-httpd-root: yes >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: random-passwords: >>> no >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: mac-range: >>> 00:1A:4A:A8:C3:00-00:1A:4A:A8:C3:FF >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: host-fqdn: >>> engine.startn.com >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: auth-pass: >>> ******** >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: org-name: >>> startn.com >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: application-mode: >>> both >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: default-dc-type: >>> NFS >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: >>> db-remote-install: local >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: db-host: localhost >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: db-local-pass: >>> ******** >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: nfs-mp: >>> /var/lib/exports/iso_2013_04_19_21_46_58 >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: iso-domain-name: >>> ISO_DOMAIN >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: config-nfs: yes >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: firewall-manager: >>> None >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: config-allinone: >>> yes >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: storage-path: >>> /var/lib/images_2013_04_19_21_46_58 >>> 2013-04-19 21:48:56::DEBUG::engine-setup::2069::root:: superuser-pass: >>> ******** >>> 2013-04-19 21:48:56::ERROR::engine-setup::2504::root:: Traceback (most >>> recent call last): >>> File "/usr/bin/engine-setup", line 2498, in >>> main(confFile) >>> File "/usr/bin/engine-setup", line 2265, in main >>> runSequences() >>> File "/usr/bin/engine-setup", line 2184, in runSequences >>> controller.runAllSequences() >>> File "/usr/share/ovirt-engine/scripts/setup_controller.py", line 54, >>> in runAllSequences >>> sequence.run() >>> File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 154, >>> in run >>> step.run() >>> File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, in >>> run >>> function() >>> File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line >>> 252, in initAPI >>> raise Exception(ERROR_CREATE_API_OBJECT) >>> Exception: Error: could not create ovirtsdk API object >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >>> >>> HI?All >>> >>> ????? >>> >>> --- >>> ??????????? >>> ?? >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> + ????????????????(????1:1) + >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> 2013/4/20 ?? >>> >>>> HI?Alon >>>> >>>> Thank your help, >>>> >>>> The question: >>>> 1,Your email "Close the repository", What does it mean? >>>> >>>> 2,Your email "Alternatively, you can try out soon to be merged >>>> development environment[1][2]" >>>> Is it stable? >>>> Can be used in a production environment? >>>> >>>> Thanks again your help, >>>> >>>> >>>> HI?All >>>> >>>> ????? >>>> >>>> --- >>>> ??????????? >>>> ?? >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> + ????????????????(????1:1) + >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> 2013/4/19 Alon Bar-Lev >>>> >>>>> Please try setup product without tweaks if you don't have real reason >>>>> to. >>>>> >>>>> Close the repository, then: >>>>> $ make tarball >>>>> $ rpmbuild -t >>>>> >>>>> Then install the result rpms as usual. >>>>> >>>>> Alternatively, you can try out soon to be merged development >>>>> environment[1][2] >>>>> >>>>> [1] https://github.com/alonbl/ovirt-engine/tree/otopi >>>>> [2] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> > From: "??" >>>>> > To: engine-devel at ovirt.org >>>>> > Sent: Friday, April 19, 2013 6:18:24 PM >>>>> > Subject: [Engine-devel] Why deploy failed? Please help me, thanks. >>>>> > >>>>> > >>>>> > HI?All >>>>> > >>>>> > OS:F18 >>>>> > Ovirt engine version: >>>>> > the first is 3.2.0 >>>>> > update to 3.2.1 >>>>> > and now I compile the source to other language. >>>>> > MEM:8G >>>>> > CPU:I7 >>>>> > DISK:60G >>>>> > >>>>> > >>>>> > I will use chinese language for ovirt engine, >>>>> > but rpm have not chinese language for default install. >>>>> > >>>>> > So I git clone source, that I compile the source success. >>>>> > From link: >>>>> > http://www.ovirt.org/Building_oVirt_engine >>>>> > >>>>> > COMPILE COMMAND >>>>> > mvn clean install -Pdep,gwt-admin,gwt-user,all-langs >>>>> > and show message: >>>>> > ------------------------ >>>>> > >>>>> > ------------------------ >>>>> > >>>>> > I deploy: >>>>> > DEPLOY COMMAND: >>>>> > cd ear && mvn clean install -Pdep >>>>> > >>>>> > QUESTION: >>>>> > 1, >>>>> > I open the first page that it show >>>>> > ------------------ >>>>> > Welcome to Open Virtualization Manager. >>>>> > Version 3.2.1- >>>>> > ------------------ >>>>> > Source shoule be 3.3.0? >>>>> > If souce version 3.3.0,then I deploy is not invalid. >>>>> > >>>>> > 2, >>>>> > Change language is failed and is still englist. >>>>> > Other language is invalid. >>>>> > COMMAND DEPLOY: >>>>> > ++++++++++++++++++++++ >>>>> > [liqiang at engine ear]$ mvn clean install -Pdep >>>>> > [INFO] Scanning for projects... >>>>> > [WARNING] >>>>> > [WARNING] Some problems were encountered while building the >>>>> effective model >>>>> > for org.ovirt.engine:engine-server-ear:ear:3.3.0-SNAPSHOT >>>>> > [WARNING] ' distributionManagement.repository.id ' must not be >>>>> 'local', this >>>>> > identifier is reserved for the local repository, using it for other >>>>> > repositories will corrupt your repository metadata. @ line 18, >>>>> column 11 >>>>> > [WARNING] >>>>> > [WARNING] It is highly recommended to fix these problems because they >>>>> > threaten the stability of your build. >>>>> > [WARNING] >>>>> > [WARNING] For this reason, future Maven versions might no longer >>>>> support >>>>> > building such malformed projects. >>>>> > [WARNING] >>>>> > [INFO] >>>>> > [INFO] >>>>> > >>>>> ------------------------------------------------------------------------ >>>>> > [INFO] Building oVirt Server EAR 3.3.0-SNAPSHOT >>>>> > [INFO] >>>>> > >>>>> ------------------------------------------------------------------------ >>>>> > [INFO] >>>>> > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ >>>>> engine-server-ear >>>>> > --- >>>>> > [INFO] Deleting /home/liqiang/ovirt-engine/ear/target >>>>> > [INFO] >>>>> > [INFO] --- maven-antrun-plugin:1.7:run (undeploy-ear) @ >>>>> engine-server-ear --- >>>>> > [WARNING] Parameter tasks is deprecated, use target instead >>>>> > [INFO] Executing tasks >>>>> > >>>>> > main: >>>>> > [echo] *** Deleting >>>>> /usr/share/jboss-as/standalone/deployments/engine.ear/... >>>>> > [delete] Deleting directory >>>>> > /usr/share/jboss-as/standalone/deployments/engine.ear >>>>> > [INFO] Executed tasks >>>>> > [INFO] >>>>> > [INFO] --- maven-ear-plugin:2.8:generate-application-xml >>>>> > (default-generate-application-xml) @ engine-server-ear --- >>>>> > [INFO] Generating application.xml >>>>> > [INFO] >>>>> > [INFO] --- maven-resources-plugin:2.4.3:resources >>>>> (default-resources) @ >>>>> > engine-server-ear --- >>>>> > [INFO] Using 'UTF-8' encoding to copy filtered resources. >>>>> > [INFO] skip non existing resourceDirectory >>>>> > /home/liqiang/ovirt-engine/ear/src/main/java >>>>> > [INFO] Copying 1 resource >>>>> > [INFO] >>>>> > [INFO] --- maven-ear-plugin:2.8:ear (default-ear) @ >>>>> engine-server-ear --- >>>>> > [INFO] Copying artifact >>>>> [war:org.ovirt.engine.core:root-war:3.3.0-SNAPSHOT] >>>>> > to [root.war] (unpacked) >>>>> > [INFO] Copying artifact >>>>> > [war:org.ovirt.engine.api:restapi-webapp:3.3.0-SNAPSHOT] to >>>>> [restapi.war] >>>>> > (unpacked) >>>>> > [INFO] Copying artifact >>>>> [war:org.ovirt.engine.ui:userportal:3.3.0-SNAPSHOT] >>>>> > to [userportal.war] (unpacked) >>>>> > [INFO] Copying artifact >>>>> [war:org.ovirt.engine.ui:webadmin:3.3.0-SNAPSHOT] to >>>>> > [webadmin.war] (unpacked) >>>>> > [INFO] Copying artifact >>>>> [ejb:org.ovirt.engine.core:scheduler:3.3.0-SNAPSHOT] >>>>> > to [scheduler.jar] >>>>> > [INFO] Copying artifact >>>>> [ejb:org.ovirt.engine.core:bll:3.3.0-SNAPSHOT] to >>>>> > [bll.jar] >>>>> > [INFO] Copying artifact >>>>> [jar:org.ovirt.engine.core:vdsbroker:3.3.0-SNAPSHOT] >>>>> > to [lib/vdsbroker.jar] >>>>> > [INFO] Copying artifact >>>>> [jar:org.ovirt.engine.core:compat:3.3.0-SNAPSHOT] to >>>>> > [lib/compat.jar] >>>>> > [INFO] Copying artifact >>>>> [jar:org.ovirt.engine.core:common:3.3.0-SNAPSHOT] to >>>>> > [lib/common.jar] >>>>> > [INFO] Copying artifact [jar:org.hibernate:hibernate-validator: >>>>> 4.0.2.GA ] to >>>>> > [lib/hibernate-validator.jar] >>>>> > [INFO] Copying artifact [jar:javax.validation:validation-api: >>>>> 1.0.0.GA ] to >>>>> > [lib/validation-api.jar] >>>>> > [INFO] Copying artifact [jar:javax.xml.bind:jaxb-api:2.1] to >>>>> > [lib/jaxb-api.jar] >>>>> > [INFO] Copying artifact [jar:javax.xml.stream:stax-api:1.0-2] to >>>>> > [lib/stax-api.jar] >>>>> > [INFO] Copying artifact [jar:com.sun.xml.bind:jaxb-impl:2.1.3] to >>>>> > [lib/jaxb-impl.jar] >>>>> > [INFO] Copying artifact >>>>> [jar:org.ovirt.engine.core:utils:3.3.0-SNAPSHOT] to >>>>> > [lib/utils.jar] >>>>> > [INFO] Copying artifact >>>>> [jar:commons-beanutils:commons-beanutils:1.8.2] to >>>>> > [lib/commons-beanutils.jar] >>>>> > [INFO] Copying artifact [jar:org.apache.mina:mina-core:2.0.1] to >>>>> > [lib/mina-core.jar] >>>>> > [INFO] Copying artifact [jar:org.apache.sshd:sshd-core:0.7.0] to >>>>> > [lib/sshd-core.jar] >>>>> > [INFO] Copying artifact [jar:org.ovirt.otopi:otopi:1.0.0] to >>>>> [lib/otopi.jar] >>>>> > [INFO] Copying artifact >>>>> > [jar:org.ovirt.ovirt-host-deploy:ovirt-host-deploy:1.0.0] to >>>>> > [lib/ovirt-host-deploy.jar] >>>>> > [INFO] Copying artifact >>>>> [jar:org.apache.commons:commons-compress:1.4.1] to >>>>> > [lib/commons-compress.jar] >>>>> > [INFO] Copying artifact [jar:org.tukaani:xz:1.0] to [lib/xz.jar] >>>>> > [INFO] Copying artifact [jar:commons-lang:commons-lang:2.6] to >>>>> > [lib/commons-lang.jar] >>>>> > [INFO] Copying artifact [jar:commons-codec:commons-codec:1.4] to >>>>> > [lib/commons-codec.jar] >>>>> > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] >>>>> to >>>>> > [lib/xmlrpc-client.jar] >>>>> > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] >>>>> to >>>>> > [lib/xmlrpc-common.jar] >>>>> > [INFO] Copying artifact >>>>> > [jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to >>>>> > [lib/ws-commons-util.jar] >>>>> > [INFO] Copying artifact [jar:xml-apis:xml-apis:1.0.b2] to >>>>> [lib/xml-apis.jar] >>>>> > [INFO] Copying artifact >>>>> [jar:org.ovirt.engine.core:dal:3.3.0-SNAPSHOT] to >>>>> > [lib/dal.jar] >>>>> > [INFO] Copying artifact >>>>> [jar:org.springframework:spring-jdbc:3.1.1.RELEASE] >>>>> > to [lib/spring-jdbc.jar] >>>>> > [INFO] Copying artifact >>>>> [jar:org.springframework:spring-tx:3.1.1.RELEASE] to >>>>> > [lib/spring-tx.jar] >>>>> > [INFO] Copying artifact >>>>> > [jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to >>>>> > [lib/spring-ldap-core.jar] >>>>> > [INFO] Copying artifact >>>>> [jar:commons-httpclient:commons-httpclient:3.1] to >>>>> > [lib/commons-httpclient.jar] >>>>> > [INFO] Copying artifact >>>>> [jar:commons-collections:commons-collections:3.1] to >>>>> > [lib/commons-collections.jar] >>>>> > [INFO] Copying artifact [jar:org.quartz-scheduler:quartz:2.1.2] to >>>>> > [lib/quartz.jar] >>>>> > [INFO] Copying artifact [jar:c3p0:c3p0:0.9.1.1] to [lib/c3p0.jar] >>>>> > [INFO] Copying artifact [jar:org.slf4j:slf4j-api:1.6.1] to >>>>> > [lib/slf4j-api.jar] >>>>> > [INFO] Copying artifact >>>>> > [jar:org.ovirt.engine.core:searchbackend:3.3.0-SNAPSHOT] to >>>>> > [lib/searchbackend.jar] >>>>> > [INFO] Copying artifact >>>>> > >>>>> [jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final] >>>>> > to [lib/jboss-interceptors-api_1.1_spec.jar] >>>>> > [INFO] Copying artifact >>>>> [jar:org.springframework:spring-core:3.1.1.RELEASE] >>>>> > to [lib/spring-core.jar] >>>>> > [INFO] Copying artifact >>>>> [jar:org.springframework:spring-asm:3.1.1.RELEASE] to >>>>> > [lib/spring-asm.jar] >>>>> > [INFO] Copying artifact >>>>> [jar:org.springframework:spring-beans:3.1.1.RELEASE] >>>>> > to [lib/spring-beans.jar] >>>>> > [INFO] Copying artifact >>>>> > [jar:org.springframework:spring-context:3.1.1.RELEASE] to >>>>> > [lib/spring-context.jar] >>>>> > [INFO] Copying artifact >>>>> [jar:org.springframework:spring-aop:3.1.1.RELEASE] to >>>>> > [lib/spring-aop.jar] >>>>> > [INFO] Copying artifact [jar:aopalliance:aopalliance:1.0] to >>>>> > [lib/aopalliance.jar] >>>>> > [INFO] Copying artifact >>>>> > [jar:org.springframework:spring-expression:3.1.1.RELEASE] to >>>>> > [lib/spring-expression.jar] >>>>> > [INFO] Copy ear sources to >>>>> /home/liqiang/ovirt-engine/ear/target/engine >>>>> > [INFO] Could not find manifest file: >>>>> > /home/liqiang/ovirt-engine/ear/target/engine/META-INF/MANIFEST.MF - >>>>> > Generating one >>>>> > [INFO] Building jar: /home/liqiang/ovirt-engine/ear/target/engine.ear >>>>> > [INFO] >>>>> > [INFO] --- maven-dependency-plugin:2.1:unpack (deploy-modules) @ >>>>> > engine-server-ear --- >>>>> > [INFO] Configured Artifact: >>>>> > org.ovirt.engine.core:dependencies:modules:3.3.0-SNAPSHOT:zip >>>>> > [INFO] Configured Artifact: >>>>> > org.ovirt.engine.core:common:modules:3.3.0-SNAPSHOT:zip >>>>> > [INFO] Configured Artifact: >>>>> > org.ovirt.engine.core:compat:modules:3.3.0-SNAPSHOT:zip >>>>> > [INFO] Configured Artifact: >>>>> > org.ovirt.engine.core:dal:modules:3.3.0-SNAPSHOT:zip >>>>> > [INFO] Configured Artifact: >>>>> > org.ovirt.engine.core:searchbackend:modules:3.3.0-SNAPSHOT:zip >>>>> > [INFO] Configured Artifact: >>>>> > org.ovirt.engine.core:tools:modules:3.3.0-SNAPSHOT:zip >>>>> > [INFO] Configured Artifact: >>>>> > org.ovirt.engine.core:utils:modules:3.3.0-SNAPSHOT:zip >>>>> > [INFO] Unpacking >>>>> > >>>>> /home/liqiang/.m2/repository/org/ovirt/engine/core/dependencies/3.3.0-SNAPSHOT/dependencies-3.3.0-SNAPSHOT-modules.zip >>>>> > to >>>>> > /usr/share/jboss-as/modules >>>>> > with includes null and excludes:null >>>>> > [WARNING] Unable to expand to file >>>>> > >>>>> /usr/share/jboss-as/modules/org/apache/commons/configuration/main/module.xml >>>>> > [WARNING] Unable to expand to file >>>>> > /usr/share/java/apache-commons-configuration.jar >>>>> > [INFO] Unpacking >>>>> > >>>>> /home/liqiang/.m2/repository/org/ovirt/engine/core/common/3.3.0-SNAPSHOT/common-3.3.0-SNAPSHOT-modules.zip >>>>> > to >>>>> > /usr/share/jboss-as/modules >>>>> > with includes null and excludes:null >>>>> > [INFO] Unpacking >>>>> > >>>>> /home/liqiang/.m2/repository/org/ovirt/engine/core/compat/3.3.0-SNAPSHOT/compat-3.3.0-SNAPSHOT-modules.zip >>>>> > to >>>>> > /usr/share/jboss-as/modules >>>>> > with includes null and excludes:null >>>>> > [INFO] Unpacking >>>>> > >>>>> /home/liqiang/.m2/repository/org/ovirt/engine/core/dal/3.3.0-SNAPSHOT/dal-3.3.0-SNAPSHOT-modules.zip >>>>> > to >>>>> > /usr/share/jboss-as/modules >>>>> > with includes null and excludes:null >>>>> > [INFO] Unpacking >>>>> > >>>>> /home/liqiang/.m2/repository/org/ovirt/engine/core/searchbackend/3.3.0-SNAPSHOT/searchbackend-3.3.0-SNAPSHOT-modules.zip >>>>> > to >>>>> > /usr/share/jboss-as/modules >>>>> > with includes null and excludes:null >>>>> > [INFO] Unpacking >>>>> > >>>>> /home/liqiang/.m2/repository/org/ovirt/engine/core/tools/3.3.0-SNAPSHOT/tools-3.3.0-SNAPSHOT-modules.zip >>>>> > to >>>>> > /usr/share/jboss-as/modules >>>>> > with includes null and excludes:null >>>>> > [INFO] Unpacking >>>>> > >>>>> /home/liqiang/.m2/repository/org/ovirt/engine/core/utils/3.3.0-SNAPSHOT/utils-3.3.0-SNAPSHOT-modules.zip >>>>> > to >>>>> > /usr/share/jboss-as/modules >>>>> > with includes null and excludes:null >>>>> > [INFO] >>>>> > [INFO] --- maven-antrun-plugin:1.7:run (deploy-ear) @ >>>>> engine-server-ear --- >>>>> > [WARNING] Parameter tasks is deprecated, use target instead >>>>> > [INFO] Executing tasks >>>>> > >>>>> > main: >>>>> > [echo] *** Copying updated files to >>>>> > /usr/share/jboss-as/standalone/deployments/engine.ear/... >>>>> > [unjar] Expanding: /home/liqiang/ovirt-engine/ear/target/engine.ear >>>>> into >>>>> > /usr/share/jboss-as/standalone/deployments/engine.ear >>>>> > [echo] *** Touching >>>>> > >>>>> /usr/share/jboss-as/standalone/deployments/engine.ear/META-INF/application.xml >>>>> > to force redeployment of engine.ear... >>>>> > [echo] *** Touching engine.ear.dodeploy to force deployment of >>>>> engine.ear... >>>>> > [INFO] Executed tasks >>>>> > [INFO] >>>>> > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ >>>>> > engine-server-ear --- >>>>> > [INFO] Installing /home/liqiang/ovirt-engine/ear/target/engine.ear to >>>>> > >>>>> /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear >>>>> > [INFO] Installing /home/liqiang/ovirt-engine/ear/pom.xml to >>>>> > >>>>> /home/liqiang/.m2/repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom >>>>> > [INFO] >>>>> > >>>>> ------------------------------------------------------------------------ >>>>> > [INFO] BUILD SUCCESS >>>>> > [INFO] >>>>> > >>>>> ------------------------------------------------------------------------ >>>>> > [INFO] Total time: 54.354s >>>>> > [INFO] Finished at: Fri Apr 19 10:48:39 EDT 2013 >>>>> > [INFO] Final Memory: 14M/191M >>>>> > [INFO] >>>>> > >>>>> ------------------------------------------------------------------------ >>>>> > ++++++++++++++++++++++ >>>>> > >>>>> > >>>>> > engine-upgrade >>>>> > COMMAND MESSAGE: >>>>> > ------------------------------------ >>>>> > [root at engine ~]# engine-upgrade >>>>> > >>>>> > Checking for updates... (This may take several minutes)...[ DONE ] >>>>> > 8 Updates available: >>>>> > * ovirt-engine-3.2.1-1.fc18.noarch >>>>> > * ovirt-engine-tools-3.2.1-1.fc18.noarch >>>>> > * ovirt-engine-backend-3.2.1-1.fc18.noarch >>>>> > * ovirt-engine-dbscripts-3.2.1-1.fc18.noarch >>>>> > * ovirt-engine-genericapi-3.2.1-1.fc18.noarch >>>>> > * ovirt-engine-restapi-3.2.1-1.fc18.noarch >>>>> > * ovirt-engine-userportal-3.2.1-1.fc18.noarch >>>>> > * ovirt-engine-webadmin-portal-3.2.1-1.fc18.noarch >>>>> > >>>>> > During the upgrade process, oVirt Engine will not be accessible. >>>>> > All existing running virtual machines will continue but you will not >>>>> be able >>>>> > to >>>>> > start or stop any new virtual machines during the process. >>>>> > >>>>> > Would you like to proceed? (yes|no): yes >>>>> > Stopping ovirt-engine service... [ DONE ] >>>>> > Stopping DB related services... [ DONE ] >>>>> > Pre-upgrade validations... [ DONE ] >>>>> > Backing Up Database... [ DONE ] >>>>> > Rename Database... [ DONE ] >>>>> > Updating rpms... [ DONE ] >>>>> > Updating Database... [ DONE ] >>>>> > Restore Database name... [ DONE ] >>>>> > Preparing CA... [ DONE ] >>>>> > Running post install configuration... [ DONE ] >>>>> > Starting ovirt-engine service... [ DONE ] >>>>> > >>>>> > oVirt Engine upgrade completed successfully! >>>>> > >>>>> > * Upgrade log available at >>>>> > /var/log/ovirt-engine/ovirt-engine-upgrade_2013_04_19_10_39_54.log >>>>> > * DB Backup available at >>>>> > >>>>> /var/lib/ovirt-engine/backups/ovirt-engine_db_backup_2013_04_19_10_39_54.sql >>>>> > ------------------------------------ >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > 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: From alonbl at redhat.com Sat Apr 20 07:31:17 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sat, 20 Apr 2013 03:31:17 -0400 (EDT) Subject: [Engine-devel] Why deploy failed? Please help me, thanks. In-Reply-To: References: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> Message-ID: <1791719115.1887621.1366443077463.JavaMail.root@redhat.com> ----- Original Message ----- > From: "??" > To: "Alon Bar-Lev" > Cc: engine-devel at ovirt.org > Sent: Saturday, April 20, 2013 5:10:13 AM > Subject: Re: [Engine-devel] Why deploy failed? Please help me, thanks. > > I have ERROR and Please help me ,thanks > > The first Upgrade is SUCCESS. > Please look the info. > > But engine-set is ERROR. > AIO: Adding Local Datacenter and cluster... [ ERROR ] > Error: could not create ovirtsdk API object > Please check log file > /var/log/ovirt-engine/engine-setup_2013_04_19_21_46_58.log for more > information If you don't need the all in one please remove it, better remove all rpms and create the repo as I outline in previous mail, and then install only ovirt-engine. From alonbl at redhat.com Sat Apr 20 07:29:26 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sat, 20 Apr 2013 03:29:26 -0400 (EDT) Subject: [Engine-devel] Why deploy failed? Please help me, thanks. In-Reply-To: References: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> <768646248.3461998.1366397184625.JavaMail.root@redhat.com> <2076251227.1825669.1366397383543.JavaMail.root@redhat.com> Message-ID: <418757633.1887569.1366442966903.JavaMail.root@redhat.com> ----- Original Message ----- > From: "??" > To: "Alon Bar-Lev" > Cc: "Vojtech Szocs" , engine-devel at ovirt.org > Sent: Saturday, April 20, 2013 3:59:23 AM > Subject: Re: [Engine-devel] Why deploy failed? Please help me, thanks. > > HI:all > > The first THANKS to all, > > I rpmbuild and create this files: > [root at engine noarch]# ls > ovirt-engine-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm > ovirt-engine-backend-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm > ovirt-engine-dbscripts-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm > ovirt-engine-restapi-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm > ovirt-engine-setup-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm > ovirt-engine-setup-plugin-allinone-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm > ovirt-engine-tools-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm > ovirt-engine-userportal-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm > ovirt-engine-webadmin-portal-3.3.0-0.2.master.20130419160733.fc18.noarch.rpm > > AND I COMMAND: > ++++++++++++++ > rpm -Uvh *.rpm > ++++++++++++++ > That command is OK? > > Sorry, I have not used rpm command for a long time. > If that rpm's command is ok, > What should I do next? Put all rpms in directory, let's say /var/lib/repos.local Run: # createrepo /var/lib/repos.local Add the following file: /etc/yum.repos.d/local.repo --- [local] name=local baseurl=file:///var/lib/repos.local enabled=1 gpgcheck=0 priority=1 protect=1 --- Then: yum install ovirt-engine From alonbl at redhat.com Sat Apr 20 07:30:10 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sat, 20 Apr 2013 03:30:10 -0400 (EDT) Subject: [Engine-devel] Why deploy failed? Please help me, thanks. In-Reply-To: References: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> Message-ID: <2063746983.1887593.1366443010873.JavaMail.root@redhat.com> ----- Original Message ----- > From: "??" > To: "Alon Bar-Lev" > Cc: engine-devel at ovirt.org > Sent: Saturday, April 20, 2013 4:11:39 AM > Subject: Re: [Engine-devel] Why deploy failed? Please help me, thanks. > > HI?Alon > > Thank your help, > > The question: > 1,Your email "Close the repository", What does it mean? I meant clone. > > 2,Your email "Alternatively, you can try out soon to be merged development > environment[1][2]" > Is it stable? > Can be used in a production environment? No. This is only for development if you want to add translation. > > Thanks again your help, From alonbl at redhat.com Sat Apr 20 07:32:16 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sat, 20 Apr 2013 03:32:16 -0400 (EDT) Subject: [Engine-devel] Why deploy failed? Please help me, thanks. In-Reply-To: References: <1779127764.1784498.1366385086969.JavaMail.root@redhat.com> Message-ID: <1173698361.1887638.1366443136100.JavaMail.root@redhat.com> ----- Original Message ----- > From: "??" > To: "Alon Bar-Lev" > Cc: engine-devel at ovirt.org > Sent: Saturday, April 20, 2013 5:37:41 AM > Subject: Re: [Engine-devel] Why deploy failed? Please help me, thanks. > > [root at engine ~]# rpm -qa | grep ^ovi* > ovirt-engine-backend-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-host-deploy-offline-1.1.0-0.0.master.20130418.git827d30b.fc18.noarch > ovirt-engine-setup-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-engine-sdk-3.3.0.1-1.20130418.gitfc5985e.fc18.noarch > ovirt-host-deploy-java-1.0.1-1.fc18.noarch > ovirt-iso-uploader-3.3.0-0.0.master.20130318.gitec3e5e7.fc18.noarch > ovirt-engine-restapi-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-engine-webadmin-portal-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-image-uploader-3.3.0-0.0.master.20130417.git13f9ba3.fc18.noarch > ovirt-engine-dbscripts-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-engine-userportal-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-engine-setup-plugin-allinone-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-host-deploy-1.0.1-1.fc18.noarch > ovirt-engine-tools-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-log-collector-3.3.0-0.0.master.20130417.git6a09d06.fc18.noarch > ovirt-engine-3.3.0-0.2.master.20130419160733.fc18.noarch > ovirt-engine-cli-3.2.0.11-1.fc18.noarch > ovirt-release-fedora-5-3.noarch If you need something for production, do not use master but the engine_3.2 branch. From alonbl at redhat.com Sat Apr 20 07:44:15 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sat, 20 Apr 2013 03:44:15 -0400 (EDT) Subject: [Engine-devel] Packaging and locales In-Reply-To: <1273160887.1887707.1366443365211.JavaMail.root@redhat.com> Message-ID: <134501763.97.1366443855648.JavaMail.root@redhat.com> Hello, >From recent thread I learned that we package locales within our main package, message bundles are going into jars, and by default we do not build them all. As this is GWT specific as far as I see in build, I have no real visibility of what happening. However, I do expect locales to be packaged and installed as separate packages, side by side with main package. Something like: # yum install ovirt-engine - provides en_US # yum install ovirt-engine-locale-zh_CN - will add zh_CN support. This ease maintenance, as these translations can be maintain using their own release cycle and even out of main tree. Any thoughts? Alon From iheim at redhat.com Sat Apr 20 14:49:47 2013 From: iheim at redhat.com (Itamar Heim) Date: Sat, 20 Apr 2013 17:49:47 +0300 Subject: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated In-Reply-To: References: Message-ID: <5172AB0B.1070803@redhat.com> On 04/19/2013 12:21 PM, Chen, Wei D wrote: > Hi All, > > Our second approach for trusted compute pools integration with oVirt seems more simple and sensible than previous VM level approach. Welcome any comments on our latest design. Thanks in advance. > > Link is here, http://www.ovirt.org/Trusted_compute_pools > > a few nits: 1. last updated date isn't updated... 2. from reading it top to bottom, hard to understand the 2nd approach is the one to be used and not the first (vm level). 3. cluster dialog - the 'trusted' should be a checkbox, not radio button, and should only be enabled if virt service was chosen. thanks, Itamar From ecohen at redhat.com Sat Apr 20 17:23:06 2013 From: ecohen at redhat.com (Einav Cohen) Date: Sat, 20 Apr 2013 13:23:06 -0400 (EDT) Subject: [Engine-devel] Packaging and locales In-Reply-To: <134501763.97.1366443855648.JavaMail.root@redhat.com> References: <134501763.97.1366443855648.JavaMail.root@redhat.com> Message-ID: <352205856.65834.1366478586880.JavaMail.root@redhat.com> Hi Alon, The available languages of oVirt's gwt-based portals are determined during compilation time. for run-time optimization purposes, the gwt-compiler executes a compilation-permutation per browser + per language. I assume that we can construct separate ovirt-engine[-*] packages, each one contains the gwt-based portals that were compiled only with the relevant locales (permutations). if we will do that, we won't be able to maintain all locales within the same web-application anymore (currently, the web-admin is a single web-application that supports all locales, same goes for the user-portal) - doing a separate web-application per locale probably makes more sense. also: could be trivial to do, but need to keep in mind that for every code-change, we will need to issue an update for each one of the ovirt-engine[-*] packages, and somehow make sure that the user will "yum update" *all* packages that he originally "yum install"ed, in order to avoid applications in different locales going out-of-sync. ---- Thanks, Einav ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Vojtech Szocs" , "Einav Cohen" , "Juan Hernandez" , > "Yair Zaslavsky" , "Alexander Wels" > Cc: "engine-devel" > Sent: Saturday, April 20, 2013 3:44:15 AM > Subject: Packaging and locales > > Hello, > > From recent thread I learned that we package locales within our main package, > message bundles are going into jars, and by default we do not build them > all. > > As this is GWT specific as far as I see in build, I have no real visibility > of what happening. > > However, I do expect locales to be packaged and installed as separate > packages, side by side with main package. > > Something like: > # yum install ovirt-engine - provides en_US > # yum install ovirt-engine-locale-zh_CN - will add zh_CN support. > > This ease maintenance, as these translations can be maintain using their own > release cycle and even out of main tree. > > Any thoughts? > Alon > From alonbl at redhat.com Sat Apr 20 18:54:23 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sat, 20 Apr 2013 14:54:23 -0400 (EDT) Subject: [Engine-devel] Packaging and locales In-Reply-To: <352205856.65834.1366478586880.JavaMail.root@redhat.com> References: <134501763.97.1366443855648.JavaMail.root@redhat.com> <352205856.65834.1366478586880.JavaMail.root@redhat.com> Message-ID: <893472814.15580.1366484063868.JavaMail.root@redhat.com> Hi! ----- Original Message ----- > From: "Einav Cohen" > To: "Alon Bar-Lev" , "Vojtech Szocs" , "Alexander Wels" > Cc: "Juan Hernandez" , "Yair Zaslavsky" , "engine-devel" > > Sent: Saturday, April 20, 2013 8:23:06 PM > Subject: Re: Packaging and locales > > Hi Alon, > > The available languages of oVirt's gwt-based portals are determined during > compilation time. > for run-time optimization purposes, the gwt-compiler executes a > compilation-permutation per > browser + per language. Hmmm... this what I was afraid of... > I assume that we can construct separate ovirt-engine[-*] packages, each one > contains the gwt-based > portals that were compiled only with the relevant locales (permutations). > > if we will do that, we won't be able to maintain all locales within the same > web-application > anymore (currently, the web-admin is a single web-application that supports > all locales, same > goes for the user-portal) - doing a separate web-application per locale > probably makes more sense. > > also: could be trivial to do, but need to keep in mind that for every > code-change, we will need > to issue an update for each one of the ovirt-engine[-*] packages, and somehow > make sure that > the user will "yum update" *all* packages that he originally "yum install"ed, > in order to avoid > applications in different locales going out-of-sync. Oh... this what I fear... if permutation include code + locale then this is no go for this approach. The separate package should contain locale only, so at worse case scenario you get locale C as default. Let's say going modular is too complicated for gwt based application... however, any reason why we do not build all locales by default? For development we can limit number of permutations, but default rpmbuild -tb should build all available locales. Thanks! Alon > > ---- > Thanks, > Einav > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "Vojtech Szocs" , "Einav Cohen" , > > "Juan Hernandez" , > > "Yair Zaslavsky" , "Alexander Wels" > > Cc: "engine-devel" > > Sent: Saturday, April 20, 2013 3:44:15 AM > > Subject: Packaging and locales > > > > Hello, > > > > From recent thread I learned that we package locales within our main > > package, > > message bundles are going into jars, and by default we do not build them > > all. > > > > As this is GWT specific as far as I see in build, I have no real visibility > > of what happening. > > > > However, I do expect locales to be packaged and installed as separate > > packages, side by side with main package. > > > > Something like: > > # yum install ovirt-engine - provides en_US > > # yum install ovirt-engine-locale-zh_CN - will add zh_CN support. > > > > This ease maintenance, as these translations can be maintain using their > > own > > release cycle and even out of main tree. > > > > Any thoughts? > > Alon > > > From ecohen at redhat.com Sat Apr 20 19:12:08 2013 From: ecohen at redhat.com (Einav Cohen) Date: Sat, 20 Apr 2013 15:12:08 -0400 (EDT) Subject: [Engine-devel] Packaging and locales In-Reply-To: <893472814.15580.1366484063868.JavaMail.root@redhat.com> References: <134501763.97.1366443855648.JavaMail.root@redhat.com> <352205856.65834.1366478586880.JavaMail.root@redhat.com> <893472814.15580.1366484063868.JavaMail.root@redhat.com> Message-ID: <1893637382.109441.1366485128030.JavaMail.root@redhat.com> > ----- Original Message ----- > From: "Alon Bar-Lev" > Sent: Saturday, April 20, 2013 2:54:23 PM > > > Hi! > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Alon Bar-Lev" , "Vojtech Szocs" > > , "Alexander Wels" > > Cc: "Juan Hernandez" , "Yair Zaslavsky" > > , "engine-devel" > > > > Sent: Saturday, April 20, 2013 8:23:06 PM > > Subject: Re: Packaging and locales > > > > Hi Alon, > > > > The available languages of oVirt's gwt-based portals are determined during > > compilation time. > > for run-time optimization purposes, the gwt-compiler executes a > > compilation-permutation per > > browser + per language. > > Hmmm... this what I was afraid of... > > > I assume that we can construct separate ovirt-engine[-*] packages, each one > > contains the gwt-based > > portals that were compiled only with the relevant locales (permutations). > > > > if we will do that, we won't be able to maintain all locales within the > > same > > web-application > > anymore (currently, the web-admin is a single web-application that supports > > all locales, same > > goes for the user-portal) - doing a separate web-application per locale > > probably makes more sense. > > > > also: could be trivial to do, but need to keep in mind that for every > > code-change, we will need > > to issue an update for each one of the ovirt-engine[-*] packages, and > > somehow > > make sure that > > the user will "yum update" *all* packages that he originally "yum > > install"ed, > > in order to avoid > > applications in different locales going out-of-sync. > > Oh... this what I fear... if permutation include code + locale then this is > no go for this approach. > The separate package should contain locale only, so at worse case scenario > you get locale C as default. > > Let's say going modular is too complicated for gwt based application... > however, any reason why we do not build all locales by default? For > development we can limit number of permutations, but default rpmbuild -tb > should build all available locales. when you are asking "why we do not build all locales by default?" I understand that you are referring specifically to an rpmbuild build, and NOT to a devel-time mvn build that a full-time ovirt-engine-GUI-maintainer performs 5 times a day, at least... so if I understood you correctly - indeed, I agree that the default "rpmbuild" should build with all available locales, assuming this is a non-frequent action, so the person performing it typically won't care if it takes some extra time, especially if it means that he will eventually gain a couple of extra available locales. > > Thanks! > Alon > > > > > ---- > > Thanks, > > Einav > > > > ----- Original Message ----- > > > From: "Alon Bar-Lev" > > > To: "Vojtech Szocs" , "Einav Cohen" > > > , > > > "Juan Hernandez" , > > > "Yair Zaslavsky" , "Alexander Wels" > > > > > > Cc: "engine-devel" > > > Sent: Saturday, April 20, 2013 3:44:15 AM > > > Subject: Packaging and locales > > > > > > Hello, > > > > > > From recent thread I learned that we package locales within our main > > > package, > > > message bundles are going into jars, and by default we do not build them > > > all. > > > > > > As this is GWT specific as far as I see in build, I have no real > > > visibility > > > of what happening. > > > > > > However, I do expect locales to be packaged and installed as separate > > > packages, side by side with main package. > > > > > > Something like: > > > # yum install ovirt-engine - provides en_US > > > # yum install ovirt-engine-locale-zh_CN - will add zh_CN support. > > > > > > This ease maintenance, as these translations can be maintain using their > > > own > > > release cycle and even out of main tree. > > > > > > Any thoughts? > > > Alon > > > > > > From alonbl at redhat.com Sat Apr 20 19:21:32 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sat, 20 Apr 2013 15:21:32 -0400 (EDT) Subject: [Engine-devel] Packaging and locales In-Reply-To: <1893637382.109441.1366485128030.JavaMail.root@redhat.com> References: <134501763.97.1366443855648.JavaMail.root@redhat.com> <352205856.65834.1366478586880.JavaMail.root@redhat.com> <893472814.15580.1366484063868.JavaMail.root@redhat.com> <1893637382.109441.1366485128030.JavaMail.root@redhat.com> Message-ID: <297089971.16141.1366485692456.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Alon Bar-Lev" > Cc: "Vojtech Szocs" , "Alexander Wels" , "Juan Hernandez" , > "Yair Zaslavsky" , "engine-devel" > Sent: Saturday, April 20, 2013 10:12:08 PM > Subject: Re: Packaging and locales > > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > Sent: Saturday, April 20, 2013 2:54:23 PM > > > > > > Hi! > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Alon Bar-Lev" , "Vojtech Szocs" > > > , "Alexander Wels" > > > Cc: "Juan Hernandez" , "Yair Zaslavsky" > > > , "engine-devel" > > > > > > Sent: Saturday, April 20, 2013 8:23:06 PM > > > Subject: Re: Packaging and locales > > > > > > Hi Alon, > > > > > > The available languages of oVirt's gwt-based portals are determined > > > during > > > compilation time. > > > for run-time optimization purposes, the gwt-compiler executes a > > > compilation-permutation per > > > browser + per language. > > > > Hmmm... this what I was afraid of... > > > > > I assume that we can construct separate ovirt-engine[-*] packages, each > > > one > > > contains the gwt-based > > > portals that were compiled only with the relevant locales (permutations). > > > > > > if we will do that, we won't be able to maintain all locales within the > > > same > > > web-application > > > anymore (currently, the web-admin is a single web-application that > > > supports > > > all locales, same > > > goes for the user-portal) - doing a separate web-application per locale > > > probably makes more sense. > > > > > > also: could be trivial to do, but need to keep in mind that for every > > > code-change, we will need > > > to issue an update for each one of the ovirt-engine[-*] packages, and > > > somehow > > > make sure that > > > the user will "yum update" *all* packages that he originally "yum > > > install"ed, > > > in order to avoid > > > applications in different locales going out-of-sync. > > > > Oh... this what I fear... if permutation include code + locale then this is > > no go for this approach. > > The separate package should contain locale only, so at worse case scenario > > you get locale C as default. > > > > Let's say going modular is too complicated for gwt based application... > > however, any reason why we do not build all locales by default? For > > development we can limit number of permutations, but default rpmbuild -tb > > should build all available locales. > > when you are asking "why we do not build all locales by default?" I > understand > that you are referring specifically to an rpmbuild build, and NOT to a > devel-time > mvn build that a full-time ovirt-engine-GUI-maintainer performs 5 times a > day, at least... > so if I understood you correctly - indeed, I agree that the default > "rpmbuild" should > build with all available locales, assuming this is a non-frequent action, so > the > person performing it typically won't care if it takes some extra time, > especially if it > means that he will eventually gain a couple of extra available locales. Yes, building via Makefile, developers use maven directly. Currently we have: BUILD_FLAGS=-P gwt-admin,gwt-user I guess it should be replaced it with: BUILD_FLAGS=-P gwt-admin,gwt-user,all-langs To build the entire feature set of application. > > > > > Thanks! > > Alon > > > > > > > > ---- > > > Thanks, > > > Einav > > > > > > ----- Original Message ----- > > > > From: "Alon Bar-Lev" > > > > To: "Vojtech Szocs" , "Einav Cohen" > > > > , > > > > "Juan Hernandez" , > > > > "Yair Zaslavsky" , "Alexander Wels" > > > > > > > > Cc: "engine-devel" > > > > Sent: Saturday, April 20, 2013 3:44:15 AM > > > > Subject: Packaging and locales > > > > > > > > Hello, > > > > > > > > From recent thread I learned that we package locales within our main > > > > package, > > > > message bundles are going into jars, and by default we do not build > > > > them > > > > all. > > > > > > > > As this is GWT specific as far as I see in build, I have no real > > > > visibility > > > > of what happening. > > > > > > > > However, I do expect locales to be packaged and installed as separate > > > > packages, side by side with main package. > > > > > > > > Something like: > > > > # yum install ovirt-engine - provides en_US > > > > # yum install ovirt-engine-locale-zh_CN - will add zh_CN support. > > > > > > > > This ease maintenance, as these translations can be maintain using > > > > their > > > > own > > > > release cycle and even out of main tree. > > > > > > > > Any thoughts? > > > > Alon > > > > > > > > > > From ecohen at redhat.com Sat Apr 20 19:25:41 2013 From: ecohen at redhat.com (Einav Cohen) Date: Sat, 20 Apr 2013 15:25:41 -0400 (EDT) Subject: [Engine-devel] Packaging and locales In-Reply-To: <297089971.16141.1366485692456.JavaMail.root@redhat.com> References: <134501763.97.1366443855648.JavaMail.root@redhat.com> <352205856.65834.1366478586880.JavaMail.root@redhat.com> <893472814.15580.1366484063868.JavaMail.root@redhat.com> <1893637382.109441.1366485128030.JavaMail.root@redhat.com> <297089971.16141.1366485692456.JavaMail.root@redhat.com> Message-ID: <1176554861.110685.1366485941221.JavaMail.root@redhat.com> > > Currently we have: > > BUILD_FLAGS=-P gwt-admin,gwt-user > > I guess it should be replaced it with: > > BUILD_FLAGS=-P gwt-admin,gwt-user,all-langs > > To build the entire feature set of application. exactly. From michal.skrivanek at redhat.com Sat Apr 20 20:13:04 2013 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Sat, 20 Apr 2013 22:13:04 +0200 Subject: [Engine-devel] storage overallocation ratio Message-ID: <1D680F89-5FE7-4A52-971E-0FAD298120FC@redhat.com> Hi, I was trying to find out how is this actually calculated. Doesn't look very straightforward?:) I'm curious about the following - vdsm reports something like truesize and apparentsize which IIUC should be distinct but then in engine, in backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/irsbroker/GetImageInfoVDSCommand.java it's written to the same engine property actual_size. That doesn't sound right. Can someone enlighten me please? Thanks, michal From iheim at redhat.com Sat Apr 20 20:52:51 2013 From: iheim at redhat.com (Itamar Heim) Date: Sat, 20 Apr 2013 23:52:51 +0300 Subject: [Engine-devel] Cloud-Init integration In-Reply-To: <5154D3BB.7080004@redhat.com> References: <5154D3BB.7080004@redhat.com> Message-ID: <51730023.30001@redhat.com> On 03/29/2013 01:35 AM, Greg Padgett wrote: > Hi Everyone, > > I'd like to propose a feature we've been doing some investigation into, > which is to integrate cloud-init support into oVirt. > > Cloud-init is used to help provision new Linux systems by setting the > hostname, ip, ssh keys, timezone, injecting files, and more. It's used > by OpenStack (amongst others) now, and has a lot of features that may be > helpful to our users. > > Details are still evolving, but for more info please see the wiki page: > > http://www.ovirt.org/Features/Cloud-Init_Integration > > All feedback is welcome! a few questions: - are you planning to save the info in the db by field, or as a single "blob"? maybe a better questions is are you going to persist it at all? - i'd be careful before passing any passwords (page mentions root password) - you'd need to not persist it unecrypted, identify it and clean it from all logs, etc. - hostname - should just assume the vm name? - timezone - is that different than the windows one? for a windows guest as well? Thanks, Itamar From iheim at redhat.com Sat Apr 20 21:14:37 2013 From: iheim at redhat.com (Itamar Heim) Date: Sun, 21 Apr 2013 00:14:37 +0300 Subject: [Engine-devel] FeatureSupported and compatibility versions In-Reply-To: <5149CBEC.9050507@redhat.com> References: <1886045500.2100242.1363591774667.JavaMail.root@redhat.com> <5146C52D.2090903@redhat.com> <5149CBEC.9050507@redhat.com> Message-ID: <5173053D.7060803@redhat.com> On 03/20/2013 04:47 PM, Shireesh Anjal wrote: > Why are we even storing this information in config? Is this something > that can be "configured" at customer site? some features can be disabled, and only enabled by someone aware of the implications of enabling them. that's apart of the versions they are supported at i guess From alonbl at redhat.com Sat Apr 20 22:26:42 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sat, 20 Apr 2013 18:26:42 -0400 (EDT) Subject: [Engine-devel] Packaging and locales In-Reply-To: <1176554861.110685.1366485941221.JavaMail.root@redhat.com> References: <134501763.97.1366443855648.JavaMail.root@redhat.com> <352205856.65834.1366478586880.JavaMail.root@redhat.com> <893472814.15580.1366484063868.JavaMail.root@redhat.com> <1893637382.109441.1366485128030.JavaMail.root@redhat.com> <297089971.16141.1366485692456.JavaMail.root@redhat.com> <1176554861.110685.1366485941221.JavaMail.root@redhat.com> Message-ID: <1074527234.22305.1366496802400.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Alon Bar-Lev" > Cc: "Vojtech Szocs" , "Alexander Wels" , "Juan Hernandez" , > "Yair Zaslavsky" , "engine-devel" > Sent: Saturday, April 20, 2013 10:25:41 PM > Subject: Re: Packaging and locales > > > > > Currently we have: > > > > BUILD_FLAGS=-P gwt-admin,gwt-user > > > > I guess it should be replaced it with: > > > > BUILD_FLAGS=-P gwt-admin,gwt-user,all-langs > > > > To build the entire feature set of application. > > exactly. > http://gerrit.ovirt.org/14083 From ovedo at redhat.com Sun Apr 21 05:41:50 2013 From: ovedo at redhat.com (Oved Ourfalli) Date: Sun, 21 Apr 2013 01:41:50 -0400 (EDT) Subject: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated In-Reply-To: <5172AB0B.1070803@redhat.com> References: <5172AB0B.1070803@redhat.com> Message-ID: <855522037.76793.1366522910666.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Wei D Chen" > Cc: "Oved Ourfalli" , "engine-devel at ovirt.org" > Sent: Saturday, April 20, 2013 5:49:47 PM > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated > > On 04/19/2013 12:21 PM, Chen, Wei D wrote: > > Hi All, > > > > Our second approach for trusted compute pools integration with oVirt seems > > more simple and sensible than previous VM level approach. Welcome any > > comments on our latest design. Thanks in advance. > > > > Link is here, http://www.ovirt.org/Trusted_compute_pools > > > > > > a few nits: > 1. last updated date isn't updated... > 2. from reading it top to bottom, hard to understand the 2nd approach is > the one to be used and not the first (vm level). > 3. cluster dialog - the 'trusted' should be a checkbox, not radio > button, and should only be enabled if virt service was chosen. > I'd also consider putting this property in a different side tab. Perhaps "Cluster policy" side tab would fit? (dividing it into two sections "scheduling policy" and "additional properties" or something similar. What do you think about that? > thanks, > Itamar > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mpastern at redhat.com Sun Apr 21 07:11:34 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 21 Apr 2013 10:11:34 +0300 Subject: [Engine-devel] Fwd: about ca-file In-Reply-To: <5172FC97.5020001@redhat.com> References: <000b01ce3440$36159b20$a240d160$@com> <5172FC97.5020001@redhat.com> Message-ID: <51739126.9040107@redhat.com> Hi, Please make sure [1] is exist on the file system and has right permissions, btw till you resolve this, you can connect to your site in insecure mode: 1. without host being validated raising --dont-validate-cert-chain flag 2. without no-certificate error being thrown raising --insecure flag (host will be validated once [1] is available/accessible by the shell) [1] /home/leaboy/ovirt_ca/ca_cear.pem On 04/20/2013 11:37 PM, Itamar Heim wrote: > > [Engine-devel] about ca-file.eml > > Subject: > [Engine-devel] about ca-file > From: > "wanglibo" > Date: > Mon, 8 Apr 2013 18:02:37 +0800 > > To: > > > > Hi,all: > > I?m in troubling with ca-file, who can tell me which the direction assigned to CA_FILE > > On the webpage http://www.ovirt.org/How_to_Connect_to_SPICE_Console_Without_Portal > > saided from the web: |wget -O ${CA_FILE}| |*http://${OVIRT}/ca.crt* | > > When I use overt-shell, I get ca.pem like this : > > > > [leaboy at Leaboy ovirt_ca]$ pwd > > /home/leaboy/ovirt_ca > > [leaboy at Leaboy ovirt_ca]$ wget -o ca-cert.pem http://192.168.1.181/ca.pem > > [leaboy at Leaboy ovirt_ca]$ ls > > ca-cert.pem > > [leaboy at Leaboy ovirt_ca]$ > > > > And then, I launched overt-shell and connect to overt-engine like this: > > > > ++++++++++++++++++++++++++++++++++++++++++ > > > > Welcome to oVirt shell > > > > ++++++++++++++++++++++++++++++++++++++++++ > > > > > > [oVirt shell (disconnected)]# *connect --url https://192.168.1.181 --user admin at internal --password 111111 --ca-file /home/leaboy/ovirt_ca/ca_cear.pem* > > > > > > error: [ERROR]::oVirt API connection failure, [Errno 185090050] _ssl.c:340: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib > > > > > > [oVirt shell (disconnected)]# > > > > > > _______________________________________________ > 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 omasad at redhat.com Sun Apr 21 07:13:30 2013 From: omasad at redhat.com (Ofri Masad) Date: Sun, 21 Apr 2013 03:13:30 -0400 (EDT) Subject: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated In-Reply-To: <855522037.76793.1366522910666.JavaMail.root@redhat.com> References: <5172AB0B.1070803@redhat.com> <855522037.76793.1366522910666.JavaMail.root@redhat.com> Message-ID: <590451846.29858.1366528410731.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Oved Ourfalli" > To: "Itamar Heim" , "Wei D Chen" > Cc: engine-devel at ovirt.org > Sent: Sunday, April 21, 2013 8:41:50 AM > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated > > > > ----- Original Message ----- > > From: "Itamar Heim" > > To: "Wei D Chen" > > Cc: "Oved Ourfalli" , "engine-devel at ovirt.org" > > > > Sent: Saturday, April 20, 2013 5:49:47 PM > > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools > > integration with oVirt has been updated > > > > On 04/19/2013 12:21 PM, Chen, Wei D wrote: > > > Hi All, > > > > > > Our second approach for trusted compute pools integration with oVirt > > > seems > > > more simple and sensible than previous VM level approach. Welcome any > > > comments on our latest design. Thanks in advance. > > > > > > Link is here, http://www.ovirt.org/Trusted_compute_pools > > > > > > > > > > a few nits: > > 1. last updated date isn't updated... > > 2. from reading it top to bottom, hard to understand the 2nd approach is > > the one to be used and not the first (vm level). > > 3. cluster dialog - the 'trusted' should be a checkbox, not radio > > button, and should only be enabled if virt service was chosen. > > > > I'd also consider putting this property in a different side tab. Perhaps > "Cluster policy" side tab would fit? (dividing it into two sections > "scheduling policy" and "additional properties" or something similar. > > What do you think about that? > > > thanks, > > Itamar Hi, One more thing we need to think about for the second approach - aggregated query. On engine start we need to determine the trust state of all the hosts. sending a separate query for each host will overload the attestation host and the network. an initial aggregated query needs to be send when the engine starts. Same thing can happen after management network fail and so on. Maybe we can run a quartz job every x minutes, checking if a large part of the hosts in the cluster (like 30%) are untrusted - in that case run the aggregated query. Ofri > > _______________________________________________ > > 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 Apr 21 07:20:17 2013 From: iheim at redhat.com (Itamar Heim) Date: Sun, 21 Apr 2013 10:20:17 +0300 Subject: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated In-Reply-To: <590451846.29858.1366528410731.JavaMail.root@redhat.com> References: <5172AB0B.1070803@redhat.com> <855522037.76793.1366522910666.JavaMail.root@redhat.com> <590451846.29858.1366528410731.JavaMail.root@redhat.com> Message-ID: <51739331.1020503@redhat.com> On 04/21/2013 10:13 AM, Ofri Masad wrote: > Hi, > One more thing we need to think about for the second approach - aggregated query. On engine start we need to determine the trust state of all the hosts. sending a separate query for each host will overload the attestation host and the network. an initial aggregated query needs to be send when the engine starts. > Same thing can happen after management network fail and so on. > Maybe we can run a quartz job every x minutes, checking if a large part of the hosts in the cluster (like 30%) are untrusted - in that case run the aggregated query. are we sure this optimization is needed? how heavy/latent is the call to the attestation service? From omasad at redhat.com Sun Apr 21 07:29:05 2013 From: omasad at redhat.com (Ofri Masad) Date: Sun, 21 Apr 2013 03:29:05 -0400 (EDT) Subject: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated In-Reply-To: <51739331.1020503@redhat.com> References: <5172AB0B.1070803@redhat.com> <855522037.76793.1366522910666.JavaMail.root@redhat.com> <590451846.29858.1366528410731.JavaMail.root@redhat.com> <51739331.1020503@redhat.com> Message-ID: <1965040641.30114.1366529345380.JavaMail.root@redhat.com> Dave, If I'm not mistaking, there is a big difference between separated queries to the attestation server and aggregated one? Is it true? Thanks, Ofri ----- Original Message ----- > From: "Itamar Heim" > To: "Ofri Masad" > Cc: "Oved Ourfalli" , "Wei D Chen" , engine-devel at ovirt.org > Sent: Sunday, April 21, 2013 10:20:17 AM > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated > > On 04/21/2013 10:13 AM, Ofri Masad wrote: > > Hi, > > One more thing we need to think about for the second approach - aggregated > > query. On engine start we need to determine the trust state of all the > > hosts. sending a separate query for each host will overload the > > attestation host and the network. an initial aggregated query needs to be > > send when the engine starts. > > Same thing can happen after management network fail and so on. > > Maybe we can run a quartz job every x minutes, checking if a large part of > > the hosts in the cluster (like 30%) are untrusted - in that case run the > > aggregated query. > > are we sure this optimization is needed? > how heavy/latent is the call to the attestation service? > From emesika at redhat.com Sun Apr 21 08:51:45 2013 From: emesika at redhat.com (Eli Mesika) Date: Sun, 21 Apr 2013 04:51:45 -0400 (EDT) Subject: [Engine-devel] Changes in DB scripts that need your attension In-Reply-To: <1106985479.1467239.1366310580033.JavaMail.root@redhat.com> References: <14647780.2516361.1366276783416.JavaMail.root@redhat.com> <582991960.1253157.1366277204064.JavaMail.root@redhat.com> <1452414632.2545412.1366278246728.JavaMail.root@redhat.com> <1743617805.2548737.1366278791486.JavaMail.root@redhat.com> <922844857.1260857.1366279106732.JavaMail.root@redhat.com> <1106985479.1467239.1366310580033.JavaMail.root@redhat.com> Message-ID: <1482339528.81937.1366534305502.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Eli Mesika" > Cc: "engine-devel" > Sent: Thursday, April 18, 2013 9:43:00 PM > Subject: Re: [Engine-devel] Changes in DB scripts that need your attension > > > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "Eli Mesika" > > Cc: "engine-devel" > > Sent: Thursday, April 18, 2013 12:58:26 PM > > Subject: Re: [Engine-devel] Changes in DB scripts that need your attension > > > > > > > > ----- Original Message ----- > > > From: "Eli Mesika" > > > To: "Alon Bar-Lev" > > > Cc: "engine-devel" > > > Sent: Thursday, April 18, 2013 12:53:11 PM > > > Subject: Re: [Engine-devel] Changes in DB scripts that need your > > > attension > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Eli Mesika" > > > > To: "Alon Bar-Lev" > > > > Cc: "engine-devel" > > > > Sent: Thursday, April 18, 2013 12:44:06 PM > > > > Subject: Re: [Engine-devel] Changes in DB scripts that need your > > > > attension > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Alon Bar-Lev" > > > > > To: "Eli Mesika" > > > > > Cc: "engine-devel" > > > > > Sent: Thursday, April 18, 2013 12:26:44 PM > > > > > Subject: Re: [Engine-devel] Changes in DB scripts that need your > > > > > attension > > > > > > > > > > Hi, > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Eli Mesika" > > > > > > To: "engine-devel" > > > > > > Sent: Thursday, April 18, 2013 12:19:43 PM > > > > > > Subject: [Engine-devel] Changes in DB scripts that need your > > > > > > attension > > > > > > > > > > > > Hi > > > > > > > > > > > > As part of solving > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=947344 > > > > > > I > > > > > > am > > > > > > doing the following changes: > > > > > > > > > > > > 1) Create all *.md5 files in /tmp/db > > > > > > > > > > Please use mkstemp or equivalent to create unique temp directory. > > > > > > > > OK, will use mktemp -d for that > > > > > > > > > > > > > > > 2) Create db log files by default under /var/log/ovirt-engine/db > > > > > > > > > > Please allow to override log location and/or output logs to stdout. > > > > > This will make it easier to run it within installer so that the log > > > > > will > > > > > be > > > > > available at installer log. > > > > > > > > > > > > All scripts supports the -l LOGFILE flag > > > > > > > > > > > > > > > 3) Do not automatically create a *.schema file that represent the > > > > > > up-to-date > > > > > > schema (after all upgrades took place) > > > > > > A new utility script exportDbSchema.sh will be available for > > > > > > that > > > > > > (manual > > > > > > only, no auto-generation schema) > > > > > > > > > > > > In order that DB scripts in development environment will keep > > > > > > working, > > > > > > please > > > > > > do > > > > > > > > > > > > > sudo mkdir -p /var/log/ovirt-engine/db > > > > > > > sudo chmod 777 /var/log/ovirt-engine/db > > > > > > > > > > 777 access permission is not something that should exist in system > > > > > anywhere, > > > > > well apart of /tmp and /tmp is marked using 't' attribute. > > > > > > Missed that in my prev reply > > > anyway , do whatever is needed so that the user that access the scripts > > > in > > > dbscripts has r/w/ permisssions on /var/log/ovirt-engine/db > > > since this is only for development, each developer will decide how to do > > > that.... > > > > OK... I will check this with the new development environment[1] > > > > [1] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer > > Hi, > > Where can I find the patch? I cannot see this in gerrit nor reference in > bug#947344 This was pushed only today :http://gerrit.ovirt.org/#/c/14090/ > > Alon > From wei.d.chen at intel.com Sun Apr 21 13:00:55 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Sun, 21 Apr 2013 13:00:55 +0000 Subject: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated In-Reply-To: <1965040641.30114.1366529345380.JavaMail.root@redhat.com> References: <5172AB0B.1070803@redhat.com> <855522037.76793.1366522910666.JavaMail.root@redhat.com> <590451846.29858.1366528410731.JavaMail.root@redhat.com> <51739331.1020503@redhat.com> <1965040641.30114.1366529345380.JavaMail.root@redhat.com> Message-ID: Ofri, Absolutely right, aggregated query has a significantly time improve compared to separated queries. I agree a aggregated query on engine's starting. Is it possible to invoke attestation service in engine's initialization code block instead of "quartz job"? Is there any class similar with " InitVdsOnUpCommand " for engine's initialization? Best Regards, Dave Chen -----Original Message----- From: Ofri Masad [mailto:omasad at redhat.com] Sent: Sunday, April 21, 2013 3:29 PM To: Chen, Wei D Cc: Oved Ourfalli; engine-devel at ovirt.org; Itamar Heim Subject: Re: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated Dave, If I'm not mistaking, there is a big difference between separated queries to the attestation server and aggregated one? Is it true? Thanks, Ofri ----- Original Message ----- > From: "Itamar Heim" > To: "Ofri Masad" > Cc: "Oved Ourfalli" , "Wei D Chen" > , engine-devel at ovirt.org > Sent: Sunday, April 21, 2013 10:20:17 AM > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools > integration with oVirt has been updated > > On 04/21/2013 10:13 AM, Ofri Masad wrote: > > Hi, > > One more thing we need to think about for the second approach - > > aggregated query. On engine start we need to determine the trust > > state of all the hosts. sending a separate query for each host will > > overload the attestation host and the network. an initial aggregated > > query needs to be send when the engine starts. > > Same thing can happen after management network fail and so on. > > Maybe we can run a quartz job every x minutes, checking if a large > > part of the hosts in the cluster (like 30%) are untrusted - in that > > case run the aggregated query. > > are we sure this optimization is needed? > how heavy/latent is the call to the attestation service? > From dfediuck at redhat.com Sun Apr 21 15:58:01 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Sun, 21 Apr 2013 11:58:01 -0400 (EDT) Subject: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated In-Reply-To: References: <5172AB0B.1070803@redhat.com> <855522037.76793.1366522910666.JavaMail.root@redhat.com> <590451846.29858.1366528410731.JavaMail.root@redhat.com> <51739331.1020503@redhat.com> <1965040641.30114.1366529345380.JavaMail.root@redhat.com> Message-ID: <2082103465.271823.1366559881373.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Wei D Chen" > To: "Ofri Masad" > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > Sent: Sunday, April 21, 2013 4:00:55 PM > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated > > Ofri, > > Absolutely right, aggregated query has a significantly time improve compared > to separated queries. I agree a aggregated query on engine's starting. Is it > possible to invoke attestation service in engine's initialization code block > instead of "quartz job"? Is there any class similar with " > InitVdsOnUpCommand " for engine's initialization? > > Best Regards, > Dave Chen > org.ovirt.engine.core.bll.Backend.Initialize() Note you cannot block this method while waiting for results. Instead I suggest you fire a one-time background request from this method. > -----Original Message----- > From: Ofri Masad [mailto:omasad at redhat.com] > Sent: Sunday, April 21, 2013 3:29 PM > To: Chen, Wei D > Cc: Oved Ourfalli; engine-devel at ovirt.org; Itamar Heim > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools > integration with oVirt has been updated > > Dave, > > If I'm not mistaking, there is a big difference between separated queries to > the attestation server and aggregated one? > Is it true? > > Thanks, > Ofri > > ----- Original Message ----- > > From: "Itamar Heim" > > To: "Ofri Masad" > > Cc: "Oved Ourfalli" , "Wei D Chen" > > , engine-devel at ovirt.org > > Sent: Sunday, April 21, 2013 10:20:17 AM > > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools > > integration with oVirt has been updated > > > > On 04/21/2013 10:13 AM, Ofri Masad wrote: > > > Hi, > > > One more thing we need to think about for the second approach - > > > aggregated query. On engine start we need to determine the trust > > > state of all the hosts. sending a separate query for each host will > > > overload the attestation host and the network. an initial aggregated > > > query needs to be send when the engine starts. > > > Same thing can happen after management network fail and so on. > > > Maybe we can run a quartz job every x minutes, checking if a large > > > part of the hosts in the cluster (like 30%) are untrusted - in that > > > case run the aggregated query. > > > > are we sure this optimization is needed? > > how heavy/latent is the call to the attestation service? > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From yzaslavs at redhat.com Mon Apr 22 03:48:11 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Sun, 21 Apr 2013 23:48:11 -0400 (EDT) Subject: [Engine-devel] Location of findbugs filter.xml file In-Reply-To: <51703C7E.2030002@redhat.com> References: <969455724.3725819.1366293346372.JavaMail.root@redhat.com> <1309930797.20107146.1366293483425.JavaMail.root@redhat.com> <51703C7E.2030002@redhat.com> Message-ID: <525085286.207980.1366602491793.JavaMail.root@redhat.com> Following this short vote, I have decided to adopt an approach in which we will use findbugs with the maven plugin on a per module basis, as some of you have suggested. An example for bll can be found here - http://gerrit.ovirt.org/#/c/14110/3 ----- Original Message ----- > From: "Michael Pasternak" > To: "Oved Ourfalli" > Cc: "Yair Zaslavsky" , "engine-devel" > Sent: Thursday, April 18, 2013 9:33:34 PM > Subject: Re: [Engine-devel] Location of findbugs filter.xml file > > On 04/18/2013 04:58 PM, Oved Ourfalli wrote: > > > > > > ----- Original Message ----- > >> From: "Yair Zaslavsky" > >> To: "engine-devel" > >> Sent: Thursday, April 18, 2013 4:55:46 PM > >> Subject: [Engine-devel] Location of findbugs filter.xml file > >> > >> Hi all, > >> I sent a patch upstream to add findbugs filter that will filter out bug > >> reports that we decided that are not bugs. > >> We have a debate on whether to have the findbugs filter definition in the > >> root pom.xml or to put it in the jenkins jobs repo and treat it as an > >> external tool. > >> I would like to hear opinions about what you think should be the proper > >> location > >> > > Putting it in the root pom.xml file will allow running filtered findbugs > > using maven, without the need to use jenkins, so I'd go with that > > approach. > > +1 > > > > >> Thanks, > >> Yair > >> _______________________________________________ > >> 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 > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > From yzaslavs at redhat.com Mon Apr 22 06:07:39 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Mon, 22 Apr 2013 02:07:39 -0400 (EDT) Subject: [Engine-devel] Question about reports generating when running mvn site Message-ID: <2136904006.225781.1366610859263.JavaMail.root@redhat.com> Hi all, It seems that generating all the reports when running mvn:site takes quite some time. Do we really need all these reports? Here is a snippet from the execution - [INFO] Generating "About" report --- maven-project-info-reports-plugin:2.6 [INFO] Generating "Project Team" report --- maven-project-info-reports-plugin:2.6 [INFO] Generating "Dependency Information" report --- maven-project-info-reports-plugin:2.6 [INFO] Generating "Dependency Management" report --- maven-project-info-reports-plugin:2.6 [INFO] Generating "Project Plugins" report --- maven-project-info-reports-plugin:2.6 [INFO] Generating "Continuous Integration" report --- maven-project-info-reports-plugin:2.6 [INFO] Generating "Issue Tracking" report --- maven-project-info-reports-plugin:2.6 [INFO] Generating "Source Repository" report --- maven-project-info-reports-plugin:2.6 [INFO] Generating "Dependency Convergence" report --- maven-project-info-reports-plugin:2.6 [INFO] Generating "Project License" report --- maven-project-info-reports-plugin:2.6 [INFO] Generating "Plugin Management" report --- maven-project-info-reports-plugin:2.6 [INFO] Generating "Distribution Management" report --- maven-project-info-reports-plugin:2.6 [INFO] Generating "Project Summary" report --- maven-project-info-reports-plugin:2.6 [INFO] Generating "Mailing Lists" report --- maven-project-info-reports-plugin:2.6 [INFO] Generating "Dependencies" report --- maven-project-info-reports-plugin:2.6 These reports are being generated when I run mvn site in order to generate a find-bugs report. Many thanks, Yair From yzaslavs at redhat.com Mon Apr 22 06:49:01 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Mon, 22 Apr 2013 02:49:01 -0400 (EDT) Subject: [Engine-devel] Question about reports generating when running mvn site In-Reply-To: <1683386960.232129.1366612512659.JavaMail.root@redhat.com> References: <2136904006.225781.1366610859263.JavaMail.root@redhat.com> <303426705.252254.1366612235726.JavaMail.root@redhat.com> <1683386960.232129.1366612512659.JavaMail.root@redhat.com> Message-ID: <1378589252.250613.1366613341380.JavaMail.root@redhat.com> Mike came up with a simpler solution - mvn findbugs:findbugs - from root pom Works like a charm. Many thanks! ----- Original Message ----- > From: "Yair Zaslavsky" > To: "Mike Kolesnik" > Sent: Monday, April 22, 2013 9:35:12 AM > Subject: Re: [Engine-devel] Question about reports generating when running mvn site > > No, > I will try. > Thanks. > > > ----- Original Message ----- > > From: "Mike Kolesnik" > > To: "Yair Zaslavsky" > > Sent: Monday, April 22, 2013 9:30:35 AM > > Subject: Re: [Engine-devel] Question about reports generating when running > > mvn site > > > > have you tried > > > > mvn findbugs:findbugs > > > > ? > > > > Regards, > > Mike > > > > ----- Original Message ----- > > > Hi all, > > > It seems that generating all the reports when running mvn:site takes > > > quite > > > some time. > > > > > > Do we really need all these reports? > > > > > > Here is a snippet from the execution - > > > > > > [INFO] Generating "About" report --- > > > maven-project-info-reports-plugin:2.6 > > > [INFO] Generating "Project Team" report --- > > > maven-project-info-reports-plugin:2.6 > > > [INFO] Generating "Dependency Information" report --- > > > maven-project-info-reports-plugin:2.6 > > > [INFO] Generating "Dependency Management" report --- > > > maven-project-info-reports-plugin:2.6 > > > [INFO] Generating "Project Plugins" report --- > > > maven-project-info-reports-plugin:2.6 > > > [INFO] Generating "Continuous Integration" report --- > > > maven-project-info-reports-plugin:2.6 > > > [INFO] Generating "Issue Tracking" report --- > > > maven-project-info-reports-plugin:2.6 > > > [INFO] Generating "Source Repository" report --- > > > maven-project-info-reports-plugin:2.6 > > > [INFO] Generating "Dependency Convergence" report --- > > > maven-project-info-reports-plugin:2.6 > > > [INFO] Generating "Project License" report --- > > > maven-project-info-reports-plugin:2.6 > > > [INFO] Generating "Plugin Management" report --- > > > maven-project-info-reports-plugin:2.6 > > > [INFO] Generating "Distribution Management" report --- > > > maven-project-info-reports-plugin:2.6 > > > [INFO] Generating "Project Summary" report --- > > > maven-project-info-reports-plugin:2.6 > > > [INFO] Generating "Mailing Lists" report --- > > > maven-project-info-reports-plugin:2.6 > > > [INFO] Generating "Dependencies" report --- > > > maven-project-info-reports-plugin:2.6 > > > > > > > > > These reports are being generated when I run mvn site in order to > > > generate > > > a > > > find-bugs report. > > > > > > > > > Many thanks, > > > Yair > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > From danken at redhat.com Mon Apr 22 09:45:17 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Mon, 22 Apr 2013 12:45:17 +0300 Subject: [Engine-devel] [vdsm] Snapshots with RAM feature In-Reply-To: References: <319368954.768893.1365494496958.JavaMail.root@redhat.com> <720BEF86-8C5F-43AC-8EE2-6CCD05AD8107@redhat.com> <20130410084312.GD32275@redhat.com> <20130411120126.GF16563@redhat.com> Message-ID: <20130422094517.GE17085@redhat.com> On Fri, Apr 19, 2013 at 10:30:19AM +0200, Michal Skrivanek wrote: > > On 11 Apr 2013, at 14:01, Dan Kenigsberg wrote: > > > On Wed, Apr 10, 2013 at 11:43:12AM +0300, Dan Kenigsberg wrote: > >> On Wed, Apr 10, 2013 at 02:12:20AM -0400, Michal Skrivanek wrote: > >>> > >>> > >>> On 9 Apr 2013, at 10:01, Arik Hadas wrote: > >>> > >>>> Hi All, > >>>> > >>>> The proposed feature will make it possible to run a VM which was reverted to live snapshot > >>>> or created from live snapshot with the same memory state as it was at the moment the live > >>>> snapshot was taken. > >>>> > >>>> http://www.ovirt.org/Features/RAM_Snapshots > >>>> > >>>> All feedback is welcome! > >>> Nice! > >> > >> (I prefer to inline the document when discussing it) > >> > >>> VDSM changes > >>> > >>> Default parameter will be added to vmSnapshot verb that maps string to string. > >>> The map will include two keys for now: > >>> 'mode' that can be mapped to 'disks_only' or 'disks_memory' to > >>> indicate if memory state should be saved. > >>> 'memVol' that will be mapped to a string that represent the two > >>> volums that will be used to save the memory state and the > >>> VM configuration. The default map will include the > >>> mapping of 'mode':'disks_only' only. > >>> > >>> If the 'mode' value in the map decribed above is > >>> 'disks_memory' the first volume in 'memVol' will be > >>> passed to libvirt in order to dump the memory to > >>> it, and the second volume in 'memVol' will be used > >>> to save the VM configuration (the same way it is > >>> done for hibernate operation). > >> > >> This definition of 'memVol' would not allow saving the state to another > >> storage domain, or a direct lun or whatever. > >> > >> I suggest that you have two independet arguments, say memVol and > >> vmConfVol. Both may have the standard pool-domain-image-volume quartet, > >> or a lun specification, or a local path. > > > > On a second thought - why should we even store vmConf on vmConfVol? Why > > not keep it in Engine's db? > you trust the engine db? I don't:-) RAM snapshot absolutely needs to correspond to the actual VM configuration otherwise it can crash the VM or corrupt > > > Sure, we do this for hibernation. But it creates a lot of inconsistency pains. > > Engine sends one vmconf to vdsm, but vdsm ignores it and starts the VM > > with an old vmconf that was stored besides the hibernation volume. On > > top of this, it wastes some GiB of disk space for each snapshot. > Pardon my lack of knowledge in this area, how/where is it wasting that much? If I recall correctly, Engine has a 1GiB minimum for the size of the LV that it can create, for one odd reason or another. vmConf takes less than 1% of that. > > > I think it is time to have Engine keep a snapshot of its vm config > > whenever it takes a snapshot - live or offline. > I'm really not sure about the impacts when it goes out of sync. I'd > rather have the VM resumed and configuration in engine > updated/overwritten afterwards in first stats update than screwing up > the VM I do not know why you trust the Engine DB less than the content of an LV. Sure, keeping a copy of vmConf near the RAM snapshot, may be useful in case of a total DB crash, or a manual vm-export. But it duplicates data, and the fact that it may be possible to do it this way, is not a good reason to avoid making Engine aware of that vmConf is a snapshot property, not a vm property. It is a shame that we cannot add/remove a disk/nic/video card to a VM without affecting history retroactively. Dan. From dfediuck at redhat.com Mon Apr 22 12:53:25 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Mon, 22 Apr 2013 08:53:25 -0400 (EDT) Subject: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated In-Reply-To: <855522037.76793.1366522910666.JavaMail.root@redhat.com> References: <5172AB0B.1070803@redhat.com> <855522037.76793.1366522910666.JavaMail.root@redhat.com> Message-ID: <739105840.645251.1366635205384.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Oved Ourfalli" > To: "Itamar Heim" , "Wei D Chen" > Cc: engine-devel at ovirt.org > Sent: Sunday, April 21, 2013 8:41:50 AM > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated > > > > ----- Original Message ----- > > From: "Itamar Heim" > > To: "Wei D Chen" > > Cc: "Oved Ourfalli" , "engine-devel at ovirt.org" > > > > Sent: Saturday, April 20, 2013 5:49:47 PM > > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools > > integration with oVirt has been updated > > > > On 04/19/2013 12:21 PM, Chen, Wei D wrote: > > > Hi All, > > > > > > Our second approach for trusted compute pools integration with oVirt > > > seems > > > more simple and sensible than previous VM level approach. Welcome any > > > comments on our latest design. Thanks in advance. > > > > > > Link is here, http://www.ovirt.org/Trusted_compute_pools > > > > > > > > > > a few nits: > > 1. last updated date isn't updated... > > 2. from reading it top to bottom, hard to understand the 2nd approach is > > the one to be used and not the first (vm level). > > 3. cluster dialog - the 'trusted' should be a checkbox, not radio > > button, and should only be enabled if virt service was chosen. > > > > I'd also consider putting this property in a different side tab. Perhaps > "Cluster policy" side tab would fit? (dividing it into two sections > "scheduling policy" and "additional properties" or something similar. > > What do you think about that? > I prefer such optimizations to wait for our scheduling work to be more advanced. > > thanks, > > Itamar > > _______________________________________________ > > 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 vfeenstr at redhat.com Mon Apr 22 15:25:30 2013 From: vfeenstr at redhat.com (Vinzenz Feenstra) Date: Mon, 22 Apr 2013 17:25:30 +0200 Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <25893083.7640290.1363211722007.JavaMail.root@redhat.com> References: <25893083.7640290.1363211722007.JavaMail.root@redhat.com> Message-ID: <5175566A.3010203@redhat.com> I have left this for a while without continuing because I had to focus on other things. However this is still in progress :-) On 03/13/2013 10:55 PM, Ayal Baron wrote: > > ----- Original Message ----- >> >> ----- Original Message ----- >>> From: "Ayal Baron" >>> To: "Saggi Mizrahi" >>> Cc: engine-devel at ovirt.org, vdsm-devel at lists.fedorahosted.org, >>> "Vinzenz Feenstra" >>> Sent: Wednesday, March 13, 2013 5:39:24 PM >>> Subject: Re: [vdsm] [Engine-devel] Proposal VDSM <=> Engine Data >>> Statistics Retrieval Optimization >>> >>> >>> >>> ----- Original Message ----- >>>> I am completely against this. >>>> It make the return value differ according to input which >>>> is a big no no when talking about type safe APIs. >>>> >>>> The only reason we have this problem is because there is this >>>> thing against making multiple calls. Which is totally contra productive because multiple calls, if properly split up, will actually lead to less data sent for frequent needed data calls. And the others shall be triggered when necessary. >>>> >>>> Just split it up. >>>> getVmRuntimeStats() - transient things like mem and cpu% >>>> getVmInformation() - (semi)static things like disk\networking >>>> layout >>>> etc. >>>> Each updated at different intervals. >>> +1 on splitting the data up into 2 separate API calls. >>> You could potentially add a checksum (md5, or any other way) of the >>> "static" data to getVmRuntimeStats and not bother even with polling >>> the VmInformation if this hasn't changed. Then you could poll as >>> often as you'd like the stats and immediately see if you also need >>> to retrieve VmInfo or not (you rarely would). >> +1 To Ayal's suggestion >> except that instead of the engine hashing the data VDSM sends the >> key which is opaque to the engine. >> This can be a local timestap or a generation number. > Of course vdsm does the hash, otherwise you'd need to pass all the data to engine which would beat the purpose. We need the hash if we can't have dynamic content. Generation numbers aren't really helpful as every call aggregates the statistics data newly, at the moment at least. >> But, we might want to consider that when we add events polling >> becomes (much) less frequent so maybe it'll be an overkill. > You'd still need to compare versions of the data in vdsm and send only if it changed. If you don't persist what was received last then potentially you could have a monday morning effect where upon on system startup you'd be sending everything. So I still think you'd want to have the hash. We do a hash already on the XML and include it in the getStats response. Hashes should show enough difference. Now to the non-dynamic responses and 'type-safe' API: If we would go for non dynamic responses we would need for sure 5 new API calls to achieve some gain on the amount of data sent. *getAllVmRuntimeStats() "returns a map of vmId/data pairs for all vms"* # All the time changing data which is needed by the oVirt Engine, or so often changing that it does not make sense # to place it anywhere else { VmId: { cpuSys --> Could be potentially summarized cpuUser -/ memUsage elapsedTime, status statsAge hashes = { conf, # Hased information of the XML (This one is called "hash" in getStats()) info, # Hashed information of semi static items statusHash: # Hashed information of items with are likely to change however not that often guestDetails: # Hashed value of the guest details (applicationList, network information) } } **getVmStatuses([vmId1, vmId2, ...])*****"Returns a vmId/data pair for each vm requested"** *# This data does not change that often and can be retrieved on demand once the hash changes return { vmId: { timeOffset, monitorResponse clientIp, lastLogin, username, session, guestIPs, } } *getAllVmDeviceStatistics():**"Returns a vmId/data pair for all vms"* # This data has to be requested all the time however in lower intervals (e.g. every 5 minutes) # And is usually needed for all the VMs anyway return { vmId: { network, disksUsage, # Might be improved by summarizing? disks, balloonInfo, memoryStats } } *getVmInfo([vmId1, vmId2, ...]) "Returns a vmId/data pair for each vm requested" * # Basically this should be almost constant, except if there have been changes like migrations, pausing, errors etc return { vmId: { acpiEnable, vmType, guestName, guestOS, kvmEnable, pauseCode, displayIp, displayPort, displaySecurePort, pid, } } *getVmGuestDetails*([vmId1, vmId2, ...]) # Data which changes seldom and these changes can be reflected in the hash when this needs to be requested # This data is really only necessary when it really has been changed or needs to be refreshed for whatever reason. return { vmId: { appsList, netIfaces, } } > > >>>> ----- Original Message ----- >>>>> From: "Vinzenz Feenstra" >>>>> To: vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org >>>>> Sent: Thursday, March 7, 2013 6:25:54 AM >>>>> Subject: [Engine-devel] Proposal VDSM <=> Engine Data >>>>> Statistics >>>>> Retrieval Optimization >>>>> >>>>> >>>>> Please find the prettier version on the wiki: >>>>> http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval >>>>> >>>>> Proposal VDSM - Engine Data Statistics Retrieval >>>>> VDSM <=> Engine data retrieval optimization >>>>> Motivation: >>>>> >>>>> >>>>> Currently the RHEVM engine is polling the a lot of data from >>>>> VDSM >>>>> every 15 seconds. This should be optimized and the amount of >>>>> data >>>>> requested should be more specific. >>>>> >>>>> For each VM the data currently contains much more information >>>>> than >>>>> actually needed which blows up the size of the XML content >>>>> quite >>>>> big. We could optimize this by splitting the reply on the >>>>> getVmStats >>>>> based on the request of the engine into sections. For this >>>>> reason >>>>> Omer Frenkel and me have split up the data into parts based on >>>>> their >>>>> usage. >>>>> >>>>> This data can and usually does change during the lifetime of >>>>> the >>>>> VM. >>>>> Rarely Changed: >>>>> >>>>> >>>>> This data is change not very frequent and it should be enough >>>>> to >>>>> update this only once in a while. Most commonly this data >>>>> changes >>>>> after changes made in the UI or after a migration of the VM to >>>>> another Host. Status = Running acpiEnable = true vmType = kvm >>>>> guestName = W864GUESTAGENTT displayType = qxl guestOs = Win 8 >>>>> kvmEnable = true # this should be constant and never changed >>>>> pauseCode = NOERR monitorResponse = 0 session = Locked # unused >>>>> netIfaces = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', >>>>> 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': >>>>> ['10.34.60.148'], >>>>> 'hw': '00:1a:4a:22:3c:db'}] appsList = ['RHEV-Tools 3.2.4', >>>>> 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 >>>>> 3.2.2', >>>>> 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 >>>>> 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB >>>>> 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] pid = >>>>> 11314 >>>>> guestIPs = 10.34.60.148 # duplicated info displayIp = 0 >>>>> displayPort >>>>> = 5902 displaySecurePort = 5903 username = user at W864GUESTAGENTT >>>>> clientIp = lastLogin = 1361976900.67 Often Changed: >>>>> >>>>> >>>>> This data is changed quite often however it is not necessary to >>>>> update this data every 15 seconds. As this is cumulative data >>>>> and >>>>> reflects the current status, and it does not need to be >>>>> snapshotted >>>>> every 15 seconds to retrieve statistics. The data can be >>>>> retrieved >>>>> in much more generous time slices. (e.g. Every 5 minutes) >>>>> network >>>>> = >>>>> {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', >>>>> 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': >>>>> '0.0', >>>>> 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': >>>>> 'vnet1'}} disksUsage = [{'path': 'c:\\', 'total': >>>>> '64055406592', >>>>> 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': >>>>> '3490912256', 'fs': 'UDF', 'used': '3490912256'}] timeOffset = >>>>> 14422 >>>>> elapsedTime = 68591 hash = 2335461227228498964 statsAge = 0.09 >>>>> # >>>>> unused Often Changed but unused >>>>> >>>>> >>>>> This data does not seem to be used in the engine at all. It is >>>>> not >>>>> even used in the data warehouse. memoryStats = {'swap_out': >>>>> '0', >>>>> 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', >>>>> 'pageflt': >>>>> '0', 'mem_total': '2096736', 'mem_unused': '1466884'} >>>>> balloonInfo >>>>> = >>>>> {'balloon_max': 2097152, 'balloon_cur': 2097152} disks = >>>>> {'vda': >>>>> {'readLatency': '0', 'apparentsize': '64424509440', >>>>> 'writeLatency': >>>>> '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', >>>>> 'flushLatency': '156549', 'readRate': '0.00', 'truesize': >>>>> '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': >>>>> '0', >>>>> 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', >>>>> 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} Very >>>>> frequent uppdates needed by webadmin portal: >>>>> >>>>> >>>>> This data is mostly needed for the webadmin portal and might be >>>>> required to be updated quite often. An exception here is the >>>>> statsAge field, which seems to be unused by the Engine. This >>>>> data >>>>> could be requested every 15 seconds to keep things as they are >>>>> now. >>>>> cpuSys = 2.32 cpuUser = 1.34 memUsage = 30 Proposed Solution >>>>> for >>>>> VDSM & Engine: >>>>> >>>>> >>>>> We will introduce new optional parameters to getVmStats, >>>>> getAllVmStats and list to allow a finer grained specification >>>>> of >>>>> data which should be included. >>>>> >>>>> Parameter: statsType = (getVmStats, getAllVmStats >>>>> only) >>>>> Allowed values: >>>>> >>>>> * full (default to keep backwards compatibility) >>>>> * app-list (Just send the application list) >>>>> * rare (include everything from rarely changed to very >>>>> frequent) >>>>> * often (include everything from often changed to very >>>>> frequent) >>>>> * frequent (only send the very frequently changed items) >>>>> >>>>> >>>>> >>>>> Parameter: clientId = The client id is specified by >>>>> the >>>>> client and should be unique however constantly used. >>>>> >>>>> Parameter: diff = In combination with the clientId >>>>> VDSM >>>>> will send only differences to the previous request from the >>>>> named >>>>> clientId. (if diff=true) >>>>> >>>>> >>>>> Additional Change: >>>>> >>>>> >>>>> Besides the introduction of the new parameters for list, >>>>> getVmStats >>>>> and getAllVmStats it might make sense to include a hash for the >>>>> appList into the rarely changed section of the response which >>>>> would >>>>> allow to identify changes and avoid having to sent the complete >>>>> appList every so often and only if the hash known to the client >>>>> is >>>>> outdated. >>>>> >>>>> Note: The appList (Application List) reported by the guest >>>>> agent >>>>> could be fully implemented on request only, as long as the >>>>> guest >>>>> agent installed supports this. As there seems to be a request >>>>> to >>>>> have the complete list of installed applications on all guests >>>>> this >>>>> data could be quite extensive and a huge list. On the other >>>>> hand >>>>> this data is only rarely visible and therefore it should not be >>>>> requested all the time and only on demand. Improvement of the >>>>> Guest >>>>> Agent: >>>>> >>>>> >>>>> As part of the proposed solution it is necessary to improve the >>>>> guest >>>>> agent as well. For the full application list there should be >>>>> implemented a caching system which will be fully reactive and >>>>> should >>>>> not poll the application list for example all the time. The >>>>> guest >>>>> can create a prepared data file containing all data in the JSON >>>>> format (as used for the communication with VDSM via VIO) and >>>>> just >>>>> have to read that file from disk and directly sends it to VDSM. >>>>> However it is quite possible that this list is to big and it >>>>> might >>>>> have to be chunked into pieces. (Multiple messages, which would >>>>> have >>>>> to be supported by VDSM then as well) The solution for this is >>>>> to >>>>> make VDSM request this data and it will retrieve the data >>>>> necessary >>>>> on request only. -- >>>>> Regards, >>>>> >>>>> Vinzenz Feenstra | Senior Software Engineer >>>>> RedHat Engineering Virtualization R & D >>>>> Phone: +420 532 294 625 >>>>> IRC: vfeenstr or evilissimo >>>>> >>>>> Better technology. Faster innovation. Powered by community >>>>> collaboration. >>>>> See how it works at redhat.com >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>>> _______________________________________________ >>>> vdsm-devel mailing list >>>> vdsm-devel at lists.fedorahosted.org >>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel >>>> -- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhornyak at redhat.com Mon Apr 22 17:27:00 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Mon, 22 Apr 2013 13:27:00 -0400 (EDT) Subject: [Engine-devel] some cleanup In-Reply-To: <1877095684.518054.1366651316032.JavaMail.root@redhat.com> Message-ID: <297057013.520179.1366651620901.JavaMail.root@redhat.com> Hi, Some of my patches are waiting for a brave reviewer to +2 them :) - entity cleanups http://gerrit.ovirt.org/13531 http://gerrit.ovirt.org/13705 http://gerrit.ovirt.org/13940 http://gerrit.ovirt.org/13705 - command cleanups http://gerrit.ovirt.org/13945 http://gerrit.ovirt.org/13946 http://gerrit.ovirt.org/13947 Thx, Laszlo From abaron at redhat.com Mon Apr 22 20:39:48 2013 From: abaron at redhat.com (Ayal Baron) Date: Mon, 22 Apr 2013 16:39:48 -0400 (EDT) Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <5175566A.3010203@redhat.com> References: <25893083.7640290.1363211722007.JavaMail.root@redhat.com> <5175566A.3010203@redhat.com> Message-ID: <1061131108.891713.1366663188606.JavaMail.root@redhat.com> ----- Original Message ----- > I have left this for a while without continuing because I had to focus > on other things. However this is still in progress :-) Are you writing patches? (if so, what solution are you pursuing) > On 03/13/2013 10:55 PM, Ayal Baron wrote: > > > > ----- Original Message ----- > >> > >> ----- Original Message ----- > >>> From: "Ayal Baron" > >>> To: "Saggi Mizrahi" > >>> Cc: engine-devel at ovirt.org, vdsm-devel at lists.fedorahosted.org, > >>> "Vinzenz Feenstra" > >>> Sent: Wednesday, March 13, 2013 5:39:24 PM > >>> Subject: Re: [vdsm] [Engine-devel] Proposal VDSM <=> Engine Data > >>> Statistics Retrieval Optimization > >>> > >>> > >>> > >>> ----- Original Message ----- > >>>> I am completely against this. > >>>> It make the return value differ according to input which > >>>> is a big no no when talking about type safe APIs. > >>>> > >>>> The only reason we have this problem is because there is this > >>>> thing against making multiple calls. > Which is totally contra productive because multiple calls, if properly > split up, will actually lead to less data sent for frequent needed data > calls. And the others shall be triggered when necessary. > >>>> > >>>> Just split it up. > >>>> getVmRuntimeStats() - transient things like mem and cpu% > >>>> getVmInformation() - (semi)static things like disk\networking > >>>> layout > >>>> etc. > >>>> Each updated at different intervals. > >>> +1 on splitting the data up into 2 separate API calls. > >>> You could potentially add a checksum (md5, or any other way) of the > >>> "static" data to getVmRuntimeStats and not bother even with polling > >>> the VmInformation if this hasn't changed. Then you could poll as > >>> often as you'd like the stats and immediately see if you also need > >>> to retrieve VmInfo or not (you rarely would). > >> +1 To Ayal's suggestion > >> except that instead of the engine hashing the data VDSM sends the > >> key which is opaque to the engine. > >> This can be a local timestap or a generation number. > > Of course vdsm does the hash, otherwise you'd need to pass all the data to > > engine which would beat the purpose. > We need the hash if we can't have dynamic content. Generation numbers > aren't really helpful as every call aggregates the statistics data > newly, at the moment at least. > >> But, we might want to consider that when we add events polling > >> becomes (much) less frequent so maybe it'll be an overkill. > > You'd still need to compare versions of the data in vdsm and send only if > > it changed. If you don't persist what was received last then potentially > > you could have a monday morning effect where upon on system startup you'd > > be sending everything. So I still think you'd want to have the hash. > We do a hash already on the XML and include it in the getStats response. > Hashes should show enough difference. > > Now to the non-dynamic responses and 'type-safe' API: If we would go for > non dynamic responses we would need for sure 5 new API calls to achieve > some gain on the amount of data sent. > > *getAllVmRuntimeStats() "returns a map of vmId/data pairs for all vms"* > # All the time changing data which is needed by the oVirt Engine, or so > often changing that it does not make sense > # to place it anywhere else > { > VmId: { > cpuSys --> Could be potentially summarized > cpuUser -/ > memUsage > elapsedTime, > status > statsAge > > hashes = { > conf, # Hased information of the XML > (This one is called "hash" in getStats()) > info, # Hashed information of semi > static items > statusHash: # Hashed information of items with are > likely to change however not that often > guestDetails: # Hashed value of the guest details > (applicationList, network information) > } > } > > **getVmStatuses([vmId1, vmId2, ...])*****"Returns a vmId/data pair for > each vm requested"** > *# This data does not change that often and can be retrieved on demand > once the hash changes > return { > vmId: { > timeOffset, > monitorResponse > clientIp, > lastLogin, > username, > session, > guestIPs, > } > } > > *getAllVmDeviceStatistics():**"Returns a vmId/data pair for all vms"* > # This data has to be requested all the time however in lower > intervals (e.g. every 5 minutes) > # And is usually needed for all the VMs anyway > return { > vmId: { > network, > disksUsage, # Might be improved by summarizing? > disks, > balloonInfo, > memoryStats > } > } > > *getVmInfo([vmId1, vmId2, ...]) "Returns a vmId/data pair for each vm > requested" > * # Basically this should be almost constant, except if there have > been changes like migrations, pausing, errors etc > return { > vmId: { > acpiEnable, > vmType, > guestName, > guestOS, > kvmEnable, > pauseCode, > displayIp, > displayPort, > displaySecurePort, > pid, > } > } > > *getVmGuestDetails*([vmId1, vmId2, ...]) > # Data which changes seldom and these changes can be reflected in > the hash when this needs to be requested > # This data is really only necessary when it really has been > changed or needs to be refreshed for whatever reason. > return { > vmId: { > appsList, > netIfaces, > } > } > > > > > > >>>> ----- Original Message ----- > >>>>> From: "Vinzenz Feenstra" > >>>>> To: vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org > >>>>> Sent: Thursday, March 7, 2013 6:25:54 AM > >>>>> Subject: [Engine-devel] Proposal VDSM <=> Engine Data > >>>>> Statistics > >>>>> Retrieval Optimization > >>>>> > >>>>> > >>>>> Please find the prettier version on the wiki: > >>>>> http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval > >>>>> > >>>>> Proposal VDSM - Engine Data Statistics Retrieval > >>>>> VDSM <=> Engine data retrieval optimization > >>>>> Motivation: > >>>>> > >>>>> > >>>>> Currently the RHEVM engine is polling the a lot of data from > >>>>> VDSM > >>>>> every 15 seconds. This should be optimized and the amount of > >>>>> data > >>>>> requested should be more specific. > >>>>> > >>>>> For each VM the data currently contains much more information > >>>>> than > >>>>> actually needed which blows up the size of the XML content > >>>>> quite > >>>>> big. We could optimize this by splitting the reply on the > >>>>> getVmStats > >>>>> based on the request of the engine into sections. For this > >>>>> reason > >>>>> Omer Frenkel and me have split up the data into parts based on > >>>>> their > >>>>> usage. > >>>>> > >>>>> This data can and usually does change during the lifetime of > >>>>> the > >>>>> VM. > >>>>> Rarely Changed: > >>>>> > >>>>> > >>>>> This data is change not very frequent and it should be enough > >>>>> to > >>>>> update this only once in a while. Most commonly this data > >>>>> changes > >>>>> after changes made in the UI or after a migration of the VM to > >>>>> another Host. Status = Running acpiEnable = true vmType = kvm > >>>>> guestName = W864GUESTAGENTT displayType = qxl guestOs = Win 8 > >>>>> kvmEnable = true # this should be constant and never changed > >>>>> pauseCode = NOERR monitorResponse = 0 session = Locked # unused > >>>>> netIfaces = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', > >>>>> 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': > >>>>> ['10.34.60.148'], > >>>>> 'hw': '00:1a:4a:22:3c:db'}] appsList = ['RHEV-Tools 3.2.4', > >>>>> 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 > >>>>> 3.2.2', > >>>>> 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 > >>>>> 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB > >>>>> 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] pid = > >>>>> 11314 > >>>>> guestIPs = 10.34.60.148 # duplicated info displayIp = 0 > >>>>> displayPort > >>>>> = 5902 displaySecurePort = 5903 username = user at W864GUESTAGENTT > >>>>> clientIp = lastLogin = 1361976900.67 Often Changed: > >>>>> > >>>>> > >>>>> This data is changed quite often however it is not necessary to > >>>>> update this data every 15 seconds. As this is cumulative data > >>>>> and > >>>>> reflects the current status, and it does not need to be > >>>>> snapshotted > >>>>> every 15 seconds to retrieve statistics. The data can be > >>>>> retrieved > >>>>> in much more generous time slices. (e.g. Every 5 minutes) > >>>>> network > >>>>> = > >>>>> {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', > >>>>> 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': > >>>>> '0.0', > >>>>> 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': > >>>>> 'vnet1'}} disksUsage = [{'path': 'c:\\', 'total': > >>>>> '64055406592', > >>>>> 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': > >>>>> '3490912256', 'fs': 'UDF', 'used': '3490912256'}] timeOffset = > >>>>> 14422 > >>>>> elapsedTime = 68591 hash = 2335461227228498964 statsAge = 0.09 > >>>>> # > >>>>> unused Often Changed but unused > >>>>> > >>>>> > >>>>> This data does not seem to be used in the engine at all. It is > >>>>> not > >>>>> even used in the data warehouse. memoryStats = {'swap_out': > >>>>> '0', > >>>>> 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', > >>>>> 'pageflt': > >>>>> '0', 'mem_total': '2096736', 'mem_unused': '1466884'} > >>>>> balloonInfo > >>>>> = > >>>>> {'balloon_max': 2097152, 'balloon_cur': 2097152} disks = > >>>>> {'vda': > >>>>> {'readLatency': '0', 'apparentsize': '64424509440', > >>>>> 'writeLatency': > >>>>> '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', > >>>>> 'flushLatency': '156549', 'readRate': '0.00', 'truesize': > >>>>> '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': > >>>>> '0', > >>>>> 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', > >>>>> 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} Very > >>>>> frequent uppdates needed by webadmin portal: > >>>>> > >>>>> > >>>>> This data is mostly needed for the webadmin portal and might be > >>>>> required to be updated quite often. An exception here is the > >>>>> statsAge field, which seems to be unused by the Engine. This > >>>>> data > >>>>> could be requested every 15 seconds to keep things as they are > >>>>> now. > >>>>> cpuSys = 2.32 cpuUser = 1.34 memUsage = 30 Proposed Solution > >>>>> for > >>>>> VDSM & Engine: > >>>>> > >>>>> > >>>>> We will introduce new optional parameters to getVmStats, > >>>>> getAllVmStats and list to allow a finer grained specification > >>>>> of > >>>>> data which should be included. > >>>>> > >>>>> Parameter: statsType = (getVmStats, getAllVmStats > >>>>> only) > >>>>> Allowed values: > >>>>> > >>>>> * full (default to keep backwards compatibility) > >>>>> * app-list (Just send the application list) > >>>>> * rare (include everything from rarely changed to very > >>>>> frequent) > >>>>> * often (include everything from often changed to very > >>>>> frequent) > >>>>> * frequent (only send the very frequently changed items) > >>>>> > >>>>> > >>>>> > >>>>> Parameter: clientId = The client id is specified by > >>>>> the > >>>>> client and should be unique however constantly used. > >>>>> > >>>>> Parameter: diff = In combination with the clientId > >>>>> VDSM > >>>>> will send only differences to the previous request from the > >>>>> named > >>>>> clientId. (if diff=true) > >>>>> > >>>>> > >>>>> Additional Change: > >>>>> > >>>>> > >>>>> Besides the introduction of the new parameters for list, > >>>>> getVmStats > >>>>> and getAllVmStats it might make sense to include a hash for the > >>>>> appList into the rarely changed section of the response which > >>>>> would > >>>>> allow to identify changes and avoid having to sent the complete > >>>>> appList every so often and only if the hash known to the client > >>>>> is > >>>>> outdated. > >>>>> > >>>>> Note: The appList (Application List) reported by the guest > >>>>> agent > >>>>> could be fully implemented on request only, as long as the > >>>>> guest > >>>>> agent installed supports this. As there seems to be a request > >>>>> to > >>>>> have the complete list of installed applications on all guests > >>>>> this > >>>>> data could be quite extensive and a huge list. On the other > >>>>> hand > >>>>> this data is only rarely visible and therefore it should not be > >>>>> requested all the time and only on demand. Improvement of the > >>>>> Guest > >>>>> Agent: > >>>>> > >>>>> > >>>>> As part of the proposed solution it is necessary to improve the > >>>>> guest > >>>>> agent as well. For the full application list there should be > >>>>> implemented a caching system which will be fully reactive and > >>>>> should > >>>>> not poll the application list for example all the time. The > >>>>> guest > >>>>> can create a prepared data file containing all data in the JSON > >>>>> format (as used for the communication with VDSM via VIO) and > >>>>> just > >>>>> have to read that file from disk and directly sends it to VDSM. > >>>>> However it is quite possible that this list is to big and it > >>>>> might > >>>>> have to be chunked into pieces. (Multiple messages, which would > >>>>> have > >>>>> to be supported by VDSM then as well) The solution for this is > >>>>> to > >>>>> make VDSM request this data and it will retrieve the data > >>>>> necessary > >>>>> on request only. -- > >>>>> Regards, > >>>>> > >>>>> Vinzenz Feenstra | Senior Software Engineer > >>>>> RedHat Engineering Virtualization R & D > >>>>> Phone: +420 532 294 625 > >>>>> IRC: vfeenstr or evilissimo > >>>>> > >>>>> Better technology. Faster innovation. Powered by community > >>>>> collaboration. > >>>>> See how it works at redhat.com > >>>>> _______________________________________________ > >>>>> Engine-devel mailing list > >>>>> Engine-devel at ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>>> > >>>> _______________________________________________ > >>>> vdsm-devel mailing list > >>>> vdsm-devel at lists.fedorahosted.org > >>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > >>>> > > > -- > Regards, > > Vinzenz Feenstra | Senior Software Engineer > RedHat Engineering Virtualization R & D > Phone: +420 532 294 625 > IRC: vfeenstr or evilissimo > > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > > From alonbl at redhat.com Mon Apr 22 22:15:01 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 22 Apr 2013 18:15:01 -0400 (EDT) Subject: [Engine-devel] rewrite the engine-notifier service wrapper In-Reply-To: <1038809629.371930.1366668436061.JavaMail.root@redhat.com> Message-ID: <439619200.374291.1366668901175.JavaMail.root@redhat.com> Hello, After finish to cleanup the engine-service to use downstream services and be portable to other distributions (upstart, openrc), we can use the same infrastructure for the engine notifier script. It is very similar to the engine-service in operation (running java), except it is written in bash instead of python and has no systemd support, and have its own configuration. What I suggest is to rewrite the notifier service in python and reuse the engine-service code. Also, drop the /etc/ovirt-engine/notifier/notifier.conf in favor of variables within the /etc/ovirt-engine/engine.conf[.d/*], this will provide a single point of configuration for all services. And of course proper systemd support and development environment support. Any comments? thoughts? Alon From vfeenstr at redhat.com Tue Apr 23 05:16:16 2013 From: vfeenstr at redhat.com (Vinzenz Feenstra) Date: Tue, 23 Apr 2013 07:16:16 +0200 Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <1061131108.891713.1366663188606.JavaMail.root@redhat.com> References: <25893083.7640290.1363211722007.JavaMail.root@redhat.com> <5175566A.3010203@redhat.com> <1061131108.891713.1366663188606.JavaMail.root@redhat.com> Message-ID: <51761920.9070007@redhat.com> On 04/22/2013 10:39 PM, Ayal Baron wrote: > > ----- Original Message ----- >> I have left this for a while without continuing because I had to focus >> on other things. However this is still in progress :-) > Are you writing patches? (if so, what solution are you pursuing) I haven't started writing patches for this particular thing yet, however I want to, but before I want to know that the approach will be acceptable and so I won't have to throw away work because it's not accepted by the project that way. My ultimate goal is to reduce the overall traffic and the amount of data the engine has to parse on a per Host basis. This can be achieved without having push notifications working already. Imagine that oVirt engine currently has to parse for 1000 VMs running, ~16MiB of XML data and that every 15 seconds. And that's just the result from getAllVmStats. Additionally it's polling every 2-3 seconds 'list' to retrieve the VmIds and statuses. Now I have split the values which the engine would return in getVmStats into groups based on how likely the are to change AND their size. getAllVmRuntimeStats() for example, returns the hashes to the different parts where it makes sense, however it won't give you the devices for example. Because the engine still has to poll that every 5 minutes or so to retrieve stats for the the data warehouse. I am personally for having push notifications properly implemented and working however the base of this idea is reducing parser and validation work and will help the engine backend to scale better. Especially it should theoretically reduce the load on the database as well, at least theoretically (I have no numbers for this one ;-)) > > >> On 03/13/2013 10:55 PM, Ayal Baron wrote: >>> ----- Original Message ----- >>>> ----- Original Message ----- >>>>> From: "Ayal Baron" >>>>> To: "Saggi Mizrahi" >>>>> Cc: engine-devel at ovirt.org, vdsm-devel at lists.fedorahosted.org, >>>>> "Vinzenz Feenstra" >>>>> Sent: Wednesday, March 13, 2013 5:39:24 PM >>>>> Subject: Re: [vdsm] [Engine-devel] Proposal VDSM <=> Engine Data >>>>> Statistics Retrieval Optimization >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> I am completely against this. >>>>>> It make the return value differ according to input which >>>>>> is a big no no when talking about type safe APIs. >>>>>> >>>>>> The only reason we have this problem is because there is this >>>>>> thing against making multiple calls. >> Which is totally contra productive because multiple calls, if properly >> split up, will actually lead to less data sent for frequent needed data >> calls. And the others shall be triggered when necessary. >>>>>> Just split it up. >>>>>> getVmRuntimeStats() - transient things like mem and cpu% >>>>>> getVmInformation() - (semi)static things like disk\networking >>>>>> layout >>>>>> etc. >>>>>> Each updated at different intervals. >>>>> +1 on splitting the data up into 2 separate API calls. >>>>> You could potentially add a checksum (md5, or any other way) of the >>>>> "static" data to getVmRuntimeStats and not bother even with polling >>>>> the VmInformation if this hasn't changed. Then you could poll as >>>>> often as you'd like the stats and immediately see if you also need >>>>> to retrieve VmInfo or not (you rarely would). >>>> +1 To Ayal's suggestion >>>> except that instead of the engine hashing the data VDSM sends the >>>> key which is opaque to the engine. >>>> This can be a local timestap or a generation number. >>> Of course vdsm does the hash, otherwise you'd need to pass all the data to >>> engine which would beat the purpose. >> We need the hash if we can't have dynamic content. Generation numbers >> aren't really helpful as every call aggregates the statistics data >> newly, at the moment at least. >>>> But, we might want to consider that when we add events polling >>>> becomes (much) less frequent so maybe it'll be an overkill. >>> You'd still need to compare versions of the data in vdsm and send only if >>> it changed. If you don't persist what was received last then potentially >>> you could have a monday morning effect where upon on system startup you'd >>> be sending everything. So I still think you'd want to have the hash. >> We do a hash already on the XML and include it in the getStats response. >> Hashes should show enough difference. >> >> Now to the non-dynamic responses and 'type-safe' API: If we would go for >> non dynamic responses we would need for sure 5 new API calls to achieve >> some gain on the amount of data sent. >> >> *getAllVmRuntimeStats() "returns a map of vmId/data pairs for all vms"* >> # All the time changing data which is needed by the oVirt Engine, or so >> often changing that it does not make sense >> # to place it anywhere else >> { >> VmId: { >> cpuSys --> Could be potentially summarized >> cpuUser -/ >> memUsage >> elapsedTime, >> status >> statsAge >> >> hashes = { >> conf, # Hased information of the XML >> (This one is called "hash" in getStats()) >> info, # Hashed information of semi >> static items >> statusHash: # Hashed information of items with are >> likely to change however not that often >> guestDetails: # Hashed value of the guest details >> (applicationList, network information) >> } >> } >> >> **getVmStatuses([vmId1, vmId2, ...])*****"Returns a vmId/data pair for >> each vm requested"** >> *# This data does not change that often and can be retrieved on demand >> once the hash changes >> return { >> vmId: { >> timeOffset, >> monitorResponse >> clientIp, >> lastLogin, >> username, >> session, >> guestIPs, >> } >> } >> >> *getAllVmDeviceStatistics():**"Returns a vmId/data pair for all vms"* >> # This data has to be requested all the time however in lower >> intervals (e.g. every 5 minutes) >> # And is usually needed for all the VMs anyway >> return { >> vmId: { >> network, >> disksUsage, # Might be improved by summarizing? >> disks, >> balloonInfo, >> memoryStats >> } >> } >> >> *getVmInfo([vmId1, vmId2, ...]) "Returns a vmId/data pair for each vm >> requested" >> * # Basically this should be almost constant, except if there have >> been changes like migrations, pausing, errors etc >> return { >> vmId: { >> acpiEnable, >> vmType, >> guestName, >> guestOS, >> kvmEnable, >> pauseCode, >> displayIp, >> displayPort, >> displaySecurePort, >> pid, >> } >> } >> >> *getVmGuestDetails*([vmId1, vmId2, ...]) >> # Data which changes seldom and these changes can be reflected in >> the hash when this needs to be requested >> # This data is really only necessary when it really has been >> changed or needs to be refreshed for whatever reason. >> return { >> vmId: { >> appsList, >> netIfaces, >> } >> } >> >>> >>>>>> ----- Original Message ----- >>>>>>> From: "Vinzenz Feenstra" >>>>>>> To: vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org >>>>>>> Sent: Thursday, March 7, 2013 6:25:54 AM >>>>>>> Subject: [Engine-devel] Proposal VDSM <=> Engine Data >>>>>>> Statistics >>>>>>> Retrieval Optimization >>>>>>> >>>>>>> >>>>>>> Please find the prettier version on the wiki: >>>>>>> http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval >>>>>>> >>>>>>> Proposal VDSM - Engine Data Statistics Retrieval >>>>>>> VDSM <=> Engine data retrieval optimization >>>>>>> Motivation: >>>>>>> >>>>>>> >>>>>>> Currently the RHEVM engine is polling the a lot of data from >>>>>>> VDSM >>>>>>> every 15 seconds. This should be optimized and the amount of >>>>>>> data >>>>>>> requested should be more specific. >>>>>>> >>>>>>> For each VM the data currently contains much more information >>>>>>> than >>>>>>> actually needed which blows up the size of the XML content >>>>>>> quite >>>>>>> big. We could optimize this by splitting the reply on the >>>>>>> getVmStats >>>>>>> based on the request of the engine into sections. For this >>>>>>> reason >>>>>>> Omer Frenkel and me have split up the data into parts based on >>>>>>> their >>>>>>> usage. >>>>>>> >>>>>>> This data can and usually does change during the lifetime of >>>>>>> the >>>>>>> VM. >>>>>>> Rarely Changed: >>>>>>> >>>>>>> >>>>>>> This data is change not very frequent and it should be enough >>>>>>> to >>>>>>> update this only once in a while. Most commonly this data >>>>>>> changes >>>>>>> after changes made in the UI or after a migration of the VM to >>>>>>> another Host. Status = Running acpiEnable = true vmType = kvm >>>>>>> guestName = W864GUESTAGENTT displayType = qxl guestOs = Win 8 >>>>>>> kvmEnable = true # this should be constant and never changed >>>>>>> pauseCode = NOERR monitorResponse = 0 session = Locked # unused >>>>>>> netIfaces = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', >>>>>>> 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': >>>>>>> ['10.34.60.148'], >>>>>>> 'hw': '00:1a:4a:22:3c:db'}] appsList = ['RHEV-Tools 3.2.4', >>>>>>> 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 >>>>>>> 3.2.2', >>>>>>> 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 >>>>>>> 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB >>>>>>> 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] pid = >>>>>>> 11314 >>>>>>> guestIPs = 10.34.60.148 # duplicated info displayIp = 0 >>>>>>> displayPort >>>>>>> = 5902 displaySecurePort = 5903 username = user at W864GUESTAGENTT >>>>>>> clientIp = lastLogin = 1361976900.67 Often Changed: >>>>>>> >>>>>>> >>>>>>> This data is changed quite often however it is not necessary to >>>>>>> update this data every 15 seconds. As this is cumulative data >>>>>>> and >>>>>>> reflects the current status, and it does not need to be >>>>>>> snapshotted >>>>>>> every 15 seconds to retrieve statistics. The data can be >>>>>>> retrieved >>>>>>> in much more generous time slices. (e.g. Every 5 minutes) >>>>>>> network >>>>>>> = >>>>>>> {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', >>>>>>> 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': >>>>>>> '0.0', >>>>>>> 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': >>>>>>> 'vnet1'}} disksUsage = [{'path': 'c:\\', 'total': >>>>>>> '64055406592', >>>>>>> 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': >>>>>>> '3490912256', 'fs': 'UDF', 'used': '3490912256'}] timeOffset = >>>>>>> 14422 >>>>>>> elapsedTime = 68591 hash = 2335461227228498964 statsAge = 0.09 >>>>>>> # >>>>>>> unused Often Changed but unused >>>>>>> >>>>>>> >>>>>>> This data does not seem to be used in the engine at all. It is >>>>>>> not >>>>>>> even used in the data warehouse. memoryStats = {'swap_out': >>>>>>> '0', >>>>>>> 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', >>>>>>> 'pageflt': >>>>>>> '0', 'mem_total': '2096736', 'mem_unused': '1466884'} >>>>>>> balloonInfo >>>>>>> = >>>>>>> {'balloon_max': 2097152, 'balloon_cur': 2097152} disks = >>>>>>> {'vda': >>>>>>> {'readLatency': '0', 'apparentsize': '64424509440', >>>>>>> 'writeLatency': >>>>>>> '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', >>>>>>> 'flushLatency': '156549', 'readRate': '0.00', 'truesize': >>>>>>> '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': >>>>>>> '0', >>>>>>> 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', >>>>>>> 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} Very >>>>>>> frequent uppdates needed by webadmin portal: >>>>>>> >>>>>>> >>>>>>> This data is mostly needed for the webadmin portal and might be >>>>>>> required to be updated quite often. An exception here is the >>>>>>> statsAge field, which seems to be unused by the Engine. This >>>>>>> data >>>>>>> could be requested every 15 seconds to keep things as they are >>>>>>> now. >>>>>>> cpuSys = 2.32 cpuUser = 1.34 memUsage = 30 Proposed Solution >>>>>>> for >>>>>>> VDSM & Engine: >>>>>>> >>>>>>> >>>>>>> We will introduce new optional parameters to getVmStats, >>>>>>> getAllVmStats and list to allow a finer grained specification >>>>>>> of >>>>>>> data which should be included. >>>>>>> >>>>>>> Parameter: statsType = (getVmStats, getAllVmStats >>>>>>> only) >>>>>>> Allowed values: >>>>>>> >>>>>>> * full (default to keep backwards compatibility) >>>>>>> * app-list (Just send the application list) >>>>>>> * rare (include everything from rarely changed to very >>>>>>> frequent) >>>>>>> * often (include everything from often changed to very >>>>>>> frequent) >>>>>>> * frequent (only send the very frequently changed items) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Parameter: clientId = The client id is specified by >>>>>>> the >>>>>>> client and should be unique however constantly used. >>>>>>> >>>>>>> Parameter: diff = In combination with the clientId >>>>>>> VDSM >>>>>>> will send only differences to the previous request from the >>>>>>> named >>>>>>> clientId. (if diff=true) >>>>>>> >>>>>>> >>>>>>> Additional Change: >>>>>>> >>>>>>> >>>>>>> Besides the introduction of the new parameters for list, >>>>>>> getVmStats >>>>>>> and getAllVmStats it might make sense to include a hash for the >>>>>>> appList into the rarely changed section of the response which >>>>>>> would >>>>>>> allow to identify changes and avoid having to sent the complete >>>>>>> appList every so often and only if the hash known to the client >>>>>>> is >>>>>>> outdated. >>>>>>> >>>>>>> Note: The appList (Application List) reported by the guest >>>>>>> agent >>>>>>> could be fully implemented on request only, as long as the >>>>>>> guest >>>>>>> agent installed supports this. As there seems to be a request >>>>>>> to >>>>>>> have the complete list of installed applications on all guests >>>>>>> this >>>>>>> data could be quite extensive and a huge list. On the other >>>>>>> hand >>>>>>> this data is only rarely visible and therefore it should not be >>>>>>> requested all the time and only on demand. Improvement of the >>>>>>> Guest >>>>>>> Agent: >>>>>>> >>>>>>> >>>>>>> As part of the proposed solution it is necessary to improve the >>>>>>> guest >>>>>>> agent as well. For the full application list there should be >>>>>>> implemented a caching system which will be fully reactive and >>>>>>> should >>>>>>> not poll the application list for example all the time. The >>>>>>> guest >>>>>>> can create a prepared data file containing all data in the JSON >>>>>>> format (as used for the communication with VDSM via VIO) and >>>>>>> just >>>>>>> have to read that file from disk and directly sends it to VDSM. >>>>>>> However it is quite possible that this list is to big and it >>>>>>> might >>>>>>> have to be chunked into pieces. (Multiple messages, which would >>>>>>> have >>>>>>> to be supported by VDSM then as well) The solution for this is >>>>>>> to >>>>>>> make VDSM request this data and it will retrieve the data >>>>>>> necessary >>>>>>> on request only. -- >>>>>>> Regards, >>>>>>> >>>>>>> Vinzenz Feenstra | Senior Software Engineer >>>>>>> RedHat Engineering Virtualization R & D >>>>>>> Phone: +420 532 294 625 >>>>>>> IRC: vfeenstr or evilissimo >>>>>>> >>>>>>> Better technology. Faster innovation. Powered by community >>>>>>> collaboration. >>>>>>> See how it works at redhat.com >>>>>>> _______________________________________________ >>>>>>> Engine-devel mailing list >>>>>>> Engine-devel at ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>> >>>>>> _______________________________________________ >>>>>> vdsm-devel mailing list >>>>>> vdsm-devel at lists.fedorahosted.org >>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel >>>>>> >> >> -- >> Regards, >> >> Vinzenz Feenstra | Senior Software Engineer >> RedHat Engineering Virtualization R & D >> Phone: +420 532 294 625 >> IRC: vfeenstr or evilissimo >> >> Better technology. Faster innovation. Powered by community collaboration. >> See how it works at redhat.com >> >> -- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From yzaslavs at redhat.com Tue Apr 23 07:07:39 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Tue, 23 Apr 2013 03:07:39 -0400 (EDT) Subject: [Engine-devel] rewrite the engine-notifier service wrapper In-Reply-To: <439619200.374291.1366668901175.JavaMail.root@redhat.com> References: <439619200.374291.1366668901175.JavaMail.root@redhat.com> Message-ID: <1507498443.799657.1366700859801.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alon Bar-Lev" > To: "engine-devel" > Cc: "Juan Hernandez" , "Simon Grinberg" > Sent: Tuesday, April 23, 2013 1:15:01 AM > Subject: [Engine-devel] rewrite the engine-notifier service wrapper > > Hello, > > After finish to cleanup the engine-service to use downstream services and be > portable to other distributions (upstart, openrc), we can use the same > infrastructure for the engine notifier script. > > It is very similar to the engine-service in operation (running java), except > it is written in bash instead of python and has no systemd support, and have > its own configuration. > > What I suggest is to rewrite the notifier service in python and reuse the > engine-service code. > > Also, drop the /etc/ovirt-engine/notifier/notifier.conf in favor of variables > within the /etc/ovirt-engine/engine.conf[.d/*], this will provide a single > point of configuration for all services. > > And of course proper systemd support and development environment support. > > Any comments? thoughts? > > Alon IMHO - +1 , the sooner the better - start with that and move to all the other bash scripts of the tools ;) > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From wei.d.chen at intel.com Tue Apr 23 07:29:28 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Tue, 23 Apr 2013 07:29:28 +0000 Subject: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated In-Reply-To: <739105840.645251.1366635205384.JavaMail.root@redhat.com> References: <5172AB0B.1070803@redhat.com> <855522037.76793.1366522910666.JavaMail.root@redhat.com> <739105840.645251.1366635205384.JavaMail.root@redhat.com> Message-ID: Our wiki page has changed according to your suggestion, that is, a checkbox is added for "Cluster policy" side tab. For details, pls check it from http://www.ovirt.org/Trusted_compute_pools. Best Regards, Dave Chen -----Original Message----- From: Doron Fediuck [mailto:dfediuck at redhat.com] Sent: Monday, April 22, 2013 8:53 PM To: Oved Ourfalli Cc: Itamar Heim; Chen, Wei D; engine-devel at ovirt.org Subject: Re: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated ----- Original Message ----- > From: "Oved Ourfalli" > To: "Itamar Heim" , "Wei D Chen" > > Cc: engine-devel at ovirt.org > Sent: Sunday, April 21, 2013 8:41:50 AM > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools > integration with oVirt has been updated > > > > ----- Original Message ----- > > From: "Itamar Heim" > > To: "Wei D Chen" > > Cc: "Oved Ourfalli" , "engine-devel at ovirt.org" > > > > Sent: Saturday, April 20, 2013 5:49:47 PM > > Subject: Re: [Engine-devel] Design wiki page for trusted compute > > pools integration with oVirt has been updated > > > > On 04/19/2013 12:21 PM, Chen, Wei D wrote: > > > Hi All, > > > > > > Our second approach for trusted compute pools integration with > > > oVirt seems more simple and sensible than previous VM level > > > approach. Welcome any comments on our latest design. Thanks in > > > advance. > > > > > > Link is here, http://www.ovirt.org/Trusted_compute_pools > > > > > > > > > > a few nits: > > 1. last updated date isn't updated... > > 2. from reading it top to bottom, hard to understand the 2nd > > approach is the one to be used and not the first (vm level). > > 3. cluster dialog - the 'trusted' should be a checkbox, not radio > > button, and should only be enabled if virt service was chosen. > > > > I'd also consider putting this property in a different side tab. > Perhaps "Cluster policy" side tab would fit? (dividing it into two > sections "scheduling policy" and "additional properties" or something similar. > > What do you think about that? > I prefer such optimizations to wait for our scheduling work to be more advanced. > > thanks, > > Itamar > > _______________________________________________ > > 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 mkublin at redhat.com Tue Apr 23 07:30:09 2013 From: mkublin at redhat.com (Michael Kublin) Date: Tue, 23 Apr 2013 03:30:09 -0400 (EDT) Subject: [Engine-devel] Introducing Infinispan cache and some required actions after change In-Reply-To: <293636070.997059.1366699705162.JavaMail.root@redhat.com> Message-ID: <457280822.1007440.1366702209458.JavaMail.root@redhat.com> Hi All, The following commit I2fbebb10c08c87d2c7fd4d7443d3e3b374541ed7 will introduce a in memory cache inside ovirt-engine The cache which was chosen is infinispan (http://www.jboss.org/infinispan/) The reasons are following: cache has all required functionality, it is open source project and has built-in integration with JBOSS, all cache configuration can be accessed or edited via JBOSS admin console. By introducing this commit the first stage is finished: 1. Cache implementation is added to project 2. Show example how to add and use a cache in ovirt-engine, if it is required 3. Solved bug with possible memory leak in audit log event The next stages are: 1. Second stage - replace all custom made implementation by standard central cache implementation 2. Third stage - introduce second level cache for work with DB 3. Fourth stage (Future) - make cluster wise cache or make cache as service, if we will have more than one instance of JBOSS Now, after the applying the following commit I2fbebb10c08c87d2c7fd4d7443d3e3b374541ed7, everyone who works with ovirt-engine will be required to perform the following operation 1. Run mvn clean install -Pdep,setup in order to replace an old standalone.xml with new version of it Or 1. Use regular deploy: mvn clean install -Pdep 2. Access to $JBOSS_HOME/bin/standalone.xml and replace or add infinispan subsystem: 3. Add or check that exists under element Thanks and Regards Michael From mkublin at redhat.com Tue Apr 23 07:39:11 2013 From: mkublin at redhat.com (Michael Kublin) Date: Tue, 23 Apr 2013 03:39:11 -0400 (EDT) Subject: [Engine-devel] some cleanup In-Reply-To: <297057013.520179.1366651620901.JavaMail.root@redhat.com> References: <297057013.520179.1366651620901.JavaMail.root@redhat.com> Message-ID: <1155130921.1014146.1366702751592.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Laszlo Hornyak" > To: "engine-devel" > Sent: Monday, April 22, 2013 8:27:00 PM > Subject: [Engine-devel] some cleanup > > Hi, > > Some of my patches are waiting for a brave reviewer to +2 them :) > > - entity cleanups > http://gerrit.ovirt.org/13531 > http://gerrit.ovirt.org/13705 > http://gerrit.ovirt.org/13940 > http://gerrit.ovirt.org/13705 > > - command cleanups > http://gerrit.ovirt.org/13945 > http://gerrit.ovirt.org/13946 > http://gerrit.ovirt.org/13947 > > Thx, > Laszlo > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > Done From yzaslavs at redhat.com Tue Apr 23 07:45:47 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Tue, 23 Apr 2013 03:45:47 -0400 (EDT) Subject: [Engine-devel] Introducing Infinispan cache and some required actions after change In-Reply-To: <457280822.1007440.1366702209458.JavaMail.root@redhat.com> References: <457280822.1007440.1366702209458.JavaMail.root@redhat.com> Message-ID: <1869322701.809275.1366703147742.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michael Kublin" > To: "engine-devel" > Sent: Tuesday, April 23, 2013 10:30:09 AM > Subject: [Engine-devel] Introducing Infinispan cache and some required actions after change > > Hi All, > The following commit I2fbebb10c08c87d2c7fd4d7443d3e3b374541ed7 will introduce > a in memory cache inside ovirt-engine > The cache which was chosen is infinispan (http://www.jboss.org/infinispan/) > The reasons are following: cache has all required functionality, it is open > source project and has built-in integration with > JBOSS, all cache configuration can be accessed or edited via JBOSS admin > console. > > By introducing this commit the first stage is finished: > 1. Cache implementation is added to project > 2. Show example how to add and use a cache in ovirt-engine, if it is required > 3. Solved bug with possible memory leak in audit log event > > The next stages are: > 1. Second stage - replace all custom made implementation by standard central > cache implementation > 2. Third stage - introduce second level cache for work with DB > 3. Fourth stage (Future) - make cluster wise cache or make cache as service, > if we will have more than one instance of JBOSS > > Now, after the applying the following commit > I2fbebb10c08c87d2c7fd4d7443d3e3b374541ed7, everyone who works with > ovirt-engine > will be required to perform the following operation > 1. Run mvn clean install -Pdep,setup in order to replace an old > standalone.xml with new version of it > Or > 1. Use regular deploy: mvn clean install -Pdep > 2. Access to $JBOSS_HOME/bin/standalone.xml and replace or add infinispan > subsystem: > default-cache-container="ovirt-engine"> > jndi-name="java:jboss/infinispan/ovirt-engine" start="EAGER"> > > > > > > > > 3. Add or check that exists module="org.jboss.as.clustering.infinispan"/> under element Great! Minor addition - For those of you who are familiar with the term "region" (exists at JBoss Cache, and IIRC ehcache) - look at the configuration Michael provided for "timeout-base". Infinspan supports transactions (see the "transaction-mode") and supports distribution (currently at local mode - see the "local-cache" definition). Yair > > Thanks and Regards Michael > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From lzelkha at redhat.com Tue Apr 23 08:44:33 2013 From: lzelkha at redhat.com (Liran Zelkha) Date: Tue, 23 Apr 2013 04:44:33 -0400 (EDT) Subject: [Engine-devel] Introducing Infinispan cache and some required actions after change In-Reply-To: <1869322701.809275.1366703147742.JavaMail.root@redhat.com> References: <457280822.1007440.1366702209458.JavaMail.root@redhat.com> <1869322701.809275.1366703147742.JavaMail.root@redhat.com> Message-ID: <1383811666.750571.1366706673690.JavaMail.root@redhat.com> Great news. I totally agree that Infinispan is the right way to go. Michael - let's sync on the database caching integration with Infinispan. Would love to hear your thoughts. ----- Original Message ----- From: "Yair Zaslavsky" To: "Michael Kublin" Cc: "engine-devel" Sent: Tuesday, April 23, 2013 10:45:47 AM Subject: Re: [Engine-devel] Introducing Infinispan cache and some required actions after change ----- Original Message ----- > From: "Michael Kublin" > To: "engine-devel" > Sent: Tuesday, April 23, 2013 10:30:09 AM > Subject: [Engine-devel] Introducing Infinispan cache and some required actions after change > > Hi All, > The following commit I2fbebb10c08c87d2c7fd4d7443d3e3b374541ed7 will introduce > a in memory cache inside ovirt-engine > The cache which was chosen is infinispan (http://www.jboss.org/infinispan/) > The reasons are following: cache has all required functionality, it is open > source project and has built-in integration with > JBOSS, all cache configuration can be accessed or edited via JBOSS admin > console. > > By introducing this commit the first stage is finished: > 1. Cache implementation is added to project > 2. Show example how to add and use a cache in ovirt-engine, if it is required > 3. Solved bug with possible memory leak in audit log event > > The next stages are: > 1. Second stage - replace all custom made implementation by standard central > cache implementation > 2. Third stage - introduce second level cache for work with DB > 3. Fourth stage (Future) - make cluster wise cache or make cache as service, > if we will have more than one instance of JBOSS > > Now, after the applying the following commit > I2fbebb10c08c87d2c7fd4d7443d3e3b374541ed7, everyone who works with > ovirt-engine > will be required to perform the following operation > 1. Run mvn clean install -Pdep,setup in order to replace an old > standalone.xml with new version of it > Or > 1. Use regular deploy: mvn clean install -Pdep > 2. Access to $JBOSS_HOME/bin/standalone.xml and replace or add infinispan > subsystem: > default-cache-container="ovirt-engine"> > jndi-name="java:jboss/infinispan/ovirt-engine" start="EAGER"> > > > > > > > > 3. Add or check that exists module="org.jboss.as.clustering.infinispan"/> under element Great! Minor addition - For those of you who are familiar with the term "region" (exists at JBoss Cache, and IIRC ehcache) - look at the configuration Michael provided for "timeout-base". Infinspan supports transactions (see the "transaction-mode") and supports distribution (currently at local mode - see the "local-cache" definition). Yair > > Thanks and Regards Michael > _______________________________________________ > 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 amureini at redhat.com Tue Apr 23 12:53:58 2013 From: amureini at redhat.com (Allon Mureinik) Date: Tue, 23 Apr 2013 08:53:58 -0400 (EDT) Subject: [Engine-devel] storage overallocation ratio In-Reply-To: <1D680F89-5FE7-4A52-971E-0FAD298120FC@redhat.com> References: <1D680F89-5FE7-4A52-971E-0FAD298120FC@redhat.com> Message-ID: <1133405633.1167866.1366721638203.JavaMail.root@redhat.com> Hi Michal, apparentsize is the size that you perceive when working with the volume (i.e., ignoring sparseness etc.) while trusize is the size taken on the drive (i.e., taking sparseness etc. into account). DiskImage.getActualSize() should report the truesize. The end result is OK, since truesize overrides apparentsize in that command, but it's obviously wrong, and should be fixed [1]. [1] http://gerrit.ovirt.org/#/c/14176/ ----- Original Message ----- > From: "Michal Skrivanek" > To: engine-devel at ovirt.org > Sent: Saturday, April 20, 2013 11:13:04 PM > Subject: [Engine-devel] storage overallocation ratio > > Hi, > I was trying to find out how is this actually calculated. Doesn't look very > straightforward?:) > > I'm curious about the following - vdsm reports something like truesize and > apparentsize which IIUC should be distinct but then in engine, in > backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/irsbroker/GetImageInfoVDSCommand.java > it's written to the same engine property actual_size. > That doesn't sound right. > Can someone enlighten me please? > > Thanks, > michal > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From sgrinber at redhat.com Tue Apr 23 11:51:25 2013 From: sgrinber at redhat.com (Simon Grinberg) Date: Tue, 23 Apr 2013 07:51:25 -0400 (EDT) Subject: [Engine-devel] rewrite the engine-notifier service wrapper In-Reply-To: <1507498443.799657.1366700859801.JavaMail.root@redhat.com> References: <439619200.374291.1366668901175.JavaMail.root@redhat.com> <1507498443.799657.1366700859801.JavaMail.root@redhat.com> Message-ID: <26579353.167.1366717816571.JavaMail.javamailuser@localhost> ----- Original Message ----- > From: "Yair Zaslavsky" > To: "Alon Bar-Lev" > Cc: "Juan Hernandez" , "Simon Grinberg" , "engine-devel" > > Sent: Tuesday, April 23, 2013 10:07:39 AM > Subject: Re: [Engine-devel] rewrite the engine-notifier service wrapper > > > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "engine-devel" > > Cc: "Juan Hernandez" , "Simon Grinberg" > > > > Sent: Tuesday, April 23, 2013 1:15:01 AM > > Subject: [Engine-devel] rewrite the engine-notifier service wrapper > > > > Hello, > > > > After finish to cleanup the engine-service to use downstream > > services and be > > portable to other distributions (upstart, openrc), we can use the > > same > > infrastructure for the engine notifier script. > > > > It is very similar to the engine-service in operation (running > > java), except > > it is written in bash instead of python and has no systemd support, > > and have > > its own configuration. > > > > What I suggest is to rewrite the notifier service in python and > > reuse the > > engine-service code. > > > > Also, drop the /etc/ovirt-engine/notifier/notifier.conf in favor of > > variables > > within the /etc/ovirt-engine/engine.conf[.d/*], this will provide a > > single > > point of configuration for all services. > > > > And of course proper systemd support and development environment > > support. > > > > Any comments? thoughts? > > > > Alon > > IMHO - +1 , the sooner the better - start with that and move to all > the other bash scripts of the tools ;) +1 > > > _______________________________________________ > > 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 gpadgett at redhat.com Tue Apr 23 15:43:38 2013 From: gpadgett at redhat.com (Greg Padgett) Date: Tue, 23 Apr 2013 11:43:38 -0400 Subject: [Engine-devel] Cloud-Init integration In-Reply-To: <51730023.30001@redhat.com> References: <5154D3BB.7080004@redhat.com> <51730023.30001@redhat.com> Message-ID: <5176AC2A.4010305@redhat.com> Hi Itamar, On 04/20/2013 04:52 PM, Itamar Heim wrote: > On 03/29/2013 01:35 AM, Greg Padgett wrote: >> Hi Everyone, >> >> I'd like to propose a feature we've been doing some investigation into, >> which is to integrate cloud-init support into oVirt. >> >> Cloud-init is used to help provision new Linux systems by setting the >> hostname, ip, ssh keys, timezone, injecting files, and more. It's used >> by OpenStack (amongst others) now, and has a lot of features that may be >> helpful to our users. >> >> Details are still evolving, but for more info please see the wiki page: >> >> http://www.ovirt.org/Features/Cloud-Init_Integration >> >> All feedback is welcome! > > a few questions: > - are you planning to save the info in the db by field, or as a single > "blob"? maybe a better questions is are you going to persist it at > all? No persistence yet, but when that time comes I'd prefer to store the fields (either separately or a standard serialized format), rather than storing the generated blob. Easier to retrieve/modify. > - i'd be careful before passing any passwords (page mentions root > password) - you'd need to not persist it unecrypted, identify it and > clean it from all logs, etc. I've looked into this a little: cloud-init will accept a password that's been crypt(3)'ed, and Apache Commons Codec has a Crypt API that will do this--but not in our version, it's new in 1.7. So, still considering alternatives. > - hostname - should just assume the vm name? Sure, how about pre-populating the field? The user would see that we're setting the hostname and be able to change it if desired. > - timezone - is that different than the windows one? for a windows > guest as well? AFAICT, a healthy subset of timezones can be mapped cleanly between Linux/Java/Windows representations, and the Java timezone ids look to be a fairly good match for the timezone files used in Linux. I hope we don't have to show different timezone selections based on OS type, but not sure yet. (Should know soon, I'm looking into all this now.) > > Thanks, > Itamar > From lhornyak at redhat.com Tue Apr 23 11:26:01 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Tue, 23 Apr 2013 07:26:01 -0400 (EDT) Subject: [Engine-devel] some cleanup In-Reply-To: <1155130921.1014146.1366702751592.JavaMail.root@redhat.com> References: <297057013.520179.1366651620901.JavaMail.root@redhat.com> <1155130921.1014146.1366702751592.JavaMail.root@redhat.com> Message-ID: <283965091.781177.1366716361690.JavaMail.root@redhat.com> Thank you Michael! ----- Original Message ----- > From: "Michael Kublin" > To: "Laszlo Hornyak" > Cc: "engine-devel" > Sent: Tuesday, April 23, 2013 9:39:11 AM > Subject: Re: [Engine-devel] some cleanup > > > > > > ----- Original Message ----- > > From: "Laszlo Hornyak" > > To: "engine-devel" > > Sent: Monday, April 22, 2013 8:27:00 PM > > Subject: [Engine-devel] some cleanup > > > > Hi, > > > > Some of my patches are waiting for a brave reviewer to +2 them :) > > > > - entity cleanups > > http://gerrit.ovirt.org/13531 > > http://gerrit.ovirt.org/13705 > > http://gerrit.ovirt.org/13940 > > http://gerrit.ovirt.org/13705 > > > > - command cleanups > > http://gerrit.ovirt.org/13945 > > http://gerrit.ovirt.org/13946 > > http://gerrit.ovirt.org/13947 > > > > Thx, > > Laszlo > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > Done > From michal.skrivanek at redhat.com Wed Apr 24 07:11:33 2013 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Wed, 24 Apr 2013 09:11:33 +0200 Subject: [Engine-devel] find-bugs errors - please investigate/fix In-Reply-To: <51777252.4000908@redhat.com> References: <1793524565.2990114.1366769840388.JavaMail.root@redhat.com> <51777252.4000908@redhat.com> Message-ID: <0C273DD1-C60D-4060-8E3F-71CE5F507EBE@redhat.com> On Apr 24, 2013, at 07:49 , Sahina Bose wrote: > > On 04/24/2013 07:47 AM, Einav Cohen wrote: >> ovirt find-bugs errors in jenkins - please investigate/fix asap. >> [@Eyal - FYI: some of them seem really strange - see Michal's section below] >> >> @Sahina Bose: >> find-bugs error details: >> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-267688716/source.349621/#23 >> caused by: http://gerrit.ovirt.org/#/c/13831/ > Have submitted a patch (http://gerrit.ovirt.org/#/c/14187/) fixing this. Thanks! >> >> @Michael Kublin: >> find-bugs error details: >> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-609324659/source.347305/#346 >> caused by: >> http://gerrit.ovirt.org/#/c/13740/ >> >> @Michal Skrivanek: >> >> the following seem strange - can you please investigate? could be false positives. >> >> - find-bugs error details: >> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/source.350390/#1349 >> [not sure when introduced - seems old, hence I suspect it is a false positive] >> >> - Two additional errors in the same file as ^^^, you can see them at: >> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/ >> when clicking on them, there aren't any details, however according to their tool-tips, it seems to be an "unreachable >> OnSuccess method within an anonymous class" or something similar. >> >> - another suspicious error is in VmListModel.java: >> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-1516395789/source.350485/#2406 >> [again - not sure when introduced - seems old, hence I suspect it is a false positive] Doesn't really seem to work correctly. Tooltip is talking about OnSuccess method for all mine above and it really doesn't seem to correspond with reality. Looks like findbugs is broken or confused >> >> ---- >> Thanks, >> Einav > From sabose at redhat.com Wed Apr 24 05:49:06 2013 From: sabose at redhat.com (Sahina Bose) Date: Wed, 24 Apr 2013 11:19:06 +0530 Subject: [Engine-devel] find-bugs errors - please investigate/fix In-Reply-To: <1793524565.2990114.1366769840388.JavaMail.root@redhat.com> References: <1793524565.2990114.1366769840388.JavaMail.root@redhat.com> Message-ID: <51777252.4000908@redhat.com> On 04/24/2013 07:47 AM, Einav Cohen wrote: > ovirt find-bugs errors in jenkins - please investigate/fix asap. > [@Eyal - FYI: some of them seem really strange - see Michal's section below] > > @Sahina Bose: > find-bugs error details: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-267688716/source.349621/#23 > caused by: http://gerrit.ovirt.org/#/c/13831/ Have submitted a patch (http://gerrit.ovirt.org/#/c/14187/) fixing this. Thanks! > > @Michael Kublin: > find-bugs error details: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-609324659/source.347305/#346 > caused by: > http://gerrit.ovirt.org/#/c/13740/ > > @Michal Skrivanek: > > the following seem strange - can you please investigate? could be false positives. > > - find-bugs error details: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/source.350390/#1349 > [not sure when introduced - seems old, hence I suspect it is a false positive] > > - Two additional errors in the same file as ^^^, you can see them at: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/ > when clicking on them, there aren't any details, however according to their tool-tips, it seems to be an "unreachable > OnSuccess method within an anonymous class" or something similar. > > - another suspicious error is in VmListModel.java: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-1516395789/source.350485/#2406 > [again - not sure when introduced - seems old, hence I suspect it is a false positive] > > ---- > Thanks, > Einav From tnisan at redhat.com Wed Apr 24 09:25:50 2013 From: tnisan at redhat.com (Tal Nisan) Date: Wed, 24 Apr 2013 12:25:50 +0300 Subject: [Engine-devel] find-bugs errors - please investigate/fix In-Reply-To: <0C273DD1-C60D-4060-8E3F-71CE5F507EBE@redhat.com> References: <1793524565.2990114.1366769840388.JavaMail.root@redhat.com> <51777252.4000908@redhat.com> <0C273DD1-C60D-4060-8E3F-71CE5F507EBE@redhat.com> Message-ID: <5177A51E.2040906@redhat.com> Seems that the cleanup worked, now the actual results after the frontend cleanup pathces are shown without the false positives http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4069/ On 04/24/2013 10:11 AM, Michal Skrivanek wrote: > On Apr 24, 2013, at 07:49 , Sahina Bose wrote: > >> On 04/24/2013 07:47 AM, Einav Cohen wrote: >>> ovirt find-bugs errors in jenkins - please investigate/fix asap. >>> [@Eyal - FYI: some of them seem really strange - see Michal's section below] >>> >>> @Sahina Bose: >>> find-bugs error details: >>> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-267688716/source.349621/#23 >>> caused by: http://gerrit.ovirt.org/#/c/13831/ >> Have submitted a patch (http://gerrit.ovirt.org/#/c/14187/) fixing this. Thanks! >>> @Michael Kublin: >>> find-bugs error details: >>> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-609324659/source.347305/#346 >>> caused by: >>> http://gerrit.ovirt.org/#/c/13740/ >>> >>> @Michal Skrivanek: >>> >>> the following seem strange - can you please investigate? could be false positives. >>> >>> - find-bugs error details: >>> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/source.350390/#1349 >>> [not sure when introduced - seems old, hence I suspect it is a false positive] >>> >>> - Two additional errors in the same file as ^^^, you can see them at: >>> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/ >>> when clicking on them, there aren't any details, however according to their tool-tips, it seems to be an "unreachable >>> OnSuccess method within an anonymous class" or something similar. >>> >>> - another suspicious error is in VmListModel.java: >>> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-1516395789/source.350485/#2406 >>> [again - not sure when introduced - seems old, hence I suspect it is a false positive] > Doesn't really seem to work correctly. Tooltip is talking about OnSuccess method for all mine above and it really doesn't seem to correspond with reality. > Looks like findbugs is broken or confused > >>> ---- >>> Thanks, >>> Einav > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From tnisan at redhat.com Wed Apr 24 08:39:49 2013 From: tnisan at redhat.com (Tal Nisan) Date: Wed, 24 Apr 2013 11:39:49 +0300 Subject: [Engine-devel] find-bugs errors - please investigate/fix In-Reply-To: <0C273DD1-C60D-4060-8E3F-71CE5F507EBE@redhat.com> References: <1793524565.2990114.1366769840388.JavaMail.root@redhat.com> <51777252.4000908@redhat.com> <0C273DD1-C60D-4060-8E3F-71CE5F507EBE@redhat.com> Message-ID: <51779A55.2030905@redhat.com> I've seen it too, it's after a series of patches I pushed to solve some findbugs issue that we got this false positive, I've asked Eyal to clean the target, it seems that findbugs is referring to old code that doesn't exist anymore. On 04/24/2013 10:11 AM, Michal Skrivanek wrote: > On Apr 24, 2013, at 07:49 , Sahina Bose wrote: > >> On 04/24/2013 07:47 AM, Einav Cohen wrote: >>> ovirt find-bugs errors in jenkins - please investigate/fix asap. >>> [@Eyal - FYI: some of them seem really strange - see Michal's section below] >>> >>> @Sahina Bose: >>> find-bugs error details: >>> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-267688716/source.349621/#23 >>> caused by: http://gerrit.ovirt.org/#/c/13831/ >> Have submitted a patch (http://gerrit.ovirt.org/#/c/14187/) fixing this. Thanks! >>> @Michael Kublin: >>> find-bugs error details: >>> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-609324659/source.347305/#346 >>> caused by: >>> http://gerrit.ovirt.org/#/c/13740/ >>> >>> @Michal Skrivanek: >>> >>> the following seem strange - can you please investigate? could be false positives. >>> >>> - find-bugs error details: >>> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/source.350390/#1349 >>> [not sure when introduced - seems old, hence I suspect it is a false positive] >>> >>> - Two additional errors in the same file as ^^^, you can see them at: >>> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/ >>> when clicking on them, there aren't any details, however according to their tool-tips, it seems to be an "unreachable >>> OnSuccess method within an anonymous class" or something similar. >>> >>> - another suspicious error is in VmListModel.java: >>> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-1516395789/source.350485/#2406 >>> [again - not sure when introduced - seems old, hence I suspect it is a false positive] > Doesn't really seem to work correctly. Tooltip is talking about OnSuccess method for all mine above and it really doesn't seem to correspond with reality. > Looks like findbugs is broken or confused > >>> ---- >>> Thanks, >>> Einav > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From lzelkha at redhat.com Wed Apr 24 06:02:19 2013 From: lzelkha at redhat.com (Liran Zelkha) Date: Wed, 24 Apr 2013 02:02:19 -0400 (EDT) Subject: [Engine-devel] Database Caching In-Reply-To: <382161017.1358909.1366783168536.JavaMail.root@redhat.com> Message-ID: <228537371.1359262.1366783339378.JavaMail.root@redhat.com> Hi I've created Change I04d7edea (http://gerrit.ovirt.org/#/c/14188/) that adds automatic database caching capabilities to the engine. To cache a business entity, just add an annotation called TimeToLiveInCache that accepts as a parameter the number of seconds this object can live in the cache until it is refreshed from the database. The next stage is improving the cache update mechanism, using Infinispan, and the ability to capture more query types. Would love input and suggestions. Thanks, Liran From ecohen at redhat.com Wed Apr 24 02:17:20 2013 From: ecohen at redhat.com (Einav Cohen) Date: Tue, 23 Apr 2013 22:17:20 -0400 (EDT) Subject: [Engine-devel] find-bugs errors - please investigate/fix In-Reply-To: <237009489.2982914.1366767557838.JavaMail.root@redhat.com> Message-ID: <1793524565.2990114.1366769840388.JavaMail.root@redhat.com> ovirt find-bugs errors in jenkins - please investigate/fix asap. [@Eyal - FYI: some of them seem really strange - see Michal's section below] @Sahina Bose: find-bugs error details: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-267688716/source.349621/#23 caused by: http://gerrit.ovirt.org/#/c/13831/ @Michael Kublin: find-bugs error details: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-609324659/source.347305/#346 caused by: http://gerrit.ovirt.org/#/c/13740/ @Michal Skrivanek: the following seem strange - can you please investigate? could be false positives. - find-bugs error details: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/source.350390/#1349 [not sure when introduced - seems old, hence I suspect it is a false positive] - Two additional errors in the same file as ^^^, you can see them at: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/ when clicking on them, there aren't any details, however according to their tool-tips, it seems to be an "unreachable OnSuccess method within an anonymous class" or something similar. - another suspicious error is in VmListModel.java: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-1516395789/source.350485/#2406 [again - not sure when introduced - seems old, hence I suspect it is a false positive] ---- Thanks, Einav From ecohen at redhat.com Wed Apr 24 12:48:34 2013 From: ecohen at redhat.com (Einav Cohen) Date: Wed, 24 Apr 2013 08:48:34 -0400 (EDT) Subject: [Engine-devel] find-bugs errors - please investigate/fix In-Reply-To: <1793524565.2990114.1366769840388.JavaMail.root@redhat.com> References: <1793524565.2990114.1366769840388.JavaMail.root@redhat.com> Message-ID: <1887010992.3322622.1366807714168.JavaMail.root@redhat.com> it seems that after the fixes and clean-up, find-bugs is now back to normal: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4073/ all - many thanks for your prompt response! ---- Regards, Einav ----- Original Message ----- > From: "Einav Cohen" > To: "Sahina Bose" , "Michael Kublin" , "Michal Skrivanek" > , "Eyal Edri" > Cc: "engine-devel" > Sent: Tuesday, April 23, 2013 10:17:20 PM > Subject: [Engine-devel] find-bugs errors - please investigate/fix > > ovirt find-bugs errors in jenkins - please investigate/fix asap. > [@Eyal - FYI: some of them seem really strange - see Michal's section below] > > @Sahina Bose: > find-bugs error details: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-267688716/source.349621/#23 > caused by: http://gerrit.ovirt.org/#/c/13831/ > > @Michael Kublin: > find-bugs error details: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-609324659/source.347305/#346 > caused by: > http://gerrit.ovirt.org/#/c/13740/ > > @Michal Skrivanek: > > the following seem strange - can you please investigate? could be false > positives. > > - find-bugs error details: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/source.350390/#1349 > [not sure when introduced - seems old, hence I suspect it is a false > positive] > > - Two additional errors in the same file as ^^^, you can see them at: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/ > when clicking on them, there aren't any details, however according to their > tool-tips, it seems to be an "unreachable > OnSuccess method within an anonymous class" or something similar. > > - another suspicious error is in VmListModel.java: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-1516395789/source.350485/#2406 > [again - not sure when introduced - seems old, hence I suspect it is a false > positive] > > ---- > Thanks, > Einav > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From eedri at redhat.com Wed Apr 24 12:52:20 2013 From: eedri at redhat.com (Eyal Edri) Date: Wed, 24 Apr 2013 08:52:20 -0400 (EDT) Subject: [Engine-devel] find-bugs errors - please investigate/fix In-Reply-To: <1887010992.3322622.1366807714168.JavaMail.root@redhat.com> References: <1793524565.2990114.1366769840388.JavaMail.root@redhat.com> <1887010992.3322622.1366807714168.JavaMail.root@redhat.com> Message-ID: <150231806.2668578.1366807940777.JavaMail.root@redhat.com> thanks for the fix. Also, finally we see some progress on the 'low' priority bugs, fixing 337, which now stands on ~1600 instead of ~1900... http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4073/findbugsResult/? Eyal. ----- Original Message ----- > From: "Einav Cohen" > To: "Sahina Bose" , "Michal Skrivanek" , "Tal Nisan" > > Cc: "engine-devel" , "Eyal Edri" > Sent: Wednesday, April 24, 2013 3:48:34 PM > Subject: Re: [Engine-devel] find-bugs errors - please investigate/fix > > it seems that after the fixes and clean-up, find-bugs is now back to normal: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4073/ > > all - many thanks for your prompt response! > > ---- > Regards, > Einav > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Sahina Bose" , "Michael Kublin" > > , "Michal Skrivanek" > > , "Eyal Edri" > > Cc: "engine-devel" > > Sent: Tuesday, April 23, 2013 10:17:20 PM > > Subject: [Engine-devel] find-bugs errors - please investigate/fix > > > > ovirt find-bugs errors in jenkins - please investigate/fix asap. > > [@Eyal - FYI: some of them seem really strange - see Michal's section > > below] > > > > @Sahina Bose: > > find-bugs error details: > > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-267688716/source.349621/#23 > > caused by: http://gerrit.ovirt.org/#/c/13831/ > > > > @Michael Kublin: > > find-bugs error details: > > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-609324659/source.347305/#346 > > caused by: > > http://gerrit.ovirt.org/#/c/13740/ > > > > @Michal Skrivanek: > > > > the following seem strange - can you please investigate? could be false > > positives. > > > > - find-bugs error details: > > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/source.350390/#1349 > > [not sure when introduced - seems old, hence I suspect it is a false > > positive] > > > > - Two additional errors in the same file as ^^^, you can see them at: > > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/ > > when clicking on them, there aren't any details, however according to their > > tool-tips, it seems to be an "unreachable > > OnSuccess method within an anonymous class" or something similar. > > > > - another suspicious error is in VmListModel.java: > > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-1516395789/source.350485/#2406 > > [again - not sure when introduced - seems old, hence I suspect it is a > > false > > positive] > > > > ---- > > Thanks, > > Einav > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From asegurap at redhat.com Wed Apr 24 13:11:33 2013 From: asegurap at redhat.com (Antoni Segura Puimedon) Date: Wed, 24 Apr 2013 09:11:33 -0400 (EDT) Subject: [Engine-devel] Proposal to make REST API more webapp-friendly In-Reply-To: <431498683.2053791.1366204111100.JavaMail.root@redhat.com> References: <2140658645.762187.1366023864071.JavaMail.root@redhat.com> <815104772.15680618.1366189992223.JavaMail.root@redhat.com> <697492056.2007786.1366194306086.JavaMail.root@redhat.com> <1616192035.15952873.1366194549669.JavaMail.root@redhat.com> <431498683.2053791.1366204111100.JavaMail.root@redhat.com> Message-ID: <1502852509.1206391.1366809093879.JavaMail.root@redhat.com> Incidentally, the other day reading hacker news I happened upon a similar discussion and article. It might be an interesting lecture to put in perspective our own discussion: article: http://swaggadocio.com/post/48223179207/why-the-hell-does-your-api-still-use-http-basic-auth discussion: https://news.ycombinator.com/item?id=5569625 ----- Original Message ----- > From: "Vojtech Szocs" > To: "Oved Ourfalli" > Cc: "Juan Hernandez" , "engine-devel" > Sent: Wednesday, April 17, 2013 3:08:31 PM > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > Hi Oved, > > >> The only difference would be, when REST API receives the request, it looks > >> for "Prefer:use-jsessionid-header", and if it's present, it uses > >> "JSESSIONID" header value to look up HttpSession in some way (not sure > >> about > >> implementation details, though, but this should be possible to do). > >> > >> So, what do you think? > >> > > As far as I saw, the handling of the cookie is done before the REST code, > > and that's why we need the cookie. > > Perhaps there is a way to make jboss take the JSESSIONID from the HTTP > > header, and not the cookie, but I didn't find a way to do that yet. > > I'm also not sure about this, so far I've only found: > http://stackoverflow.com/questions/5807664/tomcat-how-to-access-session-manager-from-servlet > > It seems that the solution is to either provide custom session manager > implementation in JBoss, or to obtain standard session manager early when > processing request and create session manually there. > > Vojtech > > > ----- Original Message ----- > From: "Oved Ourfalli" > To: "Vojtech Szocs" > Cc: "Juan Hernandez" , "engine-devel" > > Sent: Wednesday, April 17, 2013 12:29:09 PM > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > ----- Original Message ----- > > From: "Vojtech Szocs" > > To: "Oved Ourfalli" > > Cc: "Juan Hernandez" , "engine-devel" > > > > Sent: Wednesday, April 17, 2013 1:25:06 PM > > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > Hi Oved, thanks for your feedback! > > > > > We currently return the JSESSIONID also using HTTP headers. We currently > > > return the jsession id also as part of the response HTTP headers, but the > > > client still needs to pass a cookie with the appropriate value in order > > > for the REST session to work. Isn't that enough to cope with this issue? > > > > Right, currently REST API responds with JSESSIONID cookie + separate > > JSESSIONID response header, both carrying session ID value. > > > > As I wrote in my original email: JavaScript running at > > [http://example.com/webapp] *cannot* get/set cookies from requests at > > [http://example.com/restapi] > > > > So WebAdmin cannot get/set REST API JSESSIONID cookie directly, which is > > why > > it uses separate JSESSIONID response header in order to *read* the session > > ID value. As for sending JSESSIONID cookie, WebAdmin currently relies on > > standard cookie-handling implemented in browsers: all cookies for location > > X > > [http://example.com/restapi] will be part of any request to location X. So > > it's the browser who sets JSESSIONID cookie for REST API request, not > > WebAdmin. > > > > To answer your question, currently it's enough to work around the cookie > > access limitation, but it's not good enough in my opinion (from > > JavaScript/webapp perspective).. > > > > > If not, then we might be able to do option #2: > > > Today, we keep the engine session ID on the HTTP session attributes. > > > So, we can support either passing the cookie with the JSESSIONID (taking > > > the engine session ID from the http session), or passing the engine > > > session ID as HTTP header (assuming we would also return the engine > > > session ID upon first REST request). > > > > Well, the problem I described only relates to the way how JSESSIONID value > > is > > transmitted between client and server: currently using cookies, so REST API > > client has to do cookie handling. > > > > It would be really great if I could tell REST API to use plain (i.e. *not* > > Set-Cookie & Cookie) HTTP header, for example "JSESSIONID", for the purpose > > of transmitting session ID value between client and server. > > > > For example, the request to acquire session would be: > > > > GET /api HTTP/1.1 > > Host: www.example.org > > Prefer: use-jsessionid-header > > JSESSIONID: xxx > > > > [Feel free to replace "use-jsessionid-header" with anything you like. If > > client doesn't specify "use-jsessionid-header", server expects "Cookie" > > header by default to preserve compatibility.] > > > > And the response would be: > > > > HTTP/1.1 200 OK > > JSESSIONID: xxx > > > > [If client didn't specify "use-jsessionid-header", server would use > > "Set-Cookie" header by default to preserve compatibility.] > > > > > This approach is problematic, as it might work well now, when the only > > > attribute we use is the engine session ID, but in the future that might > > > not be the case. > > > If it is important enough (i.e., you can't really work with option #1) , > > > then we can make a decision to save the attributes on the engine session, > > > rather than on the HTTP session. > > > So, we would start by supporting them both together, adding new > > > attributes > > > only to the engine session, and in the future deprecating the use of > > > cookies, and only supporting HTTP headers. > > > > I think you can keep the current implementation, i.e. use REST API > > HttpSession to store Engine session ID value. > > > > The only difference would be, when REST API receives the request, it looks > > for "Prefer:use-jsessionid-header", and if it's present, it uses > > "JSESSIONID" header value to look up HttpSession in some way (not sure > > about > > implementation details, though, but this should be possible to do). > > > > So, what do you think? > > > As far as I saw, the handling of the cookie is done before the REST code, and > that's why we need the cookie. > Perhaps there is a way to make jboss take the JSESSIONID from the HTTP > header, and not the cookie, but I didn't find a way to do that yet. > > > Vojtech > > > > > > ----- Original Message ----- > > From: "Oved Ourfalli" > > To: "Vojtech Szocs" > > Cc: "engine-devel" , "Juan Hernandez" > > , "Michael Pasternak" > > Sent: Wednesday, April 17, 2013 11:13:12 AM > > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > > > > > ----- Original Message ----- > > > From: "Vojtech Szocs" > > > To: "engine-devel" > > > Sent: Monday, April 15, 2013 2:04:24 PM > > > Subject: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > > > Hi guys, > > > > > > having worked with Engine REST API from web application (JavaScript) > > > perspective, there are things that could be improved to make REST API > > > more > > > webapp-friendly. > > > > > > First of all, webapps are *not* traditional HTTP clients, i.e. they have > > > *not* full control over HTTP processing. There are some standard > > > conventions > > > and behaviors built into web browsers that any REST API implementation > > > should be aware of. > > > > > > -- > > > > > > (1) Don't force clients to use cookies for transmitting authentication > > > information! (or don't use cookies at all) > > > > > > Good explanation can be found at > > > [http://www.berenddeboer.net/rest/cookies.html]. Cookies have many > > > disadvantages: > > > > > > * cookie parsing/formatting is not trivial > > > --> extra complexity imposed on REST clients > > > > > > * in addition to Same-Origin Policy > > > [http://en.wikipedia.org/wiki/Same_origin_policy], cookies can be get/set > > > *only* for the given path > > > --> JavaScript running at [http://example.com/webapp] *cannot* get/set > > > cookies from requests at [http://example.com/restapi] > > > > > > * cookies are the primary source of Cross-Site Request Forgery > > > [http://en.wikipedia.org/wiki/Cross-site_request_forgery] attacks > > > --> malicious websites/scripts can forge requests to REST API that will > > > include the cookie, compromising user session > > > > > > Alternative: clients could be given the *option* to use regular HTTP > > > header > > > for transmitting authentication information. > > > > > > For example, webapp could read such (sensitive information) header, store > > > it > > > securely via HTML5 Session Storage > > > [http://en.wikipedia.org/wiki/Web_storage] and implement related HTTP > > > processing on its own, e.g. pass this header for all authenticated > > > requests > > > (instead of pushing this responsibility to browser). > > > > > > > Option #1: > > We currently return the JSESSIONID also using HTTP headers. We currently > > return the jsession id also as part of the response HTTP headers, but the > > client still needs to pass a cookie with the appropriate value in order for > > the REST session to work. Isn't that enough to cope with this issue? > > > > If not, then we might be able to do option #2: > > Today, we keep the engine session ID on the HTTP session attributes. > > So, we can support either passing the cookie with the JSESSIONID (taking > > the > > engine session ID from the http session), or passing the engine session ID > > as HTTP header (assuming we would also return the engine session ID upon > > first REST request). > > > > This approach is problematic, as it might work well now, when the only > > attribute we use is the engine session ID, but in the future that might not > > be the case. > > If it is important enough (i.e., you can't really work with option #1) , > > then > > we can make a decision to save the attributes on the engine session, rather > > than on the HTTP session. > > So, we would start by supporting them both together, adding new attributes > > only to the engine session, and in the future deprecating the use of > > cookies, and only supporting HTTP headers. > > > > cc-ed Juan and Michael, as they might have some input on that. > > > > > > > -- > > > > > > (2) Straight-forward HTTP Basic Auth has some drawbacks! > > > > > > HTTP Basic Auth > > > [http://en.wikipedia.org/wiki/Basic_access_authentication] > > > over (non-secure) HTTP connection means sending user credentials > > > (username/password/domain) in easy-to-decode cleartext, i.e. the value is > > > *not* encrypted or hashed in any way. Using secure lower-level protocol > > > (SSL) fixes the consequence, rather than the root cause of the > > > confidentiality issue. > > > > > > Furthermore, browsers typically remember HTTP Basic Auth information > > > (either > > > via browser-specific popup, or via XmlHttpRequest) until the browser > > > window > > > is closed. This means the webapp has no control over HTTP Basic Auth > > > header > > > after it has been set! This is the reason why it's hard to implement > > > "logout" functionality in webapps when using HTTP Basic Auth. > > > > > > Last but not least, HTTP Basic Auth is vulnerable to Replay attacks > > > [http://en.wikipedia.org/wiki/Replay_attack]. Someone between client and > > > server can intercept requests and replay them, compromising user session. > > > > > > Alternative: clients could be given the *option* to use more advanced > > > authentication scheme. > > > > > > I've just read an excellent article at > > > [http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/] > > > which describes easy yet secure authentication scheme inspired by Amazon > > > Web > > > Services REST API authentication > > > [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html]. > > > The idea is simple: collect auth information, hash (sign) it with a > > > private > > > key, and send everything to server. To guard against Replay attacks, just > > > provide some timestamp to enforce request expiry after some time (say, > > > 5-15 > > > minutes). Easy and simple! > > > > > > -- > > > > > > (3) Support JSON for resource representations! > > > > > > I think this is pretty much obvious. XML has no real advantages over > > > JSON. > > > JSON, on the other hand, has good support in webapps (JavaScript) and > > > maps > > > directly to common data structures (i.e. string, number, boolean, and so > > > on). > > > > > > From webapp perspective, it's much easier and natural to use JSON than to > > > parse/format XML documents. > > > > > > Alternative: clients could be given the *option* to use JSON, in addition > > > to > > > XML representation. > > > > > > -- > > > > > > Vojtech > > > _______________________________________________ > > > 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 vszocs at redhat.com Wed Apr 24 14:06:09 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Wed, 24 Apr 2013 10:06:09 -0400 (EDT) Subject: [Engine-devel] UiCommon models in UserPortal - note about optimization logic In-Reply-To: <106155662.1991673.1366811679364.JavaMail.root@redhat.com> Message-ID: <472587365.2022337.1366812369835.JavaMail.root@redhat.com> Hi, recently we faced an issue [1] where UserPortal UI refresh optimization logic [2] interfered with direct UiCommon model updates. The optimization logic compares freshly received data with existing data and doesn't trigger UI refresh when there's no change. This inherently implies that UiCommon SearchableListModel shouldn't manipulate its item data directly, or it risks the situation when the optimization logic thinks there's no change (data retrieved from server matches updated item data). (Possible improvement: add "dirty" flag to item model type (UserPortalItemModel) that would be called when UiCommon SearchableListModel does direct item manipulation.) Vojtech [1] http://gerrit.ovirt.org/#/c/14148/ [2] AbstractUserPortalListProvider.updateDataProvider method override From vszocs at redhat.com Wed Apr 24 14:21:47 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Wed, 24 Apr 2013 10:21:47 -0400 (EDT) Subject: [Engine-devel] Proposal to make REST API more webapp-friendly In-Reply-To: <1502852509.1206391.1366809093879.JavaMail.root@redhat.com> References: <2140658645.762187.1366023864071.JavaMail.root@redhat.com> <815104772.15680618.1366189992223.JavaMail.root@redhat.com> <697492056.2007786.1366194306086.JavaMail.root@redhat.com> <1616192035.15952873.1366194549669.JavaMail.root@redhat.com> <431498683.2053791.1366204111100.JavaMail.root@redhat.com> <1502852509.1206391.1366809093879.JavaMail.root@redhat.com> Message-ID: <1086357486.2054345.1366813307087.JavaMail.root@redhat.com> Thanks Antoni, the article essentially documents the (complete) lack of confidentiality protection for the transmitted credentials in Basic Auth protocol. Base64 encoding is neither encryption nor hashing so it's pretty much the same as plaintext. To be fair, with HTTPS, the confidentiality issue of Basic Auth protocol is mitigated. This means Basic Auth should only be used with HTTPS. At the end of the article, the author proposes exactly what I wrote some time ago: "collect auth information, hash (sign) it with a private key, and send everything to server". (In the article, it's mentioned as "HMAC-SHA" technique.) Vojtech ----- Original Message ----- From: "Antoni Segura Puimedon" To: "engine-devel" Sent: Wednesday, April 24, 2013 3:11:33 PM Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly Incidentally, the other day reading hacker news I happened upon a similar discussion and article. It might be an interesting lecture to put in perspective our own discussion: article: http://swaggadocio.com/post/48223179207/why-the-hell-does-your-api-still-use-http-basic-auth discussion: https://news.ycombinator.com/item?id=5569625 ----- Original Message ----- > From: "Vojtech Szocs" > To: "Oved Ourfalli" > Cc: "Juan Hernandez" , "engine-devel" > Sent: Wednesday, April 17, 2013 3:08:31 PM > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > Hi Oved, > > >> The only difference would be, when REST API receives the request, it looks > >> for "Prefer:use-jsessionid-header", and if it's present, it uses > >> "JSESSIONID" header value to look up HttpSession in some way (not sure > >> about > >> implementation details, though, but this should be possible to do). > >> > >> So, what do you think? > >> > > As far as I saw, the handling of the cookie is done before the REST code, > > and that's why we need the cookie. > > Perhaps there is a way to make jboss take the JSESSIONID from the HTTP > > header, and not the cookie, but I didn't find a way to do that yet. > > I'm also not sure about this, so far I've only found: > http://stackoverflow.com/questions/5807664/tomcat-how-to-access-session-manager-from-servlet > > It seems that the solution is to either provide custom session manager > implementation in JBoss, or to obtain standard session manager early when > processing request and create session manually there. > > Vojtech > > > ----- Original Message ----- > From: "Oved Ourfalli" > To: "Vojtech Szocs" > Cc: "Juan Hernandez" , "engine-devel" > > Sent: Wednesday, April 17, 2013 12:29:09 PM > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > ----- Original Message ----- > > From: "Vojtech Szocs" > > To: "Oved Ourfalli" > > Cc: "Juan Hernandez" , "engine-devel" > > > > Sent: Wednesday, April 17, 2013 1:25:06 PM > > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > Hi Oved, thanks for your feedback! > > > > > We currently return the JSESSIONID also using HTTP headers. We currently > > > return the jsession id also as part of the response HTTP headers, but the > > > client still needs to pass a cookie with the appropriate value in order > > > for the REST session to work. Isn't that enough to cope with this issue? > > > > Right, currently REST API responds with JSESSIONID cookie + separate > > JSESSIONID response header, both carrying session ID value. > > > > As I wrote in my original email: JavaScript running at > > [http://example.com/webapp] *cannot* get/set cookies from requests at > > [http://example.com/restapi] > > > > So WebAdmin cannot get/set REST API JSESSIONID cookie directly, which is > > why > > it uses separate JSESSIONID response header in order to *read* the session > > ID value. As for sending JSESSIONID cookie, WebAdmin currently relies on > > standard cookie-handling implemented in browsers: all cookies for location > > X > > [http://example.com/restapi] will be part of any request to location X. So > > it's the browser who sets JSESSIONID cookie for REST API request, not > > WebAdmin. > > > > To answer your question, currently it's enough to work around the cookie > > access limitation, but it's not good enough in my opinion (from > > JavaScript/webapp perspective).. > > > > > If not, then we might be able to do option #2: > > > Today, we keep the engine session ID on the HTTP session attributes. > > > So, we can support either passing the cookie with the JSESSIONID (taking > > > the engine session ID from the http session), or passing the engine > > > session ID as HTTP header (assuming we would also return the engine > > > session ID upon first REST request). > > > > Well, the problem I described only relates to the way how JSESSIONID value > > is > > transmitted between client and server: currently using cookies, so REST API > > client has to do cookie handling. > > > > It would be really great if I could tell REST API to use plain (i.e. *not* > > Set-Cookie & Cookie) HTTP header, for example "JSESSIONID", for the purpose > > of transmitting session ID value between client and server. > > > > For example, the request to acquire session would be: > > > > GET /api HTTP/1.1 > > Host: www.example.org > > Prefer: use-jsessionid-header > > JSESSIONID: xxx > > > > [Feel free to replace "use-jsessionid-header" with anything you like. If > > client doesn't specify "use-jsessionid-header", server expects "Cookie" > > header by default to preserve compatibility.] > > > > And the response would be: > > > > HTTP/1.1 200 OK > > JSESSIONID: xxx > > > > [If client didn't specify "use-jsessionid-header", server would use > > "Set-Cookie" header by default to preserve compatibility.] > > > > > This approach is problematic, as it might work well now, when the only > > > attribute we use is the engine session ID, but in the future that might > > > not be the case. > > > If it is important enough (i.e., you can't really work with option #1) , > > > then we can make a decision to save the attributes on the engine session, > > > rather than on the HTTP session. > > > So, we would start by supporting them both together, adding new > > > attributes > > > only to the engine session, and in the future deprecating the use of > > > cookies, and only supporting HTTP headers. > > > > I think you can keep the current implementation, i.e. use REST API > > HttpSession to store Engine session ID value. > > > > The only difference would be, when REST API receives the request, it looks > > for "Prefer:use-jsessionid-header", and if it's present, it uses > > "JSESSIONID" header value to look up HttpSession in some way (not sure > > about > > implementation details, though, but this should be possible to do). > > > > So, what do you think? > > > As far as I saw, the handling of the cookie is done before the REST code, and > that's why we need the cookie. > Perhaps there is a way to make jboss take the JSESSIONID from the HTTP > header, and not the cookie, but I didn't find a way to do that yet. > > > Vojtech > > > > > > ----- Original Message ----- > > From: "Oved Ourfalli" > > To: "Vojtech Szocs" > > Cc: "engine-devel" , "Juan Hernandez" > > , "Michael Pasternak" > > Sent: Wednesday, April 17, 2013 11:13:12 AM > > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > > > > > ----- Original Message ----- > > > From: "Vojtech Szocs" > > > To: "engine-devel" > > > Sent: Monday, April 15, 2013 2:04:24 PM > > > Subject: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > > > Hi guys, > > > > > > having worked with Engine REST API from web application (JavaScript) > > > perspective, there are things that could be improved to make REST API > > > more > > > webapp-friendly. > > > > > > First of all, webapps are *not* traditional HTTP clients, i.e. they have > > > *not* full control over HTTP processing. There are some standard > > > conventions > > > and behaviors built into web browsers that any REST API implementation > > > should be aware of. > > > > > > -- > > > > > > (1) Don't force clients to use cookies for transmitting authentication > > > information! (or don't use cookies at all) > > > > > > Good explanation can be found at > > > [http://www.berenddeboer.net/rest/cookies.html]. Cookies have many > > > disadvantages: > > > > > > * cookie parsing/formatting is not trivial > > > --> extra complexity imposed on REST clients > > > > > > * in addition to Same-Origin Policy > > > [http://en.wikipedia.org/wiki/Same_origin_policy], cookies can be get/set > > > *only* for the given path > > > --> JavaScript running at [http://example.com/webapp] *cannot* get/set > > > cookies from requests at [http://example.com/restapi] > > > > > > * cookies are the primary source of Cross-Site Request Forgery > > > [http://en.wikipedia.org/wiki/Cross-site_request_forgery] attacks > > > --> malicious websites/scripts can forge requests to REST API that will > > > include the cookie, compromising user session > > > > > > Alternative: clients could be given the *option* to use regular HTTP > > > header > > > for transmitting authentication information. > > > > > > For example, webapp could read such (sensitive information) header, store > > > it > > > securely via HTML5 Session Storage > > > [http://en.wikipedia.org/wiki/Web_storage] and implement related HTTP > > > processing on its own, e.g. pass this header for all authenticated > > > requests > > > (instead of pushing this responsibility to browser). > > > > > > > Option #1: > > We currently return the JSESSIONID also using HTTP headers. We currently > > return the jsession id also as part of the response HTTP headers, but the > > client still needs to pass a cookie with the appropriate value in order for > > the REST session to work. Isn't that enough to cope with this issue? > > > > If not, then we might be able to do option #2: > > Today, we keep the engine session ID on the HTTP session attributes. > > So, we can support either passing the cookie with the JSESSIONID (taking > > the > > engine session ID from the http session), or passing the engine session ID > > as HTTP header (assuming we would also return the engine session ID upon > > first REST request). > > > > This approach is problematic, as it might work well now, when the only > > attribute we use is the engine session ID, but in the future that might not > > be the case. > > If it is important enough (i.e., you can't really work with option #1) , > > then > > we can make a decision to save the attributes on the engine session, rather > > than on the HTTP session. > > So, we would start by supporting them both together, adding new attributes > > only to the engine session, and in the future deprecating the use of > > cookies, and only supporting HTTP headers. > > > > cc-ed Juan and Michael, as they might have some input on that. > > > > > > > -- > > > > > > (2) Straight-forward HTTP Basic Auth has some drawbacks! > > > > > > HTTP Basic Auth > > > [http://en.wikipedia.org/wiki/Basic_access_authentication] > > > over (non-secure) HTTP connection means sending user credentials > > > (username/password/domain) in easy-to-decode cleartext, i.e. the value is > > > *not* encrypted or hashed in any way. Using secure lower-level protocol > > > (SSL) fixes the consequence, rather than the root cause of the > > > confidentiality issue. > > > > > > Furthermore, browsers typically remember HTTP Basic Auth information > > > (either > > > via browser-specific popup, or via XmlHttpRequest) until the browser > > > window > > > is closed. This means the webapp has no control over HTTP Basic Auth > > > header > > > after it has been set! This is the reason why it's hard to implement > > > "logout" functionality in webapps when using HTTP Basic Auth. > > > > > > Last but not least, HTTP Basic Auth is vulnerable to Replay attacks > > > [http://en.wikipedia.org/wiki/Replay_attack]. Someone between client and > > > server can intercept requests and replay them, compromising user session. > > > > > > Alternative: clients could be given the *option* to use more advanced > > > authentication scheme. > > > > > > I've just read an excellent article at > > > [http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/] > > > which describes easy yet secure authentication scheme inspired by Amazon > > > Web > > > Services REST API authentication > > > [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html]. > > > The idea is simple: collect auth information, hash (sign) it with a > > > private > > > key, and send everything to server. To guard against Replay attacks, just > > > provide some timestamp to enforce request expiry after some time (say, > > > 5-15 > > > minutes). Easy and simple! > > > > > > -- > > > > > > (3) Support JSON for resource representations! > > > > > > I think this is pretty much obvious. XML has no real advantages over > > > JSON. > > > JSON, on the other hand, has good support in webapps (JavaScript) and > > > maps > > > directly to common data structures (i.e. string, number, boolean, and so > > > on). > > > > > > From webapp perspective, it's much easier and natural to use JSON than to > > > parse/format XML documents. > > > > > > Alternative: clients could be given the *option* to use JSON, in addition > > > to > > > XML representation. > > > > > > -- > > > > > > Vojtech > > > _______________________________________________ > > > 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 ecohen at redhat.com Thu Apr 25 07:30:48 2013 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 25 Apr 2013 03:30:48 -0400 (EDT) Subject: [Engine-devel] enable column resizing on all sub-tabs? In-Reply-To: <201304250723.r3P7NuDG012893@gerrit.ovirt.org> References: <201304250723.r3P7NuDG012893@gerrit.ovirt.org> Message-ID: <1517757415.4320624.1366875048839.JavaMail.root@redhat.com> Vojtech[/others] - what do you think about Gilad's comment below? would it be possible / more correct to activate column resizing within the base grid class itself by default (or something similar), rather than enable it separately for each grid? [@Gilad - keep in mind that IIUC - each column in each grid still needs to have its width explicitly set] ---- Thanks, Einav ----- Original Message ----- > From: gchaplik at redhat.com > To: "Daniel Erez" > Cc: "Einav Cohen" , "Vojtech Szocs" , "Alona Kaplan" , > "Tal Nisan" > Sent: Thursday, April 25, 2013 3:23:56 AM > Subject: Change in ovirt-engine[master]: webadmin: DataCenters main-tab: sub-tabs resizable columns > > Gilad Chaplik has posted comments on this change. > > Change subject: webadmin: DataCenters main-tab: sub-tabs resizable columns > ...................................................................... > > > Patch Set 4: > > why we need to invoke getTable().enableColumnResizing() on each sub-tab? > don't we want all grid subtabs to have column resizing? > > -- > To view, visit http://gerrit.ovirt.org/14105 > To unsubscribe, visit http://gerrit.ovirt.org/settings > > Gerrit-MessageType: comment > Gerrit-Change-Id: I71465d36e5c18ecb8eb6dbca436feaeea1c902a9 > Gerrit-PatchSet: 4 > Gerrit-Project: ovirt-engine > Gerrit-Branch: master > Gerrit-Owner: Daniel Erez > Gerrit-Reviewer: Alona Kaplan > Gerrit-Reviewer: Daniel Erez > Gerrit-Reviewer: Einav Cohen > Gerrit-Reviewer: Gilad Chaplik > Gerrit-Reviewer: Tal Nisan > Gerrit-Reviewer: Vojtech Szocs > From gchaplik at redhat.com Thu Apr 25 07:41:53 2013 From: gchaplik at redhat.com (Gilad Chaplik) Date: Thu, 25 Apr 2013 03:41:53 -0400 (EDT) Subject: [Engine-devel] enable column resizing on all sub-tabs? In-Reply-To: <1517757415.4320624.1366875048839.JavaMail.root@redhat.com> References: <201304250723.r3P7NuDG012893@gerrit.ovirt.org> <1517757415.4320624.1366875048839.JavaMail.root@redhat.com> Message-ID: <1566604868.2145454.1366875713744.JavaMail.root@redhat.com> imo the preliminary patches (separated or not) should be only adding the missing columns widths. once done, a single patch should activate column re-sizing in a single shot -i.e removing the method (enableColumn...) and enabling the feature. btw, what is the time in Boston? Thanks, Gilad. ----- Original Message ----- > From: "Einav Cohen" > To: "Vojtech Szocs" > Cc: "Daniel Erez" , "Alona Kaplan" , "Tal Nisan" , > gchaplik at redhat.com, "engine-devel" > Sent: Thursday, April 25, 2013 10:30:48 AM > Subject: enable column resizing on all sub-tabs? > > Vojtech[/others] - what do you think about Gilad's comment below? > would it be possible / more correct to activate column resizing within the > base grid class itself by default (or something similar), rather than enable > it separately for each grid? > > [@Gilad - keep in mind that IIUC - each column in each grid still needs to > have > its width explicitly set] > > ---- > Thanks, > Einav > > ----- Original Message ----- > > From: gchaplik at redhat.com > > To: "Daniel Erez" > > Cc: "Einav Cohen" , "Vojtech Szocs" , > > "Alona Kaplan" , > > "Tal Nisan" > > Sent: Thursday, April 25, 2013 3:23:56 AM > > Subject: Change in ovirt-engine[master]: webadmin: DataCenters main-tab: > > sub-tabs resizable columns > > > > Gilad Chaplik has posted comments on this change. > > > > Change subject: webadmin: DataCenters main-tab: sub-tabs resizable columns > > ...................................................................... > > > > > > Patch Set 4: > > > > why we need to invoke getTable().enableColumnResizing() on each sub-tab? > > don't we want all grid subtabs to have column resizing? > > > > -- > > To view, visit http://gerrit.ovirt.org/14105 > > To unsubscribe, visit http://gerrit.ovirt.org/settings > > > > Gerrit-MessageType: comment > > Gerrit-Change-Id: I71465d36e5c18ecb8eb6dbca436feaeea1c902a9 > > Gerrit-PatchSet: 4 > > Gerrit-Project: ovirt-engine > > Gerrit-Branch: master > > Gerrit-Owner: Daniel Erez > > Gerrit-Reviewer: Alona Kaplan > > Gerrit-Reviewer: Daniel Erez > > Gerrit-Reviewer: Einav Cohen > > Gerrit-Reviewer: Gilad Chaplik > > Gerrit-Reviewer: Tal Nisan > > Gerrit-Reviewer: Vojtech Szocs > > > From derez at redhat.com Thu Apr 25 10:22:02 2013 From: derez at redhat.com (Daniel Erez) Date: Thu, 25 Apr 2013 06:22:02 -0400 (EDT) Subject: [Engine-devel] enable column resizing on all sub-tabs? In-Reply-To: <1517757415.4320624.1366875048839.JavaMail.root@redhat.com> References: <201304250723.r3P7NuDG012893@gerrit.ovirt.org> <1517757415.4320624.1366875048839.JavaMail.root@redhat.com> Message-ID: <137795451.2244757.1366885322595.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Vojtech Szocs" > Cc: "Daniel Erez" , "Alona Kaplan" , "Tal Nisan" , > gchaplik at redhat.com, "engine-devel" > Sent: Thursday, April 25, 2013 10:30:48 AM > Subject: enable column resizing on all sub-tabs? > > Vojtech[/others] - what do you think about Gilad's comment below? > would it be possible / more correct to activate column resizing within the > base grid class itself by default (or something similar), rather than enable > it separately for each grid? > > [@Gilad - keep in mind that IIUC - each column in each grid still needs to > have > its width explicitly set] We probably should just replace enableColumnResizing() with disbaleColumnResizing() in favor of the problematic sub-tabs. But I think it can wait till we're done adding the support (i.e. set width explicitly for each column). What do you think? > > ---- > Thanks, > Einav > > ----- Original Message ----- > > From: gchaplik at redhat.com > > To: "Daniel Erez" > > Cc: "Einav Cohen" , "Vojtech Szocs" , > > "Alona Kaplan" , > > "Tal Nisan" > > Sent: Thursday, April 25, 2013 3:23:56 AM > > Subject: Change in ovirt-engine[master]: webadmin: DataCenters main-tab: > > sub-tabs resizable columns > > > > Gilad Chaplik has posted comments on this change. > > > > Change subject: webadmin: DataCenters main-tab: sub-tabs resizable columns > > ...................................................................... > > > > > > Patch Set 4: > > > > why we need to invoke getTable().enableColumnResizing() on each sub-tab? > > don't we want all grid subtabs to have column resizing? > > > > -- > > To view, visit http://gerrit.ovirt.org/14105 > > To unsubscribe, visit http://gerrit.ovirt.org/settings > > > > Gerrit-MessageType: comment > > Gerrit-Change-Id: I71465d36e5c18ecb8eb6dbca436feaeea1c902a9 > > Gerrit-PatchSet: 4 > > Gerrit-Project: ovirt-engine > > Gerrit-Branch: master > > Gerrit-Owner: Daniel Erez > > Gerrit-Reviewer: Alona Kaplan > > Gerrit-Reviewer: Daniel Erez > > Gerrit-Reviewer: Einav Cohen > > Gerrit-Reviewer: Gilad Chaplik > > Gerrit-Reviewer: Tal Nisan > > Gerrit-Reviewer: Vojtech Szocs > > > From ecohen at redhat.com Thu Apr 25 10:33:06 2013 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 25 Apr 2013 06:33:06 -0400 (EDT) Subject: [Engine-devel] enable column resizing on all sub-tabs? In-Reply-To: <137795451.2244757.1366885322595.JavaMail.root@redhat.com> References: <201304250723.r3P7NuDG012893@gerrit.ovirt.org> <1517757415.4320624.1366875048839.JavaMail.root@redhat.com> <137795451.2244757.1366885322595.JavaMail.root@redhat.com> Message-ID: <69913673.4416995.1366885986814.JavaMail.root@redhat.com> > ----- Original Message ----- > From: "Daniel Erez" > Sent: Thursday, April 25, 2013 6:22:02 AM > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Vojtech Szocs" > > Cc: "Daniel Erez" , "Alona Kaplan" , > > "Tal Nisan" , > > gchaplik at redhat.com, "engine-devel" > > Sent: Thursday, April 25, 2013 10:30:48 AM > > Subject: enable column resizing on all sub-tabs? > > > > Vojtech[/others] - what do you think about Gilad's comment below? > > would it be possible / more correct to activate column resizing within the > > base grid class itself by default (or something similar), rather than > > enable > > it separately for each grid? > > > > [@Gilad - keep in mind that IIUC - each column in each grid still needs to > > have > > its width explicitly set] > > We probably should just replace enableColumnResizing() with > disbaleColumnResizing() > in favor of the problematic sub-tabs. But I think it can wait till we're done > adding the support (i.e. set width explicitly for each column). > > What do you think? indeed - no matter how we decide to exactly approach this: if the general approach is to enable column resizing by default in the base widget class, we need to take care of preparing the widget instances first, i.e., set their columns' widths. I suggest that we will proceed with the patches that were already written as they are, and also write the upcoming patches in the same manner (i.e. explicitly "enableColumnResizing()" each one of the widget instances + set the widths), verify that everything is working/looking OK, and only then - create the patch that replaces the "enableColumnResizing()" method with the "disbaleColumnResizing()" method (and removes all calls to "enableColumnResizing()"), which will actually be only a code-change/refactoring patch (i.e. will have no affect on the application behavior). acks/nacks/comments? > > > > > ---- > > Thanks, > > Einav > > > > ----- Original Message ----- > > > From: gchaplik at redhat.com > > > To: "Daniel Erez" > > > Cc: "Einav Cohen" , "Vojtech Szocs" > > > , > > > "Alona Kaplan" , > > > "Tal Nisan" > > > Sent: Thursday, April 25, 2013 3:23:56 AM > > > Subject: Change in ovirt-engine[master]: webadmin: DataCenters main-tab: > > > sub-tabs resizable columns > > > > > > Gilad Chaplik has posted comments on this change. > > > > > > Change subject: webadmin: DataCenters main-tab: sub-tabs resizable > > > columns > > > ...................................................................... > > > > > > > > > Patch Set 4: > > > > > > why we need to invoke getTable().enableColumnResizing() on each sub-tab? > > > don't we want all grid subtabs to have column resizing? > > > > > > -- > > > To view, visit http://gerrit.ovirt.org/14105 > > > To unsubscribe, visit http://gerrit.ovirt.org/settings > > > > > > Gerrit-MessageType: comment > > > Gerrit-Change-Id: I71465d36e5c18ecb8eb6dbca436feaeea1c902a9 > > > Gerrit-PatchSet: 4 > > > Gerrit-Project: ovirt-engine > > > Gerrit-Branch: master > > > Gerrit-Owner: Daniel Erez > > > Gerrit-Reviewer: Alona Kaplan > > > Gerrit-Reviewer: Daniel Erez > > > Gerrit-Reviewer: Einav Cohen > > > Gerrit-Reviewer: Gilad Chaplik > > > Gerrit-Reviewer: Tal Nisan > > > Gerrit-Reviewer: Vojtech Szocs > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From vszocs at redhat.com Thu Apr 25 14:47:31 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 25 Apr 2013 10:47:31 -0400 (EDT) Subject: [Engine-devel] enable column resizing on all sub-tabs? In-Reply-To: <1566604868.2145454.1366875713744.JavaMail.root@redhat.com> References: <201304250723.r3P7NuDG012893@gerrit.ovirt.org> <1517757415.4320624.1366875048839.JavaMail.root@redhat.com> <1566604868.2145454.1366875713744.JavaMail.root@redhat.com> Message-ID: <1347332932.2742597.1366901251075.JavaMail.root@redhat.com> Hi guys, the reason why we need to call enableColumnResizing() explicitly is because currently, action tables which don't use enableColumnResizing() yet have at least one column *without* explicit width in PX units. After calling enableColumnResizing(), you *must* specify (absolute) column width in PX units when calling addColumn(). If you don't do this, column resize behavior will be messed up -- all columns simply need to have (absolute) explicit widths in order for resize behavior to work correctly. So we cannot simply call enableColumnResizing() on higher level (i.e. AbstractSubTabTableView), just because specific implementations are not always calling addColumn() using explicit width.. > imo the preliminary patches (separated or not) should be only adding the missing columns widths. > once done, a single patch should activate column re-sizing in a single shot -i.e removing the method (enableColumn...) and enabling the feature. I'm not against this, but it requires us to fix all (specific) tables before we enable resizing on higher level (i.e. AbstractSubTabTableView). Vojtech ----- Original Message ----- From: "Gilad Chaplik" To: "Einav Cohen" Cc: "Vojtech Szocs" , "Daniel Erez" , "Alona Kaplan" , "Tal Nisan" , "engine-devel" Sent: Thursday, April 25, 2013 9:41:53 AM Subject: Re: enable column resizing on all sub-tabs? imo the preliminary patches (separated or not) should be only adding the missing columns widths. once done, a single patch should activate column re-sizing in a single shot -i.e removing the method (enableColumn...) and enabling the feature. btw, what is the time in Boston? Thanks, Gilad. ----- Original Message ----- > From: "Einav Cohen" > To: "Vojtech Szocs" > Cc: "Daniel Erez" , "Alona Kaplan" , "Tal Nisan" , > gchaplik at redhat.com, "engine-devel" > Sent: Thursday, April 25, 2013 10:30:48 AM > Subject: enable column resizing on all sub-tabs? > > Vojtech[/others] - what do you think about Gilad's comment below? > would it be possible / more correct to activate column resizing within the > base grid class itself by default (or something similar), rather than enable > it separately for each grid? > > [@Gilad - keep in mind that IIUC - each column in each grid still needs to > have > its width explicitly set] > > ---- > Thanks, > Einav > > ----- Original Message ----- > > From: gchaplik at redhat.com > > To: "Daniel Erez" > > Cc: "Einav Cohen" , "Vojtech Szocs" , > > "Alona Kaplan" , > > "Tal Nisan" > > Sent: Thursday, April 25, 2013 3:23:56 AM > > Subject: Change in ovirt-engine[master]: webadmin: DataCenters main-tab: > > sub-tabs resizable columns > > > > Gilad Chaplik has posted comments on this change. > > > > Change subject: webadmin: DataCenters main-tab: sub-tabs resizable columns > > ...................................................................... > > > > > > Patch Set 4: > > > > why we need to invoke getTable().enableColumnResizing() on each sub-tab? > > don't we want all grid subtabs to have column resizing? > > > > -- > > To view, visit http://gerrit.ovirt.org/14105 > > To unsubscribe, visit http://gerrit.ovirt.org/settings > > > > Gerrit-MessageType: comment > > Gerrit-Change-Id: I71465d36e5c18ecb8eb6dbca436feaeea1c902a9 > > Gerrit-PatchSet: 4 > > Gerrit-Project: ovirt-engine > > Gerrit-Branch: master > > Gerrit-Owner: Daniel Erez > > Gerrit-Reviewer: Alona Kaplan > > Gerrit-Reviewer: Daniel Erez > > Gerrit-Reviewer: Einav Cohen > > Gerrit-Reviewer: Gilad Chaplik > > Gerrit-Reviewer: Tal Nisan > > Gerrit-Reviewer: Vojtech Szocs > > > From vszocs at redhat.com Thu Apr 25 14:50:01 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 25 Apr 2013 10:50:01 -0400 (EDT) Subject: [Engine-devel] enable column resizing on all sub-tabs? In-Reply-To: <137795451.2244757.1366885322595.JavaMail.root@redhat.com> References: <201304250723.r3P7NuDG012893@gerrit.ovirt.org> <1517757415.4320624.1366875048839.JavaMail.root@redhat.com> <137795451.2244757.1366885322595.JavaMail.root@redhat.com> Message-ID: <20173720.2743352.1366901401980.JavaMail.root@redhat.com> Hi Daniel, > We probably should just replace enableColumnResizing() with disbaleColumnResizing() > in favor of the problematic sub-tabs. But I think it can wait till we're done > adding the support (i.e. set width explicitly for each column). I agree, it makes sense, but I'd prefer to do this kind of API/behavior inversion later on (but I'm all for it). Vojtech ----- Original Message ----- From: "Daniel Erez" To: "Einav Cohen" Cc: "Vojtech Szocs" , "Alona Kaplan" , "Tal Nisan" , gchaplik at redhat.com, "engine-devel" Sent: Thursday, April 25, 2013 12:22:02 PM Subject: Re: enable column resizing on all sub-tabs? ----- Original Message ----- > From: "Einav Cohen" > To: "Vojtech Szocs" > Cc: "Daniel Erez" , "Alona Kaplan" , "Tal Nisan" , > gchaplik at redhat.com, "engine-devel" > Sent: Thursday, April 25, 2013 10:30:48 AM > Subject: enable column resizing on all sub-tabs? > > Vojtech[/others] - what do you think about Gilad's comment below? > would it be possible / more correct to activate column resizing within the > base grid class itself by default (or something similar), rather than enable > it separately for each grid? > > [@Gilad - keep in mind that IIUC - each column in each grid still needs to > have > its width explicitly set] We probably should just replace enableColumnResizing() with disbaleColumnResizing() in favor of the problematic sub-tabs. But I think it can wait till we're done adding the support (i.e. set width explicitly for each column). What do you think? > > ---- > Thanks, > Einav > > ----- Original Message ----- > > From: gchaplik at redhat.com > > To: "Daniel Erez" > > Cc: "Einav Cohen" , "Vojtech Szocs" , > > "Alona Kaplan" , > > "Tal Nisan" > > Sent: Thursday, April 25, 2013 3:23:56 AM > > Subject: Change in ovirt-engine[master]: webadmin: DataCenters main-tab: > > sub-tabs resizable columns > > > > Gilad Chaplik has posted comments on this change. > > > > Change subject: webadmin: DataCenters main-tab: sub-tabs resizable columns > > ...................................................................... > > > > > > Patch Set 4: > > > > why we need to invoke getTable().enableColumnResizing() on each sub-tab? > > don't we want all grid subtabs to have column resizing? > > > > -- > > To view, visit http://gerrit.ovirt.org/14105 > > To unsubscribe, visit http://gerrit.ovirt.org/settings > > > > Gerrit-MessageType: comment > > Gerrit-Change-Id: I71465d36e5c18ecb8eb6dbca436feaeea1c902a9 > > Gerrit-PatchSet: 4 > > Gerrit-Project: ovirt-engine > > Gerrit-Branch: master > > Gerrit-Owner: Daniel Erez > > Gerrit-Reviewer: Alona Kaplan > > Gerrit-Reviewer: Daniel Erez > > Gerrit-Reviewer: Einav Cohen > > Gerrit-Reviewer: Gilad Chaplik > > Gerrit-Reviewer: Tal Nisan > > Gerrit-Reviewer: Vojtech Szocs > > > From vszocs at redhat.com Thu Apr 25 16:35:39 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 25 Apr 2013 12:35:39 -0400 (EDT) Subject: [Engine-devel] enable column resizing on all sub-tabs? In-Reply-To: <69913673.4416995.1366885986814.JavaMail.root@redhat.com> References: <201304250723.r3P7NuDG012893@gerrit.ovirt.org> <1517757415.4320624.1366875048839.JavaMail.root@redhat.com> <137795451.2244757.1366885322595.JavaMail.root@redhat.com> <69913673.4416995.1366885986814.JavaMail.root@redhat.com> Message-ID: <303505665.2792211.1366907739401.JavaMail.root@redhat.com> Hi, > I suggest that we will proceed with the patches that were already written as they are, and > also write the upcoming patches in the same manner (i.e. explicitly "enableColumnResizing()" > each one of the widget instances + set the widths), verify that everything is working/looking OK, > and only then - create the patch that replaces the "enableColumnResizing()" method with the > "disbaleColumnResizing()" method (and removes all calls to "enableColumnResizing()"), which will > actually be only a code-change/refactoring patch (i.e. will have no affect on the application behavior). ack [I'd suggest to verify that addColumn() is always called with explicit width first, before changing enable -> disable API] Vojtech ----- Original Message ----- From: "Einav Cohen" To: "Daniel Erez" , "Vojtech Szocs" , "Gilad Chaplik" Cc: "engine-devel" Sent: Thursday, April 25, 2013 12:33:06 PM Subject: Re: [Engine-devel] enable column resizing on all sub-tabs? > ----- Original Message ----- > From: "Daniel Erez" > Sent: Thursday, April 25, 2013 6:22:02 AM > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Vojtech Szocs" > > Cc: "Daniel Erez" , "Alona Kaplan" , > > "Tal Nisan" , > > gchaplik at redhat.com, "engine-devel" > > Sent: Thursday, April 25, 2013 10:30:48 AM > > Subject: enable column resizing on all sub-tabs? > > > > Vojtech[/others] - what do you think about Gilad's comment below? > > would it be possible / more correct to activate column resizing within the > > base grid class itself by default (or something similar), rather than > > enable > > it separately for each grid? > > > > [@Gilad - keep in mind that IIUC - each column in each grid still needs to > > have > > its width explicitly set] > > We probably should just replace enableColumnResizing() with > disbaleColumnResizing() > in favor of the problematic sub-tabs. But I think it can wait till we're done > adding the support (i.e. set width explicitly for each column). > > What do you think? indeed - no matter how we decide to exactly approach this: if the general approach is to enable column resizing by default in the base widget class, we need to take care of preparing the widget instances first, i.e., set their columns' widths. I suggest that we will proceed with the patches that were already written as they are, and also write the upcoming patches in the same manner (i.e. explicitly "enableColumnResizing()" each one of the widget instances + set the widths), verify that everything is working/looking OK, and only then - create the patch that replaces the "enableColumnResizing()" method with the "disbaleColumnResizing()" method (and removes all calls to "enableColumnResizing()"), which will actually be only a code-change/refactoring patch (i.e. will have no affect on the application behavior). acks/nacks/comments? > > > > > ---- > > Thanks, > > Einav > > > > ----- Original Message ----- > > > From: gchaplik at redhat.com > > > To: "Daniel Erez" > > > Cc: "Einav Cohen" , "Vojtech Szocs" > > > , > > > "Alona Kaplan" , > > > "Tal Nisan" > > > Sent: Thursday, April 25, 2013 3:23:56 AM > > > Subject: Change in ovirt-engine[master]: webadmin: DataCenters main-tab: > > > sub-tabs resizable columns > > > > > > Gilad Chaplik has posted comments on this change. > > > > > > Change subject: webadmin: DataCenters main-tab: sub-tabs resizable > > > columns > > > ...................................................................... > > > > > > > > > Patch Set 4: > > > > > > why we need to invoke getTable().enableColumnResizing() on each sub-tab? > > > don't we want all grid subtabs to have column resizing? > > > > > > -- > > > To view, visit http://gerrit.ovirt.org/14105 > > > To unsubscribe, visit http://gerrit.ovirt.org/settings > > > > > > Gerrit-MessageType: comment > > > Gerrit-Change-Id: I71465d36e5c18ecb8eb6dbca436feaeea1c902a9 > > > Gerrit-PatchSet: 4 > > > Gerrit-Project: ovirt-engine > > > Gerrit-Branch: master > > > Gerrit-Owner: Daniel Erez > > > Gerrit-Reviewer: Alona Kaplan > > > Gerrit-Reviewer: Daniel Erez > > > Gerrit-Reviewer: Einav Cohen > > > Gerrit-Reviewer: Gilad Chaplik > > > Gerrit-Reviewer: Tal Nisan > > > Gerrit-Reviewer: Vojtech Szocs > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From ecohen at redhat.com Thu Apr 25 16:48:16 2013 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 25 Apr 2013 12:48:16 -0400 (EDT) Subject: [Engine-devel] enable column resizing on all sub-tabs? In-Reply-To: <303505665.2792211.1366907739401.JavaMail.root@redhat.com> References: <201304250723.r3P7NuDG012893@gerrit.ovirt.org> <1517757415.4320624.1366875048839.JavaMail.root@redhat.com> <137795451.2244757.1366885322595.JavaMail.root@redhat.com> <69913673.4416995.1366885986814.JavaMail.root@redhat.com> <303505665.2792211.1366907739401.JavaMail.root@redhat.com> Message-ID: <725928330.4812099.1366908496715.JavaMail.root@redhat.com> > ----- Original Message ----- > From: "Vojtech Szocs" > Sent: Thursday, April 25, 2013 12:35:39 PM > > Hi, > > > I suggest that we will proceed with the patches that were already written > > as they are, and > > also write the upcoming patches in the same manner (i.e. explicitly > > "enableColumnResizing()" > > each one of the widget instances + set the widths), verify that everything > > is working/looking OK, > > and only then - create the patch that replaces the "enableColumnResizing()" > > method with the > > "disbaleColumnResizing()" method (and removes all calls to > > "enableColumnResizing()"), which will > > actually be only a code-change/refactoring patch (i.e. will have no affect > > on the application behavior). > > ack thanks, Vojtech. > > [I'd suggest to verify that addColumn() is always called with explicit width > first, before changing enable -> disable API] ack :) > > Vojtech > > > ----- Original Message ----- > From: "Einav Cohen" > To: "Daniel Erez" , "Vojtech Szocs" , > "Gilad Chaplik" > Cc: "engine-devel" > Sent: Thursday, April 25, 2013 12:33:06 PM > Subject: Re: [Engine-devel] enable column resizing on all sub-tabs? > > > ----- Original Message ----- > > From: "Daniel Erez" > > Sent: Thursday, April 25, 2013 6:22:02 AM > > > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Vojtech Szocs" > > > Cc: "Daniel Erez" , "Alona Kaplan" > > > , > > > "Tal Nisan" , > > > gchaplik at redhat.com, "engine-devel" > > > Sent: Thursday, April 25, 2013 10:30:48 AM > > > Subject: enable column resizing on all sub-tabs? > > > > > > Vojtech[/others] - what do you think about Gilad's comment below? > > > would it be possible / more correct to activate column resizing within > > > the > > > base grid class itself by default (or something similar), rather than > > > enable > > > it separately for each grid? > > > > > > [@Gilad - keep in mind that IIUC - each column in each grid still needs > > > to > > > have > > > its width explicitly set] > > > > We probably should just replace enableColumnResizing() with > > disbaleColumnResizing() > > in favor of the problematic sub-tabs. But I think it can wait till we're > > done > > adding the support (i.e. set width explicitly for each column). > > > > What do you think? > > indeed - no matter how we decide to exactly approach this: if the general > approach is to enable > column resizing by default in the base widget class, we need to take care of > preparing the widget > instances first, i.e., set their columns' widths. > > I suggest that we will proceed with the patches that were already written as > they are, and > also write the upcoming patches in the same manner (i.e. explicitly > "enableColumnResizing()" > each one of the widget instances + set the widths), verify that everything is > working/looking OK, > and only then - create the patch that replaces the "enableColumnResizing()" > method with the > "disbaleColumnResizing()" method (and removes all calls to > "enableColumnResizing()"), which will > actually be only a code-change/refactoring patch (i.e. will have no affect on > the application behavior). > > acks/nacks/comments? > > > > > > > > > ---- > > > Thanks, > > > Einav > > > > > > ----- Original Message ----- > > > > From: gchaplik at redhat.com > > > > To: "Daniel Erez" > > > > Cc: "Einav Cohen" , "Vojtech Szocs" > > > > , > > > > "Alona Kaplan" , > > > > "Tal Nisan" > > > > Sent: Thursday, April 25, 2013 3:23:56 AM > > > > Subject: Change in ovirt-engine[master]: webadmin: DataCenters > > > > main-tab: > > > > sub-tabs resizable columns > > > > > > > > Gilad Chaplik has posted comments on this change. > > > > > > > > Change subject: webadmin: DataCenters main-tab: sub-tabs resizable > > > > columns > > > > ...................................................................... > > > > > > > > > > > > Patch Set 4: > > > > > > > > why we need to invoke getTable().enableColumnResizing() on each > > > > sub-tab? > > > > don't we want all grid subtabs to have column resizing? > > > > > > > > -- > > > > To view, visit http://gerrit.ovirt.org/14105 > > > > To unsubscribe, visit http://gerrit.ovirt.org/settings > > > > > > > > Gerrit-MessageType: comment > > > > Gerrit-Change-Id: I71465d36e5c18ecb8eb6dbca436feaeea1c902a9 > > > > Gerrit-PatchSet: 4 > > > > Gerrit-Project: ovirt-engine > > > > Gerrit-Branch: master > > > > Gerrit-Owner: Daniel Erez > > > > Gerrit-Reviewer: Alona Kaplan > > > > Gerrit-Reviewer: Daniel Erez > > > > Gerrit-Reviewer: Einav Cohen > > > > Gerrit-Reviewer: Gilad Chaplik > > > > Gerrit-Reviewer: Tal Nisan > > > > Gerrit-Reviewer: Vojtech Szocs > > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > From bigclouds at 163.com Sat Apr 27 05:40:56 2013 From: bigclouds at 163.com (bigclouds) Date: Sat, 27 Apr 2013 13:40:56 +0800 (CST) Subject: [Engine-devel] the procedure of storage-related Message-ID: <3a28758f.8586.13e4a022bf4.Coremail.bigclouds@163.com> hi,all 1.i am now not very familar with the right procedure of storage, please give me a simply introduction of their concept and relation. help me out StoragePool,StorageDomain image,volume 2.please help me confirm. i find only one place call mount command, which is poolConnectStorageServer. if poolConnectStorageServer is before create and active StoragePool,StorageDomain? 3.if attach is just modify metadata, not anything else? 4.sp.py, deactivateSD if i deactivate ISO storage,it finally umount masterDir, why ? if masterDir is not mastersd? thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From wei.d.chen at intel.com Sat Apr 27 06:36:44 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Sat, 27 Apr 2013 06:36:44 +0000 Subject: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated In-Reply-To: <2082103465.271823.1366559881373.JavaMail.root@redhat.com> References: <5172AB0B.1070803@redhat.com> <855522037.76793.1366522910666.JavaMail.root@redhat.com> <590451846.29858.1366528410731.JavaMail.root@redhat.com> <51739331.1020503@redhat.com> <1965040641.30114.1366529345380.JavaMail.root@redhat.com> <2082103465.271823.1366559881373.JavaMail.root@redhat.com> Message-ID: Hi, Our current consideration is add a new thread in engine's side to attest all of hosts (aggregated query from attestation sever) one time in case of engine's rebooting. There is still one potential issue under extreme condition, saying, hundreds of nodes in a datacenter, attest all of hosts still may take couple of mins, let's say, one hacked untrusted node before receiving the latest status may considered as a trusted host, so, the worst case in a datacenter with hundreds of nodes is, 1. engine is down for some reasons and boot up again, some trusted nodes may be hacked and rebooted during this period. 2. our thread is running to get all of node's status (trust /untrusted), may take couple of mins in large datacenter. 2. user create VMs on these hacked nodes and believe these VMs are trusted VMs launched on trusted nodes. 3. our thread get the correct status of these untrusted nodes, set these nodes as non-operational. 4. all of these "trusted" VMs running on these untrusted nodes are expected to migrate to other trusted node. So, the question is in a trusted cluster with hundreds of nodes some VMs expected to create on trusted nodes may actually create on untrusted nodes instead, and this time may last for couple of mins. (worst case in my view is 10 mins with 1000 nodes). Does this acceptable from your point of view? Or any other suggestion? Best Regards, Dave Chen > -----Original Message----- > From: Doron Fediuck [mailto:dfediuck at redhat.com] > Sent: Sunday, April 21, 2013 11:58 PM > To: Chen, Wei D > Cc: Ofri Masad; Oved Ourfalli; engine-devel at ovirt.org > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools > integration with oVirt has been updated > > > > ----- Original Message ----- > > From: "Wei D Chen" > > To: "Ofri Masad" > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > Sent: Sunday, April 21, 2013 4:00:55 PM > > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools > > integration with oVirt has been updated > > > > Ofri, > > > > Absolutely right, aggregated query has a significantly time improve > > compared to separated queries. I agree a aggregated query on engine's > > starting. Is it possible to invoke attestation service in engine's > > initialization code block instead of "quartz job"? Is there any class similar with > " > > InitVdsOnUpCommand " for engine's initialization? > > > > Best Regards, > > Dave Chen > > > org.ovirt.engine.core.bll.Backend.Initialize() > > Note you cannot block this method while waiting for results. > Instead I suggest you fire a one-time background request from this method. > > > > -----Original Message----- > > From: Ofri Masad [mailto:omasad at redhat.com] > > Sent: Sunday, April 21, 2013 3:29 PM > > To: Chen, Wei D > > Cc: Oved Ourfalli; engine-devel at ovirt.org; Itamar Heim > > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools > > integration with oVirt has been updated > > > > Dave, > > > > If I'm not mistaking, there is a big difference between separated > > queries to the attestation server and aggregated one? > > Is it true? > > > > Thanks, > > Ofri > > > > ----- Original Message ----- > > > From: "Itamar Heim" > > > To: "Ofri Masad" > > > Cc: "Oved Ourfalli" , "Wei D Chen" > > > , engine-devel at ovirt.org > > > Sent: Sunday, April 21, 2013 10:20:17 AM > > > Subject: Re: [Engine-devel] Design wiki page for trusted compute > > > pools integration with oVirt has been updated > > > > > > On 04/21/2013 10:13 AM, Ofri Masad wrote: > > > > Hi, > > > > One more thing we need to think about for the second approach - > > > > aggregated query. On engine start we need to determine the trust > > > > state of all the hosts. sending a separate query for each host > > > > will overload the attestation host and the network. an initial > > > > aggregated query needs to be send when the engine starts. > > > > Same thing can happen after management network fail and so on. > > > > Maybe we can run a quartz job every x minutes, checking if a large > > > > part of the hosts in the cluster (like 30%) are untrusted - in > > > > that case run the aggregated query. > > > > > > are we sure this optimization is needed? > > > how heavy/latent is the call to the attestation service? > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From liqiang.net at gmail.com Sun Apr 28 07:37:14 2013 From: liqiang.net at gmail.com (=?UTF-8?B?5p2O5by6?=) Date: Sun, 28 Apr 2013 15:37:14 +0800 Subject: [Engine-devel] Error: could not create ovirtsdk API object Message-ID: HI?All I build source and rpm -Uvh ovirt-engine-setup-plugin-allinone-3.3.0-0.2.master.20130427145036.fc18.noarch.rpm But I engine-setup have ERROR. Error: could not create ovirtsdk API object OS:F18 mini install. =================================== [root at localhost ~]# engine-setup Welcome to oVirt Engine setup utility WARNING: oVirt Engine setup has already been run on this host. To remove all configuration and reset oVirt Engine please run engine-cleanup. Please be advised that executing engine-setup without cleanup is not supported. Would you like to proceed? (yes|no): yes In order to proceed the installer must stop the ovirt-engine service Would you like to stop the ovirt-engine service? (yes|no): yes oVirt Engine uses httpd to proxy requests to the application server. It looks like the httpd installed locally is being actively used. The installer can override current configuration . Alternatively you can use JBoss directly (on ports higher than 1024) Do you wish to override current httpd configuration and restart the service? ['yes'| 'no'] [yes] : HTTP Port [80] : HTTPS Port [443] : Setup can configure server default page to launch oVirt Engine. Do you wish to do so? ['yes'| 'no'] [yes] : Host fully qualified domain name. Note: this name should be fully resolvable [localhost] : engine.startn.com Enter a password for an internal oVirt Engine administrator user (admin at internal) : Warning: Weak Password. Confirm password : Organization Name for the Certificate [localhost] : The engine can be configured to present the UI in three different application modes. virt [Manage virtualization only], gluster [Manage gluster storage only], and both [Manage virtualization as well as gluster storage] ['virt'| 'gluster'| 'both'] [both] : The default storage type you will be using ['NFS'| 'FC'| 'ISCSI'| 'POSIXFS'] [NFS] : Enter DB type for installation ['remote'| 'local'] [local] : Enter a password for a local oVirt Engine DB admin user (engine) : Warning: Weak Password. Confirm password : Local ISO domain path [/var/lib/exports/iso_2013_04_28_15_18_22] : Firewall ports need to be opened. The installer can configure firewall automatically overriding the current configuration. The old configuration will be backed up. Alternately you can configure the firewall later using an example file selecting None. Which firewall manager do you wish to use? ['None'| 'Firewalld'| 'iptables']: Firewalld Configure VDSM on this host? ['yes'| 'no'] [yes] : yes Local storage domain path [/var/lib/images_2013_04_28_15_18_22] : Confirm root password : oVirt Engine will be installed using the following configuration: ================================================================= override-httpd-config: yes http-port: 80 https-port: 443 override-httpd-root: yes host-fqdn: engine.startn.com auth-pass: ******** org-name: localhost application-mode: both default-dc-type: NFS db-remote-install: local db-local-pass: ******** nfs-mp: /var/lib/exports/iso_2013_04_28_15_18_22 firewall-manager: Firewalld config-allinone: yes storage-path: /var/lib/images_2013_04_28_15_18_22 superuser-pass: ******** Proceed with the configuration listed above? (yes|no): yes Installing: AIO: Validating CPU Compatibility... [ DONE ] AIO: Adding firewall rules... [ DONE ] Configuring oVirt Engine... [ DONE ] Configuring JVM... [ DONE ] Creating CA... [ DONE ] Updating ovirt-engine service... [ DONE ] Setting Database Configuration... [ DONE ] Setting Database Security... [ DONE ] Upgrading Database Schema... [ DONE ] Editing oVirt Engine Configuration... [ DONE ] Editing Postgresql Configuration... [ DONE ] Configuring the Default ISO Domain... [ DONE ] Configuring Firewall... [ DONE ] Starting ovirt-engine Service... [ DONE ] Configuring HTTPD... [ DONE ] AIO: Creating storage directory... [ DONE ] AIO: Adding Local Datacenter and cluster... [ ERROR ] Error: could not create ovirtsdk API object Please check log file /var/log/ovirt-engine/engine-setup_2013_04_28_15_18_21.log for more information =LOG========================================== FragmentPath=/usr/lib/systemd/system/firewalld.service UnitFileState=enabled InactiveExitTimestamp=Sun 2013-04-28 15:16:26 CST InactiveExitTimestampMonotonic=2057927058 ActiveEnterTimestamp=Sun 2013-04-28 15:16:26 CST ActiveEnterTimestampMonotonic=2058029155 ActiveExitTimestamp=Sun 2013-04-28 15:16:26 CST ActiveExitTimestampMonotonic=2057262228 InactiveEnterTimestamp=Sun 2013-04-28 15:16:26 CST InactiveEnterTimestampMonotonic=2057889979 "/var/log/ovirt-engine/engine-setup_2013_04_28_15_18_21.log" 2023L, 122617C 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: db-remote-install: local 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: db-host: localhost 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: db-local-pass: ******** 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: nfs-mp: /var/lib/exports/iso_2013_04_28_15_18_22 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: iso-domain-name: ISO_DOMAIN 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: config-nfs: yes 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: firewall-manager: Firewalld 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: config-allinone: yes 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: storage-path: /var/lib/images_2013_04_28_15_18_22 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: superuser-pass: ******** 2013-04-28 15:19:34::ERROR::engine-setup::2504::root:: Traceback (most recent call last): File "/usr/bin/engine-setup", line 2498, in main(confFile) File "/usr/bin/engine-setup", line 2265, in main runSequences() File "/usr/bin/engine-setup", line 2184, in runSequences controller.runAllSequences() File "/usr/share/ovirt-engine/scripts/setup_controller.py", line 54, in runAllSequences sequence.run() File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 154, in run step.run() File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, in run function() File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line 252, in initAPI raise Exception(ERROR_CREATE_API_OBJECT) Exception: Error: could not create ovirtsdk API object ============================================ [root at localhost ~]# rpm -qa | grep ovirt ovirt-engine-sdk-3.3.0.1-1.20130427.gitfc5985e.fc18.noarch ovirt-engine-backend-3.3.0-0.2.master.20130427145036.fc18.noarch ovirt-engine-setup-plugin-allinone-3.3.0-0.2.master.20130427145036.fc18.noarch ovirt-host-deploy-1.0.1-1.fc18.noarch ovirt-engine-setup-3.3.0-0.2.master.20130427145036.fc18.noarch ovirt-engine-cli-3.2.0.11-1.fc18.noarch ovirt-iso-uploader-3.3.0-0.0.master.20130318.gitec3e5e7.fc18.noarch ovirt-engine-restapi-3.3.0-0.2.master.20130427145036.fc18.noarch ovirt-engine-webadmin-portal-3.3.0-0.2.master.20130427145036.fc18.noarch ovirt-host-deploy-offline-1.0.1-1.fc18.noarch ovirt-image-uploader-3.3.0-0.0.master.20130423.git8dde3cc.fc18.noarch ovirt-engine-dbscripts-3.3.0-0.2.master.20130427145036.fc18.noarch ovirt-engine-userportal-3.3.0-0.2.master.20130427145036.fc18.noarch ovirt-release-fedora-5-3.1.noarch ovirt-host-deploy-java-1.0.1-1.fc18.noarch ovirt-engine-tools-3.3.0-0.2.master.20130427145036.fc18.noarch ovirt-log-collector-3.3.0-0.0.master.20130421.git1c4542d.fc18.noarch ovirt-engine-3.3.0-0.2.master.20130427145036.fc18.noarch [root at localhost ~]# rpm -qa | grep vdsm vdsm-python-4.10.3-10.fc18.x86_64 vdsm-xmlrpc-4.10.3-10.fc18.noarch vdsm-4.10.3-10.fc18.x86_64 vdsm-cli-4.10.3-10.fc18.noarch vdsm-bootstrap-4.10.3-10.fc18.noarch [root at localhost ~]# cat /etc/hosts 10.0.10.181 engine.startn.com [root at localhost ~]# ifconfig eth0: flags=4163 mtu 1500 inet 192.168.11.4 netmask 255.255.255.0 broadcast 192.168.11.255 inet6 fe80::20c:29ff:feed:4f64 prefixlen 64 scopeid 0x20 ether 00:0c:29:ed:4f:64 txqueuelen 1000 (Ethernet) RX packets 22780 bytes 31526531 (30.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 7612 bytes 547095 (534.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=4163 mtu 1500 inet 10.0.10.181 netmask 255.255.255.0 broadcast 10.0.10.255 inet6 fe80::20c:29ff:feed:4f6e prefixlen 64 scopeid 0x20 ether 00:0c:29:ed:4f:6e txqueuelen 1000 (Ethernet) RX packets 45792 bytes 58908887 (56.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 11143 bytes 2063171 (1.9 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 0 (Local Loopback) RX packets 180949 bytes 62786059 (59.8 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 180949 bytes 62786059 (59.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr0: flags=4099 mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 ether 16:aa:69:7c:1e:3e txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root at localhost ~]# dig -x 10.0.10.181 ; <<>> DiG 9.9.2-rl.028.23-P2-RedHat-9.9.2-10.P2.fc18 <<>> -x 10.0.10.181 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21966 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;181.10.0.10.in-addr.arpa. IN PTR ;; ANSWER SECTION: 181.10.0.10.in-addr.arpa. 1200 IN PTR engine.startn.com. ;; AUTHORITY SECTION: 10.0.10.in-addr.arpa. 1200 IN NS engine.startn.com. ;; ADDITIONAL SECTION: engine.startn.com. 86400 IN A 10.0.10.181 ;; Query time: 0 msec ;; SERVER: 10.0.10.181#53(10.0.10.181) ;; WHEN: Sun Apr 28 15:36:34 2013 ;; MSG SIZE rcvd: 114 [root at localhost ~]# dig engine.startn.com ; <<>> DiG 9.9.2-rl.028.23-P2-RedHat-9.9.2-10.P2.fc18 <<>> engine.startn.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36210 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;engine.startn.com. IN A ;; ANSWER SECTION: engine.startn.com. 86400 IN A 10.0.10.181 ;; AUTHORITY SECTION: startn.com. 86400 IN NS engine.startn.com. ;; Query time: 0 msec ;; SERVER: 10.0.10.181#53(10.0.10.181) ;; WHEN: Sun Apr 28 15:36:40 2013 ;; MSG SIZE rcvd: 76 ============================================= --- ??????????? ?? ------------------------------------------------------------------------------ + ????????????????(????1:1) + ------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfediuck at redhat.com Sun Apr 28 08:34:38 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Sun, 28 Apr 2013 04:34:38 -0400 (EDT) Subject: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated In-Reply-To: References: <855522037.76793.1366522910666.JavaMail.root@redhat.com> <590451846.29858.1366528410731.JavaMail.root@redhat.com> <51739331.1020503@redhat.com> <1965040641.30114.1366529345380.JavaMail.root@redhat.com> <2082103465.271823.1366559881373.JavaMail.root@redhat.com> Message-ID: <1284986620.5752413.1367138078075.JavaMail.root@redhat.com> Hi Dave, Just to make sure I fully understand, I'll repeat your basic arguments; 1. It takes time to query a big number of hosts (hundreds). 2. When backend is booting, a user may start a VM on a host which was hacked during the downtime of the engine. If the above is your concern, it shouldn't be so. The reason is, that no host will become operational before you get a response from the attestation server and allow it to become operational. So a user cannot start a new VM on a non-operational host. What this means is that your thread may need to update the user by sending a periodic event that a large scale attestation operation is in progress. Other than that, maybe your thread can work in smaller groups if it gets better results? ie- instead of one query for 300 hosts, maybe you can run 3 serialized queries for 100 hosts each? If this does not help, maybe you can run a short query for something like 10 hosts, which should get an answer relatively fast. The you can issue a query for the other 290 hosts which will take longer. In this way the system may get 10 hosts to work with quite fast, and later on the other 290 hosts will join... So this can actually be configurable to a 2-phase process; a short query and a longer one. The admin can choose the short query size based on his setup, and the longer query can pick up all the other hosts. What do you think? Doron ----- Original Message ----- > From: "Wei D Chen" > To: "Doron Fediuck" > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > Sent: Saturday, April 27, 2013 9:36:44 AM > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated > > Hi, > > Our current consideration is add a new thread in engine's side to attest all > of hosts (aggregated query from attestation sever) one time in case of > engine's rebooting. There is still one potential issue under extreme > condition, saying, hundreds of nodes in a datacenter, attest all of hosts > still may take couple of mins, let's say, one hacked untrusted node before > receiving the latest status may considered as a trusted host, so, the worst > case in a datacenter with hundreds of nodes is, > 1. engine is down for some reasons and boot up again, some trusted nodes may > be hacked and rebooted during this period. > 2. our thread is running to get all of node's status (trust /untrusted), may > take couple of mins in large datacenter. > 2. user create VMs on these hacked nodes and believe these VMs are trusted > VMs launched on trusted nodes. > 3. our thread get the correct status of these untrusted nodes, set these > nodes as non-operational. > 4. all of these "trusted" VMs running on these untrusted nodes are expected > to migrate to other trusted node. > > So, the question is in a trusted cluster with hundreds of nodes some VMs > expected to create on trusted nodes may actually create on untrusted nodes > instead, and this time may last for couple of mins. (worst case in my view > is 10 mins with 1000 nodes). > Does this acceptable from your point of view? Or any other suggestion? > > > Best Regards, > Dave Chen > > > > -----Original Message----- > > From: Doron Fediuck [mailto:dfediuck at redhat.com] > > Sent: Sunday, April 21, 2013 11:58 PM > > To: Chen, Wei D > > Cc: Ofri Masad; Oved Ourfalli; engine-devel at ovirt.org > > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools > > integration with oVirt has been updated > > > > > > > > ----- Original Message ----- > > > From: "Wei D Chen" > > > To: "Ofri Masad" > > > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > > > Sent: Sunday, April 21, 2013 4:00:55 PM > > > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools > > > integration with oVirt has been updated > > > > > > Ofri, > > > > > > Absolutely right, aggregated query has a significantly time improve > > > compared to separated queries. I agree a aggregated query on engine's > > > starting. Is it possible to invoke attestation service in engine's > > > initialization code block instead of "quartz job"? Is there any class > > > similar with > > " > > > InitVdsOnUpCommand " for engine's initialization? > > > > > > Best Regards, > > > Dave Chen > > > > > org.ovirt.engine.core.bll.Backend.Initialize() > > > > Note you cannot block this method while waiting for results. > > Instead I suggest you fire a one-time background request from this method. > > > > > > > -----Original Message----- > > > From: Ofri Masad [mailto:omasad at redhat.com] > > > Sent: Sunday, April 21, 2013 3:29 PM > > > To: Chen, Wei D > > > Cc: Oved Ourfalli; engine-devel at ovirt.org; Itamar Heim > > > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools > > > integration with oVirt has been updated > > > > > > Dave, > > > > > > If I'm not mistaking, there is a big difference between separated > > > queries to the attestation server and aggregated one? > > > Is it true? > > > > > > Thanks, > > > Ofri > > > > > > ----- Original Message ----- > > > > From: "Itamar Heim" > > > > To: "Ofri Masad" > > > > Cc: "Oved Ourfalli" , "Wei D Chen" > > > > , engine-devel at ovirt.org > > > > Sent: Sunday, April 21, 2013 10:20:17 AM > > > > Subject: Re: [Engine-devel] Design wiki page for trusted compute > > > > pools integration with oVirt has been updated > > > > > > > > On 04/21/2013 10:13 AM, Ofri Masad wrote: > > > > > Hi, > > > > > One more thing we need to think about for the second approach - > > > > > aggregated query. On engine start we need to determine the trust > > > > > state of all the hosts. sending a separate query for each host > > > > > will overload the attestation host and the network. an initial > > > > > aggregated query needs to be send when the engine starts. > > > > > Same thing can happen after management network fail and so on. > > > > > Maybe we can run a quartz job every x minutes, checking if a large > > > > > part of the hosts in the cluster (like 30%) are untrusted - in > > > > > that case run the aggregated query. > > > > > > > > are we sure this optimization is needed? > > > > how heavy/latent is the call to the attestation service? > > > > > > > _______________________________________________ > > > 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 Apr 28 09:35:05 2013 From: iheim at redhat.com (Itamar Heim) Date: Sun, 28 Apr 2013 12:35:05 +0300 Subject: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated In-Reply-To: <1284986620.5752413.1367138078075.JavaMail.root@redhat.com> References: <855522037.76793.1366522910666.JavaMail.root@redhat.com> <590451846.29858.1366528410731.JavaMail.root@redhat.com> <51739331.1020503@redhat.com> <1965040641.30114.1366529345380.JavaMail.root@redhat.com> <2082103465.271823.1366559881373.JavaMail.root@redhat.com> <1284986620.5752413.1367138078075.JavaMail.root@redhat.com> Message-ID: <517CED49.6070507@redhat.com> On 04/28/2013 11:34 AM, Doron Fediuck wrote: > Hi Dave, > > Just to make sure I fully understand, I'll repeat your basic arguments; > > 1. It takes time to query a big number of hosts (hundreds). > > 2. When backend is booting, a user may start a VM on a host which was > hacked during the downtime of the engine. > > If the above is your concern, it shouldn't be so. > The reason is, that no host will become operational before you get a response > from the attestation server and allow it to become operational. So a user > cannot start a new VM on a non-operational host. i'd do the queries in groups of "cluster", so cluste-by-cluster they get unblocked. cluster without attestation service shouldn't block on this of course. > > What this means is that your thread may need to update the user by sending > a periodic event that a large scale attestation operation is in progress. > Other than that, maybe your thread can work in smaller groups if it gets > better results? ie- instead of one query for 300 hosts, maybe you can run > 3 serialized queries for 100 hosts each? > If this does not help, maybe you can run a short query for something like > 10 hosts, which should get an answer relatively fast. The you can issue a > query for the other 290 hosts which will take longer. In this way the system > may get 10 hosts to work with quite fast, and later on the other 290 hosts > will join... So this can actually be configurable to a 2-phase process; > a short query and a longer one. The admin can choose the short query size > based on his setup, and the longer query can pick up all the other hosts. > What do you think? > > Doron > > ----- Original Message ----- >> From: "Wei D Chen" >> To: "Doron Fediuck" >> Cc: "Oved Ourfalli" , engine-devel at ovirt.org >> Sent: Saturday, April 27, 2013 9:36:44 AM >> Subject: Re: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated >> >> Hi, >> >> Our current consideration is add a new thread in engine's side to attest all >> of hosts (aggregated query from attestation sever) one time in case of >> engine's rebooting. There is still one potential issue under extreme >> condition, saying, hundreds of nodes in a datacenter, attest all of hosts >> still may take couple of mins, let's say, one hacked untrusted node before >> receiving the latest status may considered as a trusted host, so, the worst >> case in a datacenter with hundreds of nodes is, >> 1. engine is down for some reasons and boot up again, some trusted nodes may >> be hacked and rebooted during this period. >> 2. our thread is running to get all of node's status (trust /untrusted), may >> take couple of mins in large datacenter. >> 2. user create VMs on these hacked nodes and believe these VMs are trusted >> VMs launched on trusted nodes. >> 3. our thread get the correct status of these untrusted nodes, set these >> nodes as non-operational. >> 4. all of these "trusted" VMs running on these untrusted nodes are expected >> to migrate to other trusted node. >> >> So, the question is in a trusted cluster with hundreds of nodes some VMs >> expected to create on trusted nodes may actually create on untrusted nodes >> instead, and this time may last for couple of mins. (worst case in my view >> is 10 mins with 1000 nodes). >> Does this acceptable from your point of view? Or any other suggestion? >> >> >> Best Regards, >> Dave Chen >> >> >>> -----Original Message----- >>> From: Doron Fediuck [mailto:dfediuck at redhat.com] >>> Sent: Sunday, April 21, 2013 11:58 PM >>> To: Chen, Wei D >>> Cc: Ofri Masad; Oved Ourfalli; engine-devel at ovirt.org >>> Subject: Re: [Engine-devel] Design wiki page for trusted compute pools >>> integration with oVirt has been updated >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Wei D Chen" >>>> To: "Ofri Masad" >>>> Cc: "Oved Ourfalli" , engine-devel at ovirt.org >>>> Sent: Sunday, April 21, 2013 4:00:55 PM >>>> Subject: Re: [Engine-devel] Design wiki page for trusted compute pools >>>> integration with oVirt has been updated >>>> >>>> Ofri, >>>> >>>> Absolutely right, aggregated query has a significantly time improve >>>> compared to separated queries. I agree a aggregated query on engine's >>>> starting. Is it possible to invoke attestation service in engine's >>>> initialization code block instead of "quartz job"? Is there any class >>>> similar with >>> " >>>> InitVdsOnUpCommand " for engine's initialization? >>>> >>>> Best Regards, >>>> Dave Chen >>>> >>> org.ovirt.engine.core.bll.Backend.Initialize() >>> >>> Note you cannot block this method while waiting for results. >>> Instead I suggest you fire a one-time background request from this method. >>> >>> >>>> -----Original Message----- >>>> From: Ofri Masad [mailto:omasad at redhat.com] >>>> Sent: Sunday, April 21, 2013 3:29 PM >>>> To: Chen, Wei D >>>> Cc: Oved Ourfalli; engine-devel at ovirt.org; Itamar Heim >>>> Subject: Re: [Engine-devel] Design wiki page for trusted compute pools >>>> integration with oVirt has been updated >>>> >>>> Dave, >>>> >>>> If I'm not mistaking, there is a big difference between separated >>>> queries to the attestation server and aggregated one? >>>> Is it true? >>>> >>>> Thanks, >>>> Ofri >>>> >>>> ----- Original Message ----- >>>>> From: "Itamar Heim" >>>>> To: "Ofri Masad" >>>>> Cc: "Oved Ourfalli" , "Wei D Chen" >>>>> , engine-devel at ovirt.org >>>>> Sent: Sunday, April 21, 2013 10:20:17 AM >>>>> Subject: Re: [Engine-devel] Design wiki page for trusted compute >>>>> pools integration with oVirt has been updated >>>>> >>>>> On 04/21/2013 10:13 AM, Ofri Masad wrote: >>>>>> Hi, >>>>>> One more thing we need to think about for the second approach - >>>>>> aggregated query. On engine start we need to determine the trust >>>>>> state of all the hosts. sending a separate query for each host >>>>>> will overload the attestation host and the network. an initial >>>>>> aggregated query needs to be send when the engine starts. >>>>>> Same thing can happen after management network fail and so on. >>>>>> Maybe we can run a quartz job every x minutes, checking if a large >>>>>> part of the hosts in the cluster (like 30%) are untrusted - in >>>>>> that case run the aggregated query. >>>>> >>>>> are we sure this optimization is needed? >>>>> how heavy/latent is the call to the attestation service? >>>>> >>>> _______________________________________________ >>>> 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 vered at redhat.com Sun Apr 28 09:40:29 2013 From: vered at redhat.com (Vered Volansky) Date: Sun, 28 Apr 2013 05:40:29 -0400 (EDT) Subject: [Engine-devel] Fwd: the procedure of storage-related In-Reply-To: <464023629.5758973.1367141971909.JavaMail.root@redhat.com> References: <3a28758f.8586.13e4a022bf4.Coremail.bigclouds@163.com> <464023629.5758973.1367141971909.JavaMail.root@redhat.com> Message-ID: <1151689086.5759061.1367142029663.JavaMail.root@redhat.com> ----- Forwarded Message ----- > From: "Vered Volansky" > To: "bigclouds" > Sent: Sunday, April 28, 2013 12:39:31 PM > Subject: Re: [Engine-devel] the procedure of storage-related > > Hi, > > Find my answers below. > > Best Regards, > Vered > > ----- Original Message ----- > > From: "bigclouds" > > To: "engine-devel" > > Sent: Saturday, April 27, 2013 8:40:56 AM > > Subject: [Engine-devel] the procedure of storage-related > > > > hi,all > > 1.i am now not very familar with the right procedure of storage, > > please give me a simply introduction of their concept and relation. > > help > > me out > > > > StoragePool,StorageDomain > > image,volume > > You should find the following link helpful: > http://www.ovirt.org/Vdsm_Storage_Terminology > > As per your other questions, you might find the following guide helpul: > http://www.ovirt.org/Quick_Start_Guide#Configure_Storage > > Of not, please rephrase them as they're not clear enough and I'd rather not > guess. > > > > > > > > 2.please help me confirm. > > i find only one place call mount command, which is > > poolConnectStorageServer. > > if poolConnectStorageServer is before create and active > > StoragePool,StorageDomain? > > > > 3.if attach is just modify metadata, not anything else? > > > > 4.sp.py, deactivateSD > > if i deactivate ISO storage,it finally umount masterDir, why ? > > if masterDir is not mastersd? > > thanks > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From bigclouds at 163.com Sun Apr 28 10:25:55 2013 From: bigclouds at 163.com (bigclouds) Date: Sun, 28 Apr 2013 18:25:55 +0800 (CST) Subject: [Engine-devel] Fwd: the procedure of storage-related In-Reply-To: <1151689086.5759061.1367142029663.JavaMail.root@redhat.com> References: <3a28758f.8586.13e4a022bf4.Coremail.bigclouds@163.com> <464023629.5758973.1367141971909.JavaMail.root@redhat.com> <1151689086.5759061.1367142029663.JavaMail.root@redhat.com> Message-ID: <26613d7f.ac6c.13e502d71b0.Coremail.bigclouds@163.com> hi, maybe i do not make you understand me fully. i am reading vdsm code, but it is hard for me to understand StorageDomain,StoragePool. before stoargeD(P) can work, engine must prepare many things. i want to know the call flow (process) which must be done to make storageS(P) work. 1.for example, what funcitons you should call if make a stoargeDomain work. poolConnectStorageServer->poolCreate->poolConnect->domainCreate->domainActivate. thanks At 2013-04-28 17:40:29,"Vered Volansky" wrote: > > >----- Forwarded Message ----- >> From: "Vered Volansky" >> To: "bigclouds" >> Sent: Sunday, April 28, 2013 12:39:31 PM >> Subject: Re: [Engine-devel] the procedure of storage-related >> >> Hi, >> >> Find my answers below. >> >> Best Regards, >> Vered >> >> ----- Original Message ----- >> > From: "bigclouds" >> > To: "engine-devel" >> > Sent: Saturday, April 27, 2013 8:40:56 AM >> > Subject: [Engine-devel] the procedure of storage-related >> > >> > hi,all >> > 1.i am now not very familar with the right procedure of storage, >> > please give me a simply introduction of their concept and relation. >> > help >> > me out >> > >> > StoragePool,StorageDomain >> > image,volume >> >> You should find the following link helpful: >> http://www.ovirt.org/Vdsm_Storage_Terminology >> >> As per your other questions, you might find the following guide helpul: >> http://www.ovirt.org/Quick_Start_Guide#Configure_Storage >> >> Of not, please rephrase them as they're not clear enough and I'd rather not >> guess. >> >> >> > >> > >> > 2.please help me confirm. >> > i find only one place call mount command, which is >> > poolConnectStorageServer. >> > if poolConnectStorageServer is before create and active >> > StoragePool,StorageDomain? >> > >> > 3.if attach is just modify metadata, not anything else? >> > >> > 4.sp.py, deactivateSD >> > if i deactivate ISO storage,it finally umount masterDir, why ? >> > if masterDir is not mastersd? >> > thanks >> > >> > >> > >> > _______________________________________________ >> > 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: From vered at redhat.com Sun Apr 28 10:53:32 2013 From: vered at redhat.com (Vered Volansky) Date: Sun, 28 Apr 2013 06:53:32 -0400 (EDT) Subject: [Engine-devel] Fwd: the procedure of storage-related In-Reply-To: <26613d7f.ac6c.13e502d71b0.Coremail.bigclouds@163.com> References: <3a28758f.8586.13e4a022bf4.Coremail.bigclouds@163.com> <464023629.5758973.1367141971909.JavaMail.root@redhat.com> <1151689086.5759061.1367142029663.JavaMail.root@redhat.com> <26613d7f.ac6c.13e502d71b0.Coremail.bigclouds@163.com> Message-ID: <2017147260.5768360.1367146412627.JavaMail.root@redhat.com> I'm not that familiarized with the code myself and can't tell you without looking into it and debugging it. What I would do is - for any command I'd like the internal flow of - start at the top (All vds commands are listed when you type vdsClient, without the need to actually run something). You can then search the specific command you're interested in in the code, and see the flow there. You can obviously run a specific command if you have the correct setup and follow through with the vdsm.log to see the exact flow. You can, of course, add your own debug messages to make things clearer for you, as the vdsm log is logged to very frequently. ----- Original Message ----- > From: "bigclouds" > To: "Vered Volansky" > Cc: engine-devel at ovirt.org, "users" , vdsm-devel at lists.fedorahosted.org > Sent: Sunday, April 28, 2013 1:25:55 PM > Subject: Re: [Engine-devel] Fwd: the procedure of storage-related > > hi, > maybe i do not make you understand me fully. i am reading vdsm code, but it > is hard for me to understand StorageDomain,StoragePool. before stoargeD(P) > can work, engine must prepare many things. > i want to know the call flow (process) which must be done to make > storageS(P) work. > > 1.for example, what funcitons you should call if make a stoargeDomain > work. > poolConnectStorageServer->poolCreate->poolConnect->domainCreate->domainActivate. > > thanks > > > > > At 2013-04-28 17:40:29,"Vered Volansky" wrote: > > > > > >----- Forwarded Message ----- > >> From: "Vered Volansky" > >> To: "bigclouds" > >> Sent: Sunday, April 28, 2013 12:39:31 PM > >> Subject: Re: [Engine-devel] the procedure of storage-related > >> > >> Hi, > >> > >> Find my answers below. > >> > >> Best Regards, > >> Vered > >> > >> ----- Original Message ----- > >> > From: "bigclouds" > >> > To: "engine-devel" > >> > Sent: Saturday, April 27, 2013 8:40:56 AM > >> > Subject: [Engine-devel] the procedure of storage-related > >> > > >> > hi,all > >> > 1.i am now not very familar with the right procedure of storage, > >> > please give me a simply introduction of their concept and relation. > >> > help > >> > me out > >> > > >> > StoragePool,StorageDomain > >> > image,volume > >> > >> You should find the following link helpful: > >> http://www.ovirt.org/Vdsm_Storage_Terminology > >> > >> As per your other questions, you might find the following guide helpul: > >> http://www.ovirt.org/Quick_Start_Guide#Configure_Storage > >> > >> Of not, please rephrase them as they're not clear enough and I'd rather > >> not > >> guess. > >> > >> > >> > > >> > > >> > 2.please help me confirm. > >> > i find only one place call mount command, which is > >> > poolConnectStorageServer. > >> > if poolConnectStorageServer is before create and active > >> > StoragePool,StorageDomain? > >> > > >> > 3.if attach is just modify metadata, not anything else? > >> > > >> > 4.sp.py, deactivateSD > >> > if i deactivate ISO storage,it finally umount masterDir, why ? > >> > if masterDir is not mastersd? > >> > thanks > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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 gang.wei at intel.com Sun Apr 28 11:06:24 2013 From: gang.wei at intel.com (Wei, Gang) Date: Sun, 28 Apr 2013 11:06:24 +0000 Subject: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated In-Reply-To: <517CED49.6070507@redhat.com> References: <855522037.76793.1366522910666.JavaMail.root@redhat.com> <590451846.29858.1366528410731.JavaMail.root@redhat.com> <51739331.1020503@redhat.com> <1965040641.30114.1366529345380.JavaMail.root@redhat.com> <2082103465.271823.1366559881373.JavaMail.root@redhat.com> <1284986620.5752413.1367138078075.JavaMail.root@redhat.com> <517CED49.6070507@redhat.com> Message-ID: I like the ideas of 2-phase aggregated attestation & cluster-by-cluster order. But I want to understand the process more clearly. Without TCP, how does engine handle the states of existing hosts during engine booting? Will engine put all existing hosts in non-operational state and then perform some check via VDSM then turn it into operational state? Put host in non-operational state will cause VM migration, right? Or there is a global state in engine to indicate whether user is allowed to create VM? Thanks Jimmy Itamar Heim wrote on?2013-04-28: > On 04/28/2013 11:34 AM, Doron Fediuck wrote: >> Hi Dave, >> >> Just to make sure I fully understand, I'll repeat your basic arguments; >> >> 1. It takes time to query a big number of hosts (hundreds). >> >> 2. When backend is booting, a user may start a VM on a host which was >> hacked during the downtime of the engine. >> >> If the above is your concern, it shouldn't be so. >> The reason is, that no host will become operational before you get a response >> from the attestation server and allow it to become operational. So a user >> cannot start a new VM on a non-operational host. > > i'd do the queries in groups of "cluster", so cluste-by-cluster they get > unblocked. cluster without attestation service shouldn't block on this > of course. > >> >> What this means is that your thread may need to update the user by sending >> a periodic event that a large scale attestation operation is in progress. >> Other than that, maybe your thread can work in smaller groups if it gets >> better results? ie- instead of one query for 300 hosts, maybe you can run >> 3 serialized queries for 100 hosts each? >> If this does not help, maybe you can run a short query for something like >> 10 hosts, which should get an answer relatively fast. The you can issue a >> query for the other 290 hosts which will take longer. In this way the system >> may get 10 hosts to work with quite fast, and later on the other 290 hosts >> will join... So this can actually be configurable to a 2-phase process; >> a short query and a longer one. The admin can choose the short query size >> based on his setup, and the longer query can pick up all the other hosts. >> What do you think? >> >> Doron >> >> ----- Original Message ----- >>> From: "Wei D Chen" To: "Doron Fediuck" >>> Cc: "Oved Ourfalli" , >>> engine-devel at ovirt.org Sent: Saturday, April 27, 2013 9:36:44 AM >>> Subject: Re: [Engine-devel] Design wiki page for trusted compute pools >>> integration with oVirt has been updated >>> >>> Hi, >>> >>> Our current consideration is add a new thread in engine's side to >>> attest all of hosts (aggregated query from attestation sever) one time >>> in case of engine's rebooting. There is still one potential issue >>> under extreme condition, saying, hundreds of nodes in a datacenter, >>> attest all of hosts still may take couple of mins, let's say, one >>> hacked untrusted node before receiving the latest status may >>> considered as a trusted host, so, the worst case in a datacenter with >>> hundreds of nodes is, 1. engine is down for some reasons and boot up >>> again, some trusted nodes may be hacked and rebooted during this >>> period. 2. our thread is running to get all of node's status (trust >>> /untrusted), may take couple of mins in large datacenter. 2. user >>> create VMs on these hacked nodes and believe these VMs are trusted VMs >>> launched on trusted nodes. 3. our thread get the correct status of >>> these untrusted nodes, set these nodes as non-operational. 4. all of >>> these "trusted" VMs running on these untrusted nodes are expected to >>> migrate to other trusted node. >>> >>> So, the question is in a trusted cluster with hundreds of nodes some >>> VMs expected to create on trusted nodes may actually create on >>> untrusted nodes instead, and this time may last for couple of mins. >>> (worst case in my view is 10 mins with 1000 nodes). Does this >>> acceptable from your point of view? Or any other suggestion? >>> >>> >>> Best Regards, >>> Dave Chen >>> >>> >>> Doron Fediuck wrote on 2013-04-21: >>>> integration with oVirt has been updated >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Wei D Chen" >>>>> To: "Ofri Masad" >>>>> Cc: "Oved Ourfalli" , engine-devel at ovirt.org >>>>> Sent: Sunday, April 21, 2013 4:00:55 PM >>>>> Subject: Re: [Engine-devel] Design wiki page for trusted compute pools >>>>> integration with oVirt has been updated >>>>> >>>>> Ofri, >>>>> >>>>> Absolutely right, aggregated query has a significantly time improve >>>>> compared to separated queries. I agree a aggregated query on >>>>> engine's starting. Is it possible to invoke attestation service in >>>>> engine's initialization code block instead of "quartz job"? Is there >>>>> any class similar with " InitVdsOnUpCommand " for engine's >>>>> initialization? >>>>> >>>>> Best Regards, >>>>> Dave Chen >>>>> >>>> org.ovirt.engine.core.bll.Backend.Initialize() >>>> >>>> Note you cannot block this method while waiting for results. Instead >>>> I suggest you fire a one-time background request from this method. >>>> >>>> >>>> Ofri Masad wrote on 2013-04-21: >>>>> integration with oVirt has been updated >>>>> >>>>> Dave, >>>>> >>>>> If I'm not mistaking, there is a big difference between separated >>>>> queries to the attestation server and aggregated one? >>>>> Is it true? >>>>> >>>>> Thanks, >>>>> Ofri >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Itamar Heim" >>>>>> To: "Ofri Masad" >>>>>> Cc: "Oved Ourfalli" , "Wei D Chen" >>>>>> , engine-devel at ovirt.org >>>>>> Sent: Sunday, April 21, 2013 10:20:17 AM >>>>>> Subject: Re: [Engine-devel] Design wiki page for trusted compute >>>>>> pools integration with oVirt has been updated >>>>>> >>>>>> On 04/21/2013 10:13 AM, Ofri Masad wrote: >>>>>>> Hi, >>>>>>> One more thing we need to think about for the second approach - >>>>>>> aggregated query. On engine start we need to determine the trust >>>>>>> state of all the hosts. sending a separate query for each host >>>>>>> will overload the attestation host and the network. an initial >>>>>>> aggregated query needs to be send when the engine starts. >>>>>>> Same thing can happen after management network fail and so on. >>>>>>> Maybe we can run a quartz job every x minutes, checking if a large >>>>>>> part of the hosts in the cluster (like 30%) are untrusted - in >>>>>>> that case run the aggregated query. >>>>>> >>>>>> are we sure this optimization is needed? >>>>>> how heavy/latent is the call to the attestation service? >>>>>> >>>>> _______________________________________________ >>>>> 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 Jimmy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 8586 bytes Desc: not available URL: From dfediuck at redhat.com Sun Apr 28 13:24:06 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Sun, 28 Apr 2013 09:24:06 -0400 (EDT) Subject: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated In-Reply-To: References: <1965040641.30114.1366529345380.JavaMail.root@redhat.com> <2082103465.271823.1366559881373.JavaMail.root@redhat.com> <1284986620.5752413.1367138078075.JavaMail.root@redhat.com> <517CED49.6070507@redhat.com> Message-ID: <1723805203.5812041.1367155446074.JavaMail.root@redhat.com> Hi Jimmy, When the engine starts, it will start 'learning' the current state of known hosts. So if we want to secure all hosts in 'up' state, you will need to change it to 'unassigned' only if cluster.trusted == true in- org.ovirt.engine.core.vdsbroker.ResourceManager.AddVds(VDS, boolean) This means the host will be picked up by: org.ovirt.engine.core.vdsbroker.VirtMonitoringStrategy.isMonitoringNeeded(VDS) and the attestation query should get the results and update the trust level and accordingly the vds status. Note that we assume that trust level takes precedence on other functionalities, as this flow will cause storage connections to reinitialize as well. Basically it means that booting will take longer, but this is the price of security. ----- Original Message ----- > From: "Gang Wei" > To: "Itamar Heim" , "Doron Fediuck" > Cc: "Oved Ourfalli" , engine-devel at ovirt.org > Sent: Sunday, April 28, 2013 2:06:24 PM > Subject: Re: [Engine-devel] Design wiki page for trusted compute pools integration with oVirt has been updated > > I like the ideas of 2-phase aggregated attestation & cluster-by-cluster > order. > > But I want to understand the process more clearly. > > Without TCP, how does engine handle the states of existing hosts during > engine booting? Will engine put all existing hosts in non-operational state > and then perform some check via VDSM then turn it into operational state? > Put host in non-operational state will cause VM migration, right? > > Or there is a global state in engine to indicate whether user is allowed to > create VM? > > Thanks > Jimmy > > Itamar Heim wrote on?2013-04-28: > > On 04/28/2013 11:34 AM, Doron Fediuck wrote: > >> Hi Dave, > >> > >> Just to make sure I fully understand, I'll repeat your basic arguments; > >> > >> 1. It takes time to query a big number of hosts (hundreds). > >> > >> 2. When backend is booting, a user may start a VM on a host which was > >> hacked during the downtime of the engine. > >> > >> If the above is your concern, it shouldn't be so. > >> The reason is, that no host will become operational before you get a > response > >> from the attestation server and allow it to become operational. So a user > >> cannot start a new VM on a non-operational host. > > > > i'd do the queries in groups of "cluster", so cluste-by-cluster they get > > unblocked. cluster without attestation service shouldn't block on this > > of course. > > > >> > >> What this means is that your thread may need to update the user by > sending > >> a periodic event that a large scale attestation operation is in progress. > >> Other than that, maybe your thread can work in smaller groups if it gets > >> better results? ie- instead of one query for 300 hosts, maybe you can run > >> 3 serialized queries for 100 hosts each? > >> If this does not help, maybe you can run a short query for something like > >> 10 hosts, which should get an answer relatively fast. The you can issue a > >> query for the other 290 hosts which will take longer. In this way the > system > >> may get 10 hosts to work with quite fast, and later on the other 290 > hosts > >> will join... So this can actually be configurable to a 2-phase process; > >> a short query and a longer one. The admin can choose the short query size > >> based on his setup, and the longer query can pick up all the other hosts. > >> What do you think? > >> > >> Doron > >> > >> ----- Original Message ----- > >>> From: "Wei D Chen" To: "Doron Fediuck" > >>> Cc: "Oved Ourfalli" , > >>> engine-devel at ovirt.org Sent: Saturday, April 27, 2013 9:36:44 AM > >>> Subject: Re: [Engine-devel] Design wiki page for trusted compute pools > >>> integration with oVirt has been updated > >>> > >>> Hi, > >>> > >>> Our current consideration is add a new thread in engine's side to > >>> attest all of hosts (aggregated query from attestation sever) one time > >>> in case of engine's rebooting. There is still one potential issue > >>> under extreme condition, saying, hundreds of nodes in a datacenter, > >>> attest all of hosts still may take couple of mins, let's say, one > >>> hacked untrusted node before receiving the latest status may > >>> considered as a trusted host, so, the worst case in a datacenter with > >>> hundreds of nodes is, 1. engine is down for some reasons and boot up > >>> again, some trusted nodes may be hacked and rebooted during this > >>> period. 2. our thread is running to get all of node's status (trust > >>> /untrusted), may take couple of mins in large datacenter. 2. user > >>> create VMs on these hacked nodes and believe these VMs are trusted VMs > >>> launched on trusted nodes. 3. our thread get the correct status of > >>> these untrusted nodes, set these nodes as non-operational. 4. all of > >>> these "trusted" VMs running on these untrusted nodes are expected to > >>> migrate to other trusted node. > >>> > >>> So, the question is in a trusted cluster with hundreds of nodes some > >>> VMs expected to create on trusted nodes may actually create on > >>> untrusted nodes instead, and this time may last for couple of mins. > >>> (worst case in my view is 10 mins with 1000 nodes). Does this > >>> acceptable from your point of view? Or any other suggestion? > >>> > >>> > >>> Best Regards, > >>> Dave Chen > >>> > >>> > >>> Doron Fediuck wrote on 2013-04-21: > >>>> integration with oVirt has been updated > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Wei D Chen" > >>>>> To: "Ofri Masad" > >>>>> Cc: "Oved Ourfalli" , engine-devel at ovirt.org > >>>>> Sent: Sunday, April 21, 2013 4:00:55 PM > >>>>> Subject: Re: [Engine-devel] Design wiki page for trusted compute pools > >>>>> integration with oVirt has been updated > >>>>> > >>>>> Ofri, > >>>>> > >>>>> Absolutely right, aggregated query has a significantly time improve > >>>>> compared to separated queries. I agree a aggregated query on > >>>>> engine's starting. Is it possible to invoke attestation service in > >>>>> engine's initialization code block instead of "quartz job"? Is there > >>>>> any class similar with " InitVdsOnUpCommand " for engine's > >>>>> initialization? > >>>>> > >>>>> Best Regards, > >>>>> Dave Chen > >>>>> > >>>> org.ovirt.engine.core.bll.Backend.Initialize() > >>>> > >>>> Note you cannot block this method while waiting for results. Instead > >>>> I suggest you fire a one-time background request from this method. > >>>> > >>>> > >>>> Ofri Masad wrote on 2013-04-21: > >>>>> integration with oVirt has been updated > >>>>> > >>>>> Dave, > >>>>> > >>>>> If I'm not mistaking, there is a big difference between separated > >>>>> queries to the attestation server and aggregated one? > >>>>> Is it true? > >>>>> > >>>>> Thanks, > >>>>> Ofri > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Itamar Heim" > >>>>>> To: "Ofri Masad" > >>>>>> Cc: "Oved Ourfalli" , "Wei D Chen" > >>>>>> , engine-devel at ovirt.org > >>>>>> Sent: Sunday, April 21, 2013 10:20:17 AM > >>>>>> Subject: Re: [Engine-devel] Design wiki page for trusted compute > >>>>>> pools integration with oVirt has been updated > >>>>>> > >>>>>> On 04/21/2013 10:13 AM, Ofri Masad wrote: > >>>>>>> Hi, > >>>>>>> One more thing we need to think about for the second approach - > >>>>>>> aggregated query. On engine start we need to determine the trust > >>>>>>> state of all the hosts. sending a separate query for each host > >>>>>>> will overload the attestation host and the network. an initial > >>>>>>> aggregated query needs to be send when the engine starts. > >>>>>>> Same thing can happen after management network fail and so on. > >>>>>>> Maybe we can run a quartz job every x minutes, checking if a large > >>>>>>> part of the hosts in the cluster (like 30%) are untrusted - in > >>>>>>> that case run the aggregated query. > >>>>>> > >>>>>> are we sure this optimization is needed? > >>>>>> how heavy/latent is the call to the attestation service? > >>>>>> > >>>>> _______________________________________________ > >>>>> 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 > > > > Jimmy > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From iheim at redhat.com Sun Apr 28 13:27:55 2013 From: iheim at redhat.com (Itamar Heim) Date: Sun, 28 Apr 2013 16:27:55 +0300 Subject: [Engine-devel] Error: could not create ovirtsdk API object In-Reply-To: References: Message-ID: <517D23DB.6010304@redhat.com> On 04/28/2013 10:37 AM, ?? wrote: > > HI?All > > I build source and rpm > -Uvh ovirt-engine-setup-plugin-allinone-3.3.0-0.2.master.20130427145036.fc18.noarch.rpm > > But I engine-setup have ERROR. > Error: could not create ovirtsdk API object > > OS:F18 mini install. > > > =================================== > [root at localhost ~]# engine-setup > Welcome to oVirt Engine setup utility > > WARNING: oVirt Engine setup has already been run on this host. > To remove all configuration and reset oVirt Engine please run > engine-cleanup. > Please be advised that executing engine-setup without cleanup is not > supported. > Would you like to proceed? (yes|no): yes > > In order to proceed the installer must stop the ovirt-engine service > Would you like to stop the ovirt-engine service? (yes|no): yes > oVirt Engine uses httpd to proxy requests to the application server. > It looks like the httpd installed locally is being actively used. > The installer can override current configuration . > Alternatively you can use JBoss directly (on ports higher than 1024) > Do you wish to override current httpd configuration and restart the > service? ['yes'| 'no'] [yes] : > HTTP Port [80] : > HTTPS Port [443] : > Setup can configure server default page to launch oVirt Engine. Do you > wish to do so? ['yes'| 'no'] [yes] : > Host fully qualified domain name. Note: this name should be fully > resolvable [localhost] : engine.startn.com > Enter a password for an internal oVirt Engine administrator user > (admin at internal) : > Warning: Weak Password. > Confirm password : > Organization Name for the Certificate [localhost] : > The engine can be configured to present the UI in three different > application modes. virt [Manage virtualization only], gluster [Manage > gluster storage only], and both [Manage virtualization as well as > gluster storage] ['virt'| 'gluster'| 'both'] [both] : > The default storage type you will be using ['NFS'| 'FC'| 'ISCSI'| > 'POSIXFS'] [NFS] : > Enter DB type for installation ['remote'| 'local'] [local] : > Enter a password for a local oVirt Engine DB admin user (engine) : > Warning: Weak Password. > Confirm password : > Local ISO domain path [/var/lib/exports/iso_2013_04_28_15_18_22] : > Firewall ports need to be opened. > The installer can configure firewall automatically overriding the > current configuration. The old configuration will be backed up. > Alternately you can configure the firewall later using an example file > selecting None. > Which firewall manager do you wish to use? ['None'| 'Firewalld'| > 'iptables']: Firewalld > Configure VDSM on this host? ['yes'| 'no'] [yes] : yes > Local storage domain path [/var/lib/images_2013_04_28_15_18_22] : > Confirm root password : > > oVirt Engine will be installed using the following configuration: > ================================================================= > override-httpd-config: yes > http-port: 80 > https-port: 443 > override-httpd-root: yes > host-fqdn: engine.startn.com > auth-pass: ******** > org-name: localhost > application-mode: both > default-dc-type: NFS > db-remote-install: local > db-local-pass: ******** > nfs-mp: /var/lib/exports/iso_2013_04_28_15_18_22 > firewall-manager: Firewalld > config-allinone: yes > storage-path: /var/lib/images_2013_04_28_15_18_22 > superuser-pass: ******** > Proceed with the configuration listed above? (yes|no): yes > > Installing: > AIO: Validating CPU Compatibility... [ DONE ] > AIO: Adding firewall rules... [ DONE ] > Configuring oVirt Engine... [ DONE ] > Configuring JVM... [ DONE ] > Creating CA... [ DONE ] > Updating ovirt-engine service... [ DONE ] > Setting Database Configuration... [ DONE ] > Setting Database Security... [ DONE ] > Upgrading Database Schema... [ DONE ] > Editing oVirt Engine Configuration... [ DONE ] > Editing Postgresql Configuration... [ DONE ] > Configuring the Default ISO Domain... [ DONE ] > Configuring Firewall... [ DONE ] > Starting ovirt-engine Service... [ DONE ] > Configuring HTTPD... [ DONE ] > AIO: Creating storage directory... [ DONE ] > AIO: Adding Local Datacenter and cluster... [ ERROR ] > Error: could not create ovirtsdk API object > Please check log file > /var/log/ovirt-engine/engine-setup_2013_04_28_15_18_21.log for more > information > > =LOG========================================== > FragmentPath=/usr/lib/systemd/system/firewalld.service > UnitFileState=enabled > InactiveExitTimestamp=Sun 2013-04-28 15:16:26 CST > InactiveExitTimestampMonotonic=2057927058 > ActiveEnterTimestamp=Sun 2013-04-28 15:16:26 CST > ActiveEnterTimestampMonotonic=2058029155 > ActiveExitTimestamp=Sun 2013-04-28 15:16:26 CST > ActiveExitTimestampMonotonic=2057262228 > InactiveEnterTimestamp=Sun 2013-04-28 15:16:26 CST > InactiveEnterTimestampMonotonic=2057889979 > "/var/log/ovirt-engine/engine-setup_2013_04_28_15_18_21.log" 2023L, 122617C > 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: > db-remote-install: local > 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: db-host: localhost > 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: db-local-pass: > ******** > 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: nfs-mp: > /var/lib/exports/iso_2013_04_28_15_18_22 > 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: iso-domain-name: > ISO_DOMAIN > 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: config-nfs: yes > 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: firewall-manager: > Firewalld > 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: config-allinone: yes > 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: storage-path: > /var/lib/images_2013_04_28_15_18_22 > 2013-04-28 15:19:34::DEBUG::engine-setup::2069::root:: superuser-pass: > ******** > 2013-04-28 15:19:34::ERROR::engine-setup::2504::root:: Traceback (most > recent call last): > File "/usr/bin/engine-setup", line 2498, in > main(confFile) > File "/usr/bin/engine-setup", line 2265, in main > runSequences() > File "/usr/bin/engine-setup", line 2184, in runSequences > controller.runAllSequences() > File "/usr/share/ovirt-engine/scripts/setup_controller.py", line 54, > in runAllSequences > sequence.run() > File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 154, > in run > step.run() > File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, > in run > function() > File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", > line 252, in initAPI > raise Exception(ERROR_CREATE_API_OBJECT) > Exception: Error: could not create ovirtsdk API object > Bug 947753 - [AIO] 'Error: could not create ovirtsdk API object' during installation? > > ============================================ > [root at localhost ~]# rpm -qa | grep ovirt > ovirt-engine-sdk-3.3.0.1-1.20130427.gitfc5985e.fc18.noarch > ovirt-engine-backend-3.3.0-0.2.master.20130427145036.fc18.noarch > ovirt-engine-setup-plugin-allinone-3.3.0-0.2.master.20130427145036.fc18.noarch > ovirt-host-deploy-1.0.1-1.fc18.noarch > ovirt-engine-setup-3.3.0-0.2.master.20130427145036.fc18.noarch > ovirt-engine-cli-3.2.0.11-1.fc18.noarch > ovirt-iso-uploader-3.3.0-0.0.master.20130318.gitec3e5e7.fc18.noarch > ovirt-engine-restapi-3.3.0-0.2.master.20130427145036.fc18.noarch > ovirt-engine-webadmin-portal-3.3.0-0.2.master.20130427145036.fc18.noarch > ovirt-host-deploy-offline-1.0.1-1.fc18.noarch > ovirt-image-uploader-3.3.0-0.0.master.20130423.git8dde3cc.fc18.noarch > ovirt-engine-dbscripts-3.3.0-0.2.master.20130427145036.fc18.noarch > ovirt-engine-userportal-3.3.0-0.2.master.20130427145036.fc18.noarch > ovirt-release-fedora-5-3.1.noarch > ovirt-host-deploy-java-1.0.1-1.fc18.noarch > ovirt-engine-tools-3.3.0-0.2.master.20130427145036.fc18.noarch > ovirt-log-collector-3.3.0-0.0.master.20130421.git1c4542d.fc18.noarch > ovirt-engine-3.3.0-0.2.master.20130427145036.fc18.noarch > > [root at localhost ~]# rpm -qa | grep vdsm > vdsm-python-4.10.3-10.fc18.x86_64 > vdsm-xmlrpc-4.10.3-10.fc18.noarch > vdsm-4.10.3-10.fc18.x86_64 > vdsm-cli-4.10.3-10.fc18.noarch > vdsm-bootstrap-4.10.3-10.fc18.noarch > > [root at localhost ~]# cat /etc/hosts > 10.0.10.181 engine.startn.com > > [root at localhost ~]# ifconfig > eth0: flags=4163 mtu 1500 > inet 192.168.11.4 netmask 255.255.255.0 broadcast 192.168.11.255 > inet6 fe80::20c:29ff:feed:4f64 prefixlen 64 scopeid 0x20 > ether 00:0c:29:ed:4f:64 txqueuelen 1000 (Ethernet) > RX packets 22780 bytes 31526531 (30.0 MiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 7612 bytes 547095 (534.2 KiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > eth1: flags=4163 mtu 1500 > inet 10.0.10.181 netmask 255.255.255.0 broadcast 10.0.10.255 > inet6 fe80::20c:29ff:feed:4f6e prefixlen 64 scopeid 0x20 > ether 00:0c:29:ed:4f:6e txqueuelen 1000 (Ethernet) > RX packets 45792 bytes 58908887 (56.1 MiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 11143 bytes 2063171 (1.9 MiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > lo: flags=73 mtu 65536 > inet 127.0.0.1 netmask 255.0.0.0 > inet6 ::1 prefixlen 128 scopeid 0x10 > loop txqueuelen 0 (Local Loopback) > RX packets 180949 bytes 62786059 (59.8 MiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 180949 bytes 62786059 (59.8 MiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > virbr0: flags=4099 mtu 1500 > inet 192.168.122.1 netmask 255.255.255.0 broadcast > 192.168.122.255 > ether 16:aa:69:7c:1e:3e txqueuelen 0 (Ethernet) > RX packets 0 bytes 0 (0.0 B) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 0 bytes 0 (0.0 B) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > [root at localhost ~]# dig -x 10.0.10.181 > > ; <<>> DiG 9.9.2-rl.028.23-P2-RedHat-9.9.2-10.P2.fc18 <<>> -x 10.0.10.181 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21966 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;181.10.0.10.in-addr.arpa. IN PTR > > ;; ANSWER SECTION: > 181.10.0.10.in-addr.arpa. 1200 IN PTR engine.startn.com > . > > ;; AUTHORITY SECTION: > 10.0.10.in-addr.arpa. 1200 IN NS engine.startn.com > . > > ;; ADDITIONAL SECTION: > engine.startn.com . 86400 IN A > 10.0.10.181 > > ;; Query time: 0 msec > ;; SERVER: 10.0.10.181#53(10.0.10.181) > ;; WHEN: Sun Apr 28 15:36:34 2013 > ;; MSG SIZE rcvd: 114 > > [root at localhost ~]# dig engine.startn.com > > ; <<>> DiG 9.9.2-rl.028.23-P2-RedHat-9.9.2-10.P2.fc18 <<>> > engine.startn.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36210 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;engine.startn.com . IN A > > ;; ANSWER SECTION: > engine.startn.com . 86400 IN A > 10.0.10.181 > > ;; AUTHORITY SECTION: > startn.com . 86400 IN NS > engine.startn.com . > > ;; Query time: 0 msec > ;; SERVER: 10.0.10.181#53(10.0.10.181) > ;; WHEN: Sun Apr 28 15:36:40 2013 > ;; MSG SIZE rcvd: 76 > ============================================= > > --- > ??????????? > ?? > > ------------------------------------------------------------------------------ > > > + ????????????????(????1:1) + > ------------------------------------------------------------------------------ > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From iheim at redhat.com Sun Apr 28 18:25:28 2013 From: iheim at redhat.com (Itamar Heim) Date: Sun, 28 Apr 2013 21:25:28 +0300 Subject: [Engine-devel] oVirt updates - April 28th, 2013 Message-ID: <517D6998.4070604@redhat.com> I thought a summary of things going on from time to time may interest folks: 1. From the Web * Vagrant support for oVirt/RHEV added http://alturl.com/bkauk https://github.com/pradels/vagrant-ovirt http://www.vagrantup.com/ * How to create and provision an oVirt VM with ansible http://www.youtube.com/watch?v=up8X_clAvZk * ovirt_metrics - ActiveRecord-based gem for reading the oVirt History database http://is.gd/hO94Us * DEMO: oVirt - GlusterFS Native Integration for KVM Virtualization http://www.youtube.com/watch?v=0iIuHCz8L04 * Android x86 running on oVirt http://www.youtube.com/watch?v=5nFZLma_Ofw * using oVirt to build a virtualization platform on an IBM BladeCenter http://www.r11networks.com/2013/04/ovirt-meets-ibm-bladecenter/ http://www.r11networks.com/2013/04/ovirt-installation-guide/ 2. Conferences * Ren? Koch (ovido) presented oVirt in a two conferences in Germany oVirt was covered in two OpenStack summit sessions: * Mike Day, IBM: Connected Communities, Innovative Technologies: OpenStack, oVirt, and KVM http://sched.co/WcehtG * Romil Gupta et al, HP: RHEV-M/oVirt Clusters as compute resources http://sched.co/14hte1T http://www.slideshare.net/romilgupta19/hp-rhevmdriverromil) http://alturl.com/vsn5e 3. Bug/feature/patch of the week? Send your candidates for the next update 4. Upcoming * oVirt Shanghai workshop http://www.ovirt.org/Intel_Workshop_May_2013 Feel free to send comments, items, etc for consideration for the next update. Thanks, Itamar From abaron at redhat.com Mon Apr 29 07:40:14 2013 From: abaron at redhat.com (Ayal Baron) Date: Mon, 29 Apr 2013 03:40:14 -0400 (EDT) Subject: [Engine-devel] [vdsm] Fwd: the procedure of storage-related In-Reply-To: <26613d7f.ac6c.13e502d71b0.Coremail.bigclouds@163.com> References: <3a28758f.8586.13e4a022bf4.Coremail.bigclouds@163.com> <464023629.5758973.1367141971909.JavaMail.root@redhat.com> <1151689086.5759061.1367142029663.JavaMail.root@redhat.com> <26613d7f.ac6c.13e502d71b0.Coremail.bigclouds@163.com> Message-ID: <1488462462.3562136.1367221214803.JavaMail.root@redhat.com> ----- Original Message ----- > hi, > maybe i do not make you understand me fully. i am reading vdsm code, but it > is hard for me to understand StorageDomain,StoragePool. before stoargeD(P) > can work, engine must prepare many things. > i want to know the call flow (process) which must be done to make storageS(P) > work. > 1.for example, what funcitons you should call if make a stoargeDomain work. > poolConnectStorageServer->poolCreate->poolConnect->domainCreate->domainActivate. > thanks The setup flow is: 1. connectStorageServer (this connects the host to storage. i.e. either performs a 'mount' or iscaiadm command) 2. createStorageDomain (only required once) 3. createStoragePool (only required once) Once you have the pool, on all hosts you perform: 1. connectStorageServer 2. connectStoragePool And on one (and only one) of the hosts: 1. spmStart > > > > At?2013-04-28?17:40:29,"Vered?Volansky"??wrote: > > > > > >-----?Forwarded?Message?----- > >>?From:?"Vered?Volansky"? > >>?To:?"bigclouds"? > >>?Sent:?Sunday,?April?28,?2013?12:39:31?PM > >>?Subject:?Re:?[Engine-devel]?the?procedure?of?storage-related > >>? > >>?Hi, > >>? > >>?Find?my?answers?below. > >>? > >>?Best?Regards, > >>?Vered > >>? > >>?-----?Original?Message?----- > >>?>?From:?"bigclouds"? > >>?>?To:?"engine-devel"? > >>?>?Sent:?Saturday,?April?27,?2013?8:40:56?AM > >>?>?Subject:?[Engine-devel]?the?procedure?of?storage-related > >>?>? > >>?>?hi,all > >>?>?1.i?am?now?not?very?familar?with?the?right?procedure?of?storage, > >>?>?????please?give?me?a?simply?introduction?of?their?concept?and?relation. > >>?>?????help > >>?>?????me?out > >>?>?? > >>?>?StoragePool,StorageDomain > >>?>?image,volume > >>? > >>?You?should?find?the?following?link?helpful: > >>?http://www.ovirt.org/Vdsm_Storage_Terminology > >>? > >>?As?per?your?other?questions,?you?might?find?the?following?guide?helpul: > >>?http://www.ovirt.org/Quick_Start_Guide#Configure_Storage > >>? > >>?Of?not,?please?rephrase?them?as?they're?not?clear?enough?and?I'd?rather > >>??not > >>?guess. > >>? > >>? > >>?>?? > >>?>?? > >>?>?2.please?help?me?confirm. > >>?>?i?find?only?one?place?call?mount?command,?which?is > >>?>?poolConnectStorageServer. > >>?>?if?poolConnectStorageServer?is?before?create?and?active > >>?>?StoragePool,StorageDomain? > >>?>?? > >>?>?3.if?attach?is?just?modify?metadata,?not?anything?else? > >>?>?? > >>?>?4.sp.py,?deactivateSD > >>?>???if?i?deactivate?ISO?storage,it?finally?umount?masterDir,?why??? > >>?>???if?masterDir?is?not??mastersd? > >>?>?thanks > >>?>? > >>?>? > >>?>? > >>?>?_______________________________________________ > >>?>?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 > > > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > From andrej.bagon at arnes.si Mon Apr 29 08:28:39 2013 From: andrej.bagon at arnes.si (Andrej Bagon) Date: Mon, 29 Apr 2013 10:28:39 +0200 Subject: [Engine-devel] ovirt user portal and attach a cd Message-ID: <517E2F37.3010807@arnes.si> Hi all, we would like to limit a user as much as possible and give him only actions that he needs with his VM. If we disallow a user the right in system|configure system|manipulate permissions), we give the user, in user portal, only basic mode. But then three is no option to attach a cd in the basic user portal. In basic mode user interface there is no chance in attaching a cd (as this is a basic operation a solution to this would be a button attaching a cd when starting a vm). If we allow the user to manipulate permissions, we get the extended menu back and the user is limited, but we found unacceptable when he is adding permission to the VM, he sees all the users (name, surname, email!) in the ovirt authentication mechanism? A solution to this would be authenticating to the directory service as a user an not as ovirt admin user - meaning that the user will see only users that we allowed he sees in the ldap directory. Thank you. Best Regards, Andrej From ofrenkel at redhat.com Mon Apr 29 09:12:25 2013 From: ofrenkel at redhat.com (Omer Frenkel) Date: Mon, 29 Apr 2013 05:12:25 -0400 (EDT) Subject: [Engine-devel] ovirt user portal and attach a cd In-Reply-To: <517E2F37.3010807@arnes.si> References: <517E2F37.3010807@arnes.si> Message-ID: <1682099686.6160454.1367226745207.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Andrej Bagon" > To: engine-devel at ovirt.org > Sent: Monday, April 29, 2013 11:28:39 AM > Subject: [Engine-devel] ovirt user portal and attach a cd > > Hi all, > > we would like to limit a user as much as possible and give him only > actions that he needs with his VM. If we disallow a user the right in > system|configure system|manipulate permissions), we give the user, in > user portal, only basic mode. But then three is no option to attach a cd > in the basic user portal. In basic mode user interface there is no > chance in attaching a cd (as this is a basic operation a solution to > this would be a button attaching a cd when starting a vm). > > If we allow the user to manipulate permissions, we get the extended menu > back and the user is limited, but we found unacceptable when he is > adding permission to the VM, he sees all the users (name, surname, > email!) in the ovirt authentication mechanism? A solution to this would > be authenticating to the directory service as a user an not as ovirt > admin user - meaning that the user will see only users that we allowed > he sees in the ldap directory. > > Thank you. > > Best Regards, > Andrej > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > well if you only need to change cd for vm, permission wise, the userRole and basic user portal are enough, iirc, if using spice (on windows?) that used to be possible, this may be related: https://bugzilla.redhat.com/show_bug.cgi?id=957611 From andrej.bagon at arnes.si Mon Apr 29 10:06:33 2013 From: andrej.bagon at arnes.si (Andrej Bagon) Date: Mon, 29 Apr 2013 12:06:33 +0200 Subject: [Engine-devel] ovirt user portal and attach a cd In-Reply-To: <1682099686.6160454.1367226745207.JavaMail.root@redhat.com> References: <517E2F37.3010807@arnes.si> <1682099686.6160454.1367226745207.JavaMail.root@redhat.com> Message-ID: <517E4629.5050001@arnes.si> We are using oVirt Engine Version: 3.2.1-1.beta1.el6 and linux environment (and vnc for console). Never tried spice console. Best Regards, Andrej On 04/29/2013 11:12 AM, Omer Frenkel wrote: > > ----- Original Message ----- >> From: "Andrej Bagon" >> To: engine-devel at ovirt.org >> Sent: Monday, April 29, 2013 11:28:39 AM >> Subject: [Engine-devel] ovirt user portal and attach a cd >> >> Hi all, >> >> we would like to limit a user as much as possible and give him only >> actions that he needs with his VM. If we disallow a user the right in >> system|configure system|manipulate permissions), we give the user, in >> user portal, only basic mode. But then three is no option to attach a cd >> in the basic user portal. In basic mode user interface there is no >> chance in attaching a cd (as this is a basic operation a solution to >> this would be a button attaching a cd when starting a vm). >> >> If we allow the user to manipulate permissions, we get the extended menu >> back and the user is limited, but we found unacceptable when he is >> adding permission to the VM, he sees all the users (name, surname, >> email!) in the ovirt authentication mechanism? A solution to this would >> be authenticating to the directory service as a user an not as ovirt >> admin user - meaning that the user will see only users that we allowed >> he sees in the ldap directory. >> >> Thank you. >> >> Best Regards, >> Andrej >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > well if you only need to change cd for vm, > permission wise, the userRole and basic user portal are enough, > iirc, if using spice (on windows?) that used to be possible, this may be related: > https://bugzilla.redhat.com/show_bug.cgi?id=957611 > From Kari.Whitcomb at hp.com Mon Apr 29 22:19:00 2013 From: Kari.Whitcomb at hp.com (Whitcomb, Kari) Date: Mon, 29 Apr 2013 22:19:00 +0000 Subject: [Engine-devel] REST vs. UI validation Message-ID: <80DC92D924DD7344818D4A17A1C995D7688D2B86@G9W0733.americas.hpqcorp.net> I've been making use of the oVirt REST api, and have noticed that in several cases the validation done for a REST request is different than what the admin UI does. It seems that the UI is generally more restrictive on the data it will accept than the backend. So you can set things up using the REST api that the UI wouldn't let you do. Two examples I've hit recently, both in the cluster policy (load balancing section): - Cluster load balancing policy duration - the UI requires a value between 1 and 100, but the REST api seems to let you set it to any integer. - Cluster load balancing high and low thresholds / max and min service levels - The UI restricts the high value to 51-90% and the low value to 10-50%. But the backend only requires that the values be 0-100% and that low can't be greater than high. So my question - is this intended behavior, or is it a bug that the validation is different? If similar validation should be done through both the UI and REST api, should the UI be less restrictive, or the backend more restrictive? Thanks, Kari From vered at redhat.com Tue Apr 30 07:15:31 2013 From: vered at redhat.com (Vered Volansky) Date: Tue, 30 Apr 2013 03:15:31 -0400 (EDT) Subject: [Engine-devel] REST vs. UI validation In-Reply-To: <80DC92D924DD7344818D4A17A1C995D7688D2B86@G9W0733.americas.hpqcorp.net> References: <80DC92D924DD7344818D4A17A1C995D7688D2B86@G9W0733.americas.hpqcorp.net> Message-ID: <179985819.7101058.1367306131556.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Kari Whitcomb" > To: engine-devel at ovirt.org > Sent: Tuesday, April 30, 2013 1:19:00 AM > Subject: [Engine-devel] REST vs. UI validation > > I've been making use of the oVirt REST api, and have noticed that in several > cases the validation done for a REST request is different than what the > admin UI does. It seems that the UI is generally more restrictive on the > data it will accept than the backend. So you can set things up using the > REST api that the UI wouldn't let you do. Two examples I've hit recently, > both in the cluster policy (load balancing section): > > - Cluster load balancing policy duration - the UI requires a value between 1 > and 100, but the REST api seems to let you set it to any integer. > > - Cluster load balancing high and low thresholds / max and min service levels > - The UI restricts the high value to 51-90% and the low value to 10-50%. > But the backend only requires that the values be 0-100% and that low can't > be greater than high. > > So my question - is this intended behavior, or is it a bug that the > validation is different? If similar validation should be done through both > the UI and REST api, should the UI be less restrictive, or the backend more > restrictive? This is the intended behaviour. The UI is often more restrictive than the api. By definition the api is more lenient that the UI. Regards, Vered > > Thanks, > Kari > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From lspevak at redhat.com Tue Apr 30 09:50:52 2013 From: lspevak at redhat.com (Libor Spevak) Date: Tue, 30 Apr 2013 11:50:52 +0200 Subject: [Engine-devel] VDSM Fake Message-ID: <517F93FC.7000500@redhat.com> Hi, let me introduce an experimental project called VDSM Fake. This is a small Java web application simulating selected VDSM features, but only from the Engine point of view. The aim was to get oVirt-Engine top performance characteristics in core features simulating hundreds of fake hosts and VMs, and in ecologic way. More info: http://www.ovirt.org/VDSM_Fake Sources: git clone git://github.com/lspevak/ovirt-vdsmfake.git git clone git://github.com/lspevak/ovirt-restapiconf.git Regards, Libor From lzelkha at redhat.com Tue Apr 30 10:48:44 2013 From: lzelkha at redhat.com (Liran Zelkha) Date: Tue, 30 Apr 2013 06:48:44 -0400 (EDT) Subject: [Engine-devel] VDSM Fake In-Reply-To: <517F93FC.7000500@redhat.com> References: <517F93FC.7000500@redhat.com> Message-ID: <1332904058.1994060.1367318924637.JavaMail.root@redhat.com> Awesome. I really need this for the stress tests I'm running. How many hosts were you able to simulate with one web application? ----- Original Message ----- From: "Libor Spevak" To: engine-devel at ovirt.org Sent: Tuesday, April 30, 2013 12:50:52 PM Subject: [Engine-devel] VDSM Fake Hi, let me introduce an experimental project called VDSM Fake. This is a small Java web application simulating selected VDSM features, but only from the Engine point of view. The aim was to get oVirt-Engine top performance characteristics in core features simulating hundreds of fake hosts and VMs, and in ecologic way. More info: http://www.ovirt.org/VDSM_Fake Sources: git clone git://github.com/lspevak/ovirt-vdsmfake.git git clone git://github.com/lspevak/ovirt-restapiconf.git Regards, Libor _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel From lspevak at redhat.com Tue Apr 30 11:00:33 2013 From: lspevak at redhat.com (Libor Spevak) Date: Tue, 30 Apr 2013 13:00:33 +0200 Subject: [Engine-devel] VDSM Fake In-Reply-To: <1332904058.1994060.1367318924637.JavaMail.root@redhat.com> References: <517F93FC.7000500@redhat.com> <1332904058.1994060.1367318924637.JavaMail.root@redhat.com> Message-ID: <517FA451.20703@redhat.com> I didn't have enough time to make a real stress test, I created 100 hosts running 300 VMs, all-in-one - one server running Engine, DB, VDSM Fake. I put the VMs into running state and tried migration. It was rather responsive. The server had still enough resources. On 30.4.2013 12:48, Liran Zelkha wrote: > Awesome. I really need this for the stress tests I'm running. How many hosts were you able to simulate with one web application? > > ----- Original Message ----- > From: "Libor Spevak" > To: engine-devel at ovirt.org > Sent: Tuesday, April 30, 2013 12:50:52 PM > Subject: [Engine-devel] VDSM Fake > > Hi, > > let me introduce an experimental project called VDSM Fake. This is a > small Java web application simulating > selected VDSM features, but only from the Engine point of view. > > The aim was to get oVirt-Engine top performance characteristics in core > features simulating hundreds of fake hosts and VMs, and in ecologic way. > > More info: > http://www.ovirt.org/VDSM_Fake > > Sources: > git clone git://github.com/lspevak/ovirt-vdsmfake.git > git clone git://github.com/lspevak/ovirt-restapiconf.git > > Regards, > Libor > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From laravot at redhat.com Tue Apr 30 11:38:14 2013 From: laravot at redhat.com (Liron Aravot) Date: Tue, 30 Apr 2013 07:38:14 -0400 (EDT) Subject: [Engine-devel] VDSM Fake In-Reply-To: <517FA451.20703@redhat.com> References: <517F93FC.7000500@redhat.com> <1332904058.1994060.1367318924637.JavaMail.root@redhat.com> <517FA451.20703@redhat.com> Message-ID: <860338513.2956112.1367321894574.JavaMail.root@redhat.com> thanks, looks great! ----- Original Message ----- > From: "Libor Spevak" > To: "Liran Zelkha" > Cc: engine-devel at ovirt.org > Sent: Tuesday, April 30, 2013 2:00:33 PM > Subject: Re: [Engine-devel] VDSM Fake > > I didn't have enough time to make a real stress test, I created 100 > hosts running 300 VMs, all-in-one - one server running Engine, DB, VDSM > Fake. I put the VMs into running state and tried migration. It was > rather responsive. > The server had still enough resources. > > On 30.4.2013 12:48, Liran Zelkha wrote: > > Awesome. I really need this for the stress tests I'm running. How many > > hosts were you able to simulate with one web application? > > > > ----- Original Message ----- > > From: "Libor Spevak" > > To: engine-devel at ovirt.org > > Sent: Tuesday, April 30, 2013 12:50:52 PM > > Subject: [Engine-devel] VDSM Fake > > > > Hi, > > > > let me introduce an experimental project called VDSM Fake. This is a > > small Java web application simulating > > selected VDSM features, but only from the Engine point of view. > > > > The aim was to get oVirt-Engine top performance characteristics in core > > features simulating hundreds of fake hosts and VMs, and in ecologic way. > > > > More info: > > http://www.ovirt.org/VDSM_Fake > > > > Sources: > > git clone git://github.com/lspevak/ovirt-vdsmfake.git > > git clone git://github.com/lspevak/ovirt-restapiconf.git > > > > Regards, > > Libor > > > > _______________________________________________ > > 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 Tue Apr 30 11:44:22 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Tue, 30 Apr 2013 07:44:22 -0400 (EDT) Subject: [Engine-devel] VDSM Fake In-Reply-To: <517FA451.20703@redhat.com> References: <517F93FC.7000500@redhat.com> <1332904058.1994060.1367318924637.JavaMail.root@redhat.com> <517FA451.20703@redhat.com> Message-ID: <1684323377.4048350.1367322262854.JavaMail.root@redhat.com> Great job. I guess you're communicating in "in-secure" way with fake-vdsm? ----- Original Message ----- > From: "Libor Spevak" > To: "Liran Zelkha" > Cc: engine-devel at ovirt.org > Sent: Tuesday, April 30, 2013 2:00:33 PM > Subject: Re: [Engine-devel] VDSM Fake > > I didn't have enough time to make a real stress test, I created 100 > hosts running 300 VMs, all-in-one - one server running Engine, DB, VDSM > Fake. I put the VMs into running state and tried migration. It was > rather responsive. > The server had still enough resources. > > On 30.4.2013 12:48, Liran Zelkha wrote: > > Awesome. I really need this for the stress tests I'm running. How many > > hosts were you able to simulate with one web application? > > > > ----- Original Message ----- > > From: "Libor Spevak" > > To: engine-devel at ovirt.org > > Sent: Tuesday, April 30, 2013 12:50:52 PM > > Subject: [Engine-devel] VDSM Fake > > > > Hi, > > > > let me introduce an experimental project called VDSM Fake. This is a > > small Java web application simulating > > selected VDSM features, but only from the Engine point of view. > > > > The aim was to get oVirt-Engine top performance characteristics in core > > features simulating hundreds of fake hosts and VMs, and in ecologic way. > > > > More info: > > http://www.ovirt.org/VDSM_Fake > > > > Sources: > > git clone git://github.com/lspevak/ovirt-vdsmfake.git > > git clone git://github.com/lspevak/ovirt-restapiconf.git > > > > Regards, > > Libor > > > > _______________________________________________ > > 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 lspevak at redhat.com Tue Apr 30 11:49:18 2013 From: lspevak at redhat.com (Libor Spevak) Date: Tue, 30 Apr 2013 13:49:18 +0200 Subject: [Engine-devel] VDSM Fake In-Reply-To: <1684323377.4048350.1367322262854.JavaMail.root@redhat.com> References: <517F93FC.7000500@redhat.com> <1332904058.1994060.1367318924637.JavaMail.root@redhat.com> <517FA451.20703@redhat.com> <1684323377.4048350.1367322262854.JavaMail.root@redhat.com> Message-ID: <517FAFBE.90200@redhat.com> On 30.4.2013 13:44, Yair Zaslavsky wrote: > Great job. > I guess you're communicating in "in-secure" way with fake-vdsm? Yes, I turned off SSL, but to add keys to e.g. Tomcat should not be difficult. The server load will increase a little bit. :) > > ----- Original Message ----- >> From: "Libor Spevak" >> To: "Liran Zelkha" >> Cc: engine-devel at ovirt.org >> Sent: Tuesday, April 30, 2013 2:00:33 PM >> Subject: Re: [Engine-devel] VDSM Fake >> >> I didn't have enough time to make a real stress test, I created 100 >> hosts running 300 VMs, all-in-one - one server running Engine, DB, VDSM >> Fake. I put the VMs into running state and tried migration. It was >> rather responsive. >> The server had still enough resources. >> >> On 30.4.2013 12:48, Liran Zelkha wrote: >>> Awesome. I really need this for the stress tests I'm running. How many >>> hosts were you able to simulate with one web application? >>> >>> ----- Original Message ----- >>> From: "Libor Spevak" >>> To: engine-devel at ovirt.org >>> Sent: Tuesday, April 30, 2013 12:50:52 PM >>> Subject: [Engine-devel] VDSM Fake >>> >>> Hi, >>> >>> let me introduce an experimental project called VDSM Fake. This is a >>> small Java web application simulating >>> selected VDSM features, but only from the Engine point of view. >>> >>> The aim was to get oVirt-Engine top performance characteristics in core >>> features simulating hundreds of fake hosts and VMs, and in ecologic way. >>> >>> More info: >>> http://www.ovirt.org/VDSM_Fake >>> >>> Sources: >>> git clone git://github.com/lspevak/ovirt-vdsmfake.git >>> git clone git://github.com/lspevak/ovirt-restapiconf.git >>> >>> Regards, >>> Libor >>> >>> _______________________________________________ >>> 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 florian.bruschet at gmail.com Tue Apr 30 16:28:12 2013 From: florian.bruschet at gmail.com (Florian BRUSCHET) Date: Tue, 30 Apr 2013 18:28:12 +0200 Subject: [Engine-devel] Root password to add Host Message-ID: Hi, I try to add Host from oVirt Engine Web Administration, but it asks me to give a Root Password (It's not the same that i used to log in admin on the Node). Do i really need this Root Password? Because i can't have it and i don't want to change it by using single mode... There is an other solution to add Hosts? Thank you, Florian BRUSCHET -------------- next part -------------- An HTML attachment was scrubbed... URL: From alonbl at redhat.com Tue Apr 30 17:52:39 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 30 Apr 2013 13:52:39 -0400 (EDT) Subject: [Engine-devel] Root password to add Host In-Reply-To: References: Message-ID: <1148180116.3088932.1367344359986.JavaMail.root@redhat.com> What is 'single mode'? You should be able to set root password via node TUI, at ovirt tab. Or... you can simply perform registration via the node TUI, so you don't need to specify password at all. ----- Original Message ----- > From: "Florian BRUSCHET" > To: engine-devel at ovirt.org > Sent: Tuesday, April 30, 2013 7:28:12 PM > Subject: [Engine-devel] Root password to add Host > > Hi, > > I try to add Host from oVirt Engine Web Administration, but it asks me to > give a Root Password (It's not the same that i used to log in admin on the > Node). > Do i really need this Root Password? Because i can't have it and i don't want > to change it by using single mode... > There is an other solution to add Hosts? > > Thank you, > > Florian BRUSCHET > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From alonbl at redhat.com Tue Apr 30 19:41:20 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 30 Apr 2013 15:41:20 -0400 (EDT) Subject: [Engine-devel] Dropping encryption of database password In-Reply-To: <1003840521.3117171.1367350310165.JavaMail.root@redhat.com> Message-ID: <670062783.3118840.1367350880599.JavaMail.root@redhat.com> Hello, Currently we store database password encrypted using org.picketbox.datasource.security.SecureIdentityLoginModule. This is reverse encryption with common knowledge shared secret. Using encryption with common knowledge shared secret is close to void protection. So far we also stored the password as plain text at /etc/ovirt-engine/.pgpass, this is going to be removed as no component actually uses the .pgpass, however we do need to store non-java specific password in for utilities. In master (aiming to 3.3), we store the database connection details in own file /etc/ovirt-engine/engine.conf.d/50-setup-database.conf owned by ovirt user and not world readable. I would like to use the same 50-setup-database.conf to store plain text password and remove the java specific reversible encrypted password usage. Bottom line... 1. We drop the .pgpass file. 2. We store database connection information in /etc/ovirt-engine/engine.conf.d/ that is readable only by ovirt usage. 3. We drop the java specific reversible encryption in favor of plain text. Thoughts? Alon From alonbl at redhat.com Tue Apr 30 20:56:24 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 30 Apr 2013 16:56:24 -0400 (EDT) Subject: [Engine-devel] Root password to add Host In-Reply-To: References: <1148180116.3088932.1367344359986.JavaMail.root@redhat.com> <1665961376.3125732.1367352519875.JavaMail.root@redhat.com> Message-ID: <2014599378.3138189.1367355384770.JavaMail.root@redhat.com> You cannot do this via agent by via the TUI of the ovirt-node. Just to make sure, you are using ovirt-node as hypervisor, right? ----- Original Message ----- > From: "Florian BRUSCHET" > To: "Alon Bar-Lev" > Sent: Tuesday, April 30, 2013 11:47:53 PM > Subject: Re: [Engine-devel] Root password to add Host > > Oh ok, i didn't know ... > > I was looking my oVirt Engine and i don't understand how i can add an Host > without this password ... > For me i have to right click on the Hosts panel, select "new" and it asks > me to give name, address and Root password. > I have already register this Host from oVirt Node Hypervisor, i add my > Management Server and there is no problem i can see "Certificate Status : > Verified" but this Host don't appears in the Web page ... > > > 2013/4/30 Alon Bar-Lev > > > > > > > ----- Original Message ----- > > > From: "Florian BRUSCHET" > > > To: "Alon Bar-Lev" > > > Sent: Tuesday, April 30, 2013 11:06:14 PM > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > For me single mode it's when you add "single" at the end of the kernel > > > commande line like that you boot on shell commande as root at localhost and > > > you can do what you want. > > > > Oh... this is "single user mode"... :) > > > > > > > > I will try it soon! > > > > > > Thank you > > > > > > Florian > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > What is 'single mode'? > > > > > > > > You should be able to set root password via node TUI, at ovirt tab. > > > > Or... you can simply perform registration via the node TUI, so you > > don't > > > > need to specify password at all. > > > > > > > > ----- Original Message ----- > > > > > From: "Florian BRUSCHET" > > > > > To: engine-devel at ovirt.org > > > > > Sent: Tuesday, April 30, 2013 7:28:12 PM > > > > > Subject: [Engine-devel] Root password to add Host > > > > > > > > > > Hi, > > > > > > > > > > I try to add Host from oVirt Engine Web Administration, but it asks > > me to > > > > > give a Root Password (It's not the same that i used to log in admin > > on > > > > the > > > > > Node). > > > > > Do i really need this Root Password? Because i can't have it and i > > don't > > > > want > > > > > to change it by using single mode... > > > > > There is an other solution to add Hosts? > > > > > > > > > > Thank you, > > > > > > > > > > Florian BRUSCHET > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > From alonbl at redhat.com Tue Apr 30 21:09:40 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 30 Apr 2013 17:09:40 -0400 (EDT) Subject: [Engine-devel] Root password to add Host In-Reply-To: References: <1148180116.3088932.1367344359986.JavaMail.root@redhat.com> <1665961376.3125732.1367352519875.JavaMail.root@redhat.com> <2014599378.3138189.1367355384770.JavaMail.root@redhat.com> Message-ID: <522710063.3140932.1367356180370.JavaMail.root@redhat.com> Please reply to 'all'. When you login as admin you should be presented with Text User Interface. Within this interface there should be options on the left and a dialog on the right. At the left you should see 'ovirt-engine' or similar option, when selecting it, you should see on the right an input field of address of the ovirt-engine server, specifying the engine address and selecting apply will initiate registration into the engine. Once registered, you should see the host in the engine, select it and click on "Approve". Another option is to specify password at the same dialog without filling the engine address. This password may be used as the password withi the 'Add Host' dialog. Alon ----- Original Message ----- > From: "Florian BRUSCHET" > To: "Alon Bar-Lev" > Sent: Wednesday, May 1, 2013 12:00:01 AM > Subject: Re: [Engine-devel] Root password to add Host > > I think I don't really understand what you call TUI? > Yes I'm log as admin on ovirt-node to use Hypervisor > > (And sorry if I make some language faults English isn't my native language > ^^) > > > 2013/4/30 Alon Bar-Lev > > > > > You cannot do this via agent by via the TUI of the ovirt-node. > > > > Just to make sure, you are using ovirt-node as hypervisor, right? > > > > ----- Original Message ----- > > > From: "Florian BRUSCHET" > > > To: "Alon Bar-Lev" > > > Sent: Tuesday, April 30, 2013 11:47:53 PM > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > Oh ok, i didn't know ... > > > > > > I was looking my oVirt Engine and i don't understand how i can add an > > Host > > > without this password ... > > > For me i have to right click on the Hosts panel, select "new" and it asks > > > me to give name, address and Root password. > > > I have already register this Host from oVirt Node Hypervisor, i add my > > > Management Server and there is no problem i can see "Certificate Status : > > > Verified" but this Host don't appears in the Web page ... > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Florian BRUSCHET" > > > > > To: "Alon Bar-Lev" > > > > > Sent: Tuesday, April 30, 2013 11:06:14 PM > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > For me single mode it's when you add "single" at the end of the > > kernel > > > > > commande line like that you boot on shell commande as > > > > > root at localhostand > > > > > you can do what you want. > > > > > > > > Oh... this is "single user mode"... :) > > > > > > > > > > > > > > I will try it soon! > > > > > > > > > > Thank you > > > > > > > > > > Florian > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > What is 'single mode'? > > > > > > > > > > > > You should be able to set root password via node TUI, at ovirt tab. > > > > > > Or... you can simply perform registration via the node TUI, so you > > > > don't > > > > > > need to specify password at all. > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Florian BRUSCHET" > > > > > > > To: engine-devel at ovirt.org > > > > > > > Sent: Tuesday, April 30, 2013 7:28:12 PM > > > > > > > Subject: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I try to add Host from oVirt Engine Web Administration, but it > > asks > > > > me to > > > > > > > give a Root Password (It's not the same that i used to log in > > admin > > > > on > > > > > > the > > > > > > > Node). > > > > > > > Do i really need this Root Password? Because i can't have it and > > i > > > > don't > > > > > > want > > > > > > > to change it by using single mode... > > > > > > > There is an other solution to add Hosts? > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > Florian BRUSCHET > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > From florian.bruschet at gmail.com Tue Apr 30 21:33:38 2013 From: florian.bruschet at gmail.com (Florian BRUSCHET) Date: Tue, 30 Apr 2013 23:33:38 +0200 Subject: [Engine-devel] Root password to add Host In-Reply-To: <522710063.3140932.1367356180370.JavaMail.root@redhat.com> References: <1148180116.3088932.1367344359986.JavaMail.root@redhat.com> <1665961376.3125732.1367352519875.JavaMail.root@redhat.com> <2014599378.3138189.1367355384770.JavaMail.root@redhat.com> <522710063.3140932.1367356180370.JavaMail.root@redhat.com> Message-ID: Ok this what I have done, I see it, I specify the engine address, then he ask me to "Retrieve Certificate" i do it, it works. After I choose "Save & Register", i can see "Activating VDMS", and "All changes were applied successfully". But nothing in the engine ... I tryed the other way but don't work too ... for this solution i'm nearly sure that it's cause the password is wrong, it isn't the one which i specified in ovirt-node. 2013/4/30 Alon Bar-Lev > > Please reply to 'all'. > > When you login as admin you should be presented with Text User Interface. > Within this interface there should be options on the left and a dialog on > the right. > At the left you should see 'ovirt-engine' or similar option, when > selecting it, you should see on the right an input field of address of the > ovirt-engine server, specifying the engine address and selecting apply will > initiate registration into the engine. > > Once registered, you should see the host in the engine, select it and > click on "Approve". > > Another option is to specify password at the same dialog without filling > the engine address. This password may be used as the password withi the > 'Add Host' dialog. > > Alon > > ----- Original Message ----- > > From: "Florian BRUSCHET" > > To: "Alon Bar-Lev" > > Sent: Wednesday, May 1, 2013 12:00:01 AM > > Subject: Re: [Engine-devel] Root password to add Host > > > > I think I don't really understand what you call TUI? > > Yes I'm log as admin on ovirt-node to use Hypervisor > > > > (And sorry if I make some language faults English isn't my native > language > > ^^) > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > You cannot do this via agent by via the TUI of the ovirt-node. > > > > > > Just to make sure, you are using ovirt-node as hypervisor, right? > > > > > > ----- Original Message ----- > > > > From: "Florian BRUSCHET" > > > > To: "Alon Bar-Lev" > > > > Sent: Tuesday, April 30, 2013 11:47:53 PM > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > Oh ok, i didn't know ... > > > > > > > > I was looking my oVirt Engine and i don't understand how i can add an > > > Host > > > > without this password ... > > > > For me i have to right click on the Hosts panel, select "new" and it > asks > > > > me to give name, address and Root password. > > > > I have already register this Host from oVirt Node Hypervisor, i add > my > > > > Management Server and there is no problem i can see "Certificate > Status : > > > > Verified" but this Host don't appears in the Web page ... > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Florian BRUSCHET" > > > > > > To: "Alon Bar-Lev" > > > > > > Sent: Tuesday, April 30, 2013 11:06:14 PM > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > For me single mode it's when you add "single" at the end of the > > > kernel > > > > > > commande line like that you boot on shell commande as > > > > > > root at localhostand > > > > > > you can do what you want. > > > > > > > > > > Oh... this is "single user mode"... :) > > > > > > > > > > > > > > > > > I will try it soon! > > > > > > > > > > > > Thank you > > > > > > > > > > > > Florian > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > What is 'single mode'? > > > > > > > > > > > > > > You should be able to set root password via node TUI, at ovirt > tab. > > > > > > > Or... you can simply perform registration via the node TUI, so > you > > > > > don't > > > > > > > need to specify password at all. > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > Sent: Tuesday, April 30, 2013 7:28:12 PM > > > > > > > > Subject: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I try to add Host from oVirt Engine Web Administration, but > it > > > asks > > > > > me to > > > > > > > > give a Root Password (It's not the same that i used to log in > > > admin > > > > > on > > > > > > > the > > > > > > > > Node). > > > > > > > > Do i really need this Root Password? Because i can't have it > and > > > i > > > > > don't > > > > > > > want > > > > > > > > to change it by using single mode... > > > > > > > > There is an other solution to add Hosts? > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > Florian BRUSCHET > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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: From alonbl at redhat.com Tue Apr 30 21:35:03 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 30 Apr 2013 17:35:03 -0400 (EDT) Subject: [Engine-devel] Root password to add Host In-Reply-To: References: <1665961376.3125732.1367352519875.JavaMail.root@redhat.com> <2014599378.3138189.1367355384770.JavaMail.root@redhat.com> <522710063.3140932.1367356180370.JavaMail.root@redhat.com> Message-ID: <65420993.3146107.1367357703748.JavaMail.root@redhat.com> Can you please attach /var/log/ovirt-engine/engine.log? ----- Original Message ----- > From: "Florian BRUSCHET" > To: "Alon Bar-Lev" > Cc: "engine-devel" > Sent: Wednesday, May 1, 2013 12:33:38 AM > Subject: Re: [Engine-devel] Root password to add Host > > Ok this what I have done, I see it, I specify the engine address, then he > ask me to "Retrieve Certificate" i do it, it works. After I choose "Save & > Register", i can see "Activating VDMS", and "All changes were applied > successfully". But nothing in the engine ... > I tryed the other way but don't work too ... for this solution i'm nearly > sure that it's cause the password is wrong, it isn't the one which i > specified in ovirt-node. > > > 2013/4/30 Alon Bar-Lev > > > > > Please reply to 'all'. > > > > When you login as admin you should be presented with Text User Interface. > > Within this interface there should be options on the left and a dialog on > > the right. > > At the left you should see 'ovirt-engine' or similar option, when > > selecting it, you should see on the right an input field of address of the > > ovirt-engine server, specifying the engine address and selecting apply will > > initiate registration into the engine. > > > > Once registered, you should see the host in the engine, select it and > > click on "Approve". > > > > Another option is to specify password at the same dialog without filling > > the engine address. This password may be used as the password withi the > > 'Add Host' dialog. > > > > Alon > > > > ----- Original Message ----- > > > From: "Florian BRUSCHET" > > > To: "Alon Bar-Lev" > > > Sent: Wednesday, May 1, 2013 12:00:01 AM > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > I think I don't really understand what you call TUI? > > > Yes I'm log as admin on ovirt-node to use Hypervisor > > > > > > (And sorry if I make some language faults English isn't my native > > language > > > ^^) > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > You cannot do this via agent by via the TUI of the ovirt-node. > > > > > > > > Just to make sure, you are using ovirt-node as hypervisor, right? > > > > > > > > ----- Original Message ----- > > > > > From: "Florian BRUSCHET" > > > > > To: "Alon Bar-Lev" > > > > > Sent: Tuesday, April 30, 2013 11:47:53 PM > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > Oh ok, i didn't know ... > > > > > > > > > > I was looking my oVirt Engine and i don't understand how i can add an > > > > Host > > > > > without this password ... > > > > > For me i have to right click on the Hosts panel, select "new" and it > > asks > > > > > me to give name, address and Root password. > > > > > I have already register this Host from oVirt Node Hypervisor, i add > > my > > > > > Management Server and there is no problem i can see "Certificate > > Status : > > > > > Verified" but this Host don't appears in the Web page ... > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Florian BRUSCHET" > > > > > > > To: "Alon Bar-Lev" > > > > > > > Sent: Tuesday, April 30, 2013 11:06:14 PM > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > For me single mode it's when you add "single" at the end of the > > > > kernel > > > > > > > commande line like that you boot on shell commande as > > > > > > > root at localhostand > > > > > > > you can do what you want. > > > > > > > > > > > > Oh... this is "single user mode"... :) > > > > > > > > > > > > > > > > > > > > I will try it soon! > > > > > > > > > > > > > > Thank you > > > > > > > > > > > > > > Florian > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > What is 'single mode'? > > > > > > > > > > > > > > > > You should be able to set root password via node TUI, at ovirt > > tab. > > > > > > > > Or... you can simply perform registration via the node TUI, so > > you > > > > > > don't > > > > > > > > need to specify password at all. > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > > Sent: Tuesday, April 30, 2013 7:28:12 PM > > > > > > > > > Subject: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I try to add Host from oVirt Engine Web Administration, but > > it > > > > asks > > > > > > me to > > > > > > > > > give a Root Password (It's not the same that i used to log in > > > > admin > > > > > > on > > > > > > > > the > > > > > > > > > Node). > > > > > > > > > Do i really need this Root Password? Because i can't have it > > and > > > > i > > > > > > don't > > > > > > > > want > > > > > > > > > to change it by using single mode... > > > > > > > > > There is an other solution to add Hosts? > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > Florian BRUSCHET > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Engine-devel mailing list > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From florian.bruschet at gmail.com Tue Apr 30 21:47:13 2013 From: florian.bruschet at gmail.com (Florian BRUSCHET) Date: Tue, 30 Apr 2013 23:47:13 +0200 Subject: [Engine-devel] Root password to add Host In-Reply-To: <65420993.3146107.1367357703748.JavaMail.root@redhat.com> References: <1665961376.3125732.1367352519875.JavaMail.root@redhat.com> <2014599378.3138189.1367355384770.JavaMail.root@redhat.com> <522710063.3140932.1367356180370.JavaMail.root@redhat.com> <65420993.3146107.1367357703748.JavaMail.root@redhat.com> Message-ID: Sure, 2013-04-30 23:44:35,984 ERROR [org.ovirt.engine.core.pki.PKIResourceServlet] (ajp--127.0.0.1-8702-4) Cannot send public key resource '/etc/pki/ovirt-engine/certs/engine.cer' format 'SSH': java.security.cert.CertificateParsingException: invalid DER-encoded certificate data at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1723) [rt.jar:1.6.0_24] at sun.security.x509.X509CertImpl.(X509CertImpl.java:320) [rt.jar:1.6.0_24] at sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:121) [rt.jar:1.6.0_24] at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:322) [rt.jar:1.6.0_24] at org.ovirt.engine.core.pki.PKIResourceServlet.doGet(PKIResourceServlet.java:83) [classes:] at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.13.Final.jar:] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:] at org.jboss.web.rewrite.RewriteValve.invoke(RewriteValve.java:466) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.13.Final.jar:] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) [jbossweb-7.0.13.Final.jar:] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:] at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24] 2013/4/30 Alon Bar-Lev > > Can you please attach /var/log/ovirt-engine/engine.log? > > ----- Original Message ----- > > From: "Florian BRUSCHET" > > To: "Alon Bar-Lev" > > Cc: "engine-devel" > > Sent: Wednesday, May 1, 2013 12:33:38 AM > > Subject: Re: [Engine-devel] Root password to add Host > > > > Ok this what I have done, I see it, I specify the engine address, then he > > ask me to "Retrieve Certificate" i do it, it works. After I choose "Save > & > > Register", i can see "Activating VDMS", and "All changes were applied > > successfully". But nothing in the engine ... > > I tryed the other way but don't work too ... for this solution i'm nearly > > sure that it's cause the password is wrong, it isn't the one which i > > specified in ovirt-node. > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > Please reply to 'all'. > > > > > > When you login as admin you should be presented with Text User > Interface. > > > Within this interface there should be options on the left and a dialog > on > > > the right. > > > At the left you should see 'ovirt-engine' or similar option, when > > > selecting it, you should see on the right an input field of address of > the > > > ovirt-engine server, specifying the engine address and selecting apply > will > > > initiate registration into the engine. > > > > > > Once registered, you should see the host in the engine, select it and > > > click on "Approve". > > > > > > Another option is to specify password at the same dialog without > filling > > > the engine address. This password may be used as the password withi the > > > 'Add Host' dialog. > > > > > > Alon > > > > > > ----- Original Message ----- > > > > From: "Florian BRUSCHET" > > > > To: "Alon Bar-Lev" > > > > Sent: Wednesday, May 1, 2013 12:00:01 AM > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > I think I don't really understand what you call TUI? > > > > Yes I'm log as admin on ovirt-node to use Hypervisor > > > > > > > > (And sorry if I make some language faults English isn't my native > > > language > > > > ^^) > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > You cannot do this via agent by via the TUI of the ovirt-node. > > > > > > > > > > Just to make sure, you are using ovirt-node as hypervisor, right? > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Florian BRUSCHET" > > > > > > To: "Alon Bar-Lev" > > > > > > Sent: Tuesday, April 30, 2013 11:47:53 PM > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > Oh ok, i didn't know ... > > > > > > > > > > > > I was looking my oVirt Engine and i don't understand how i can > add an > > > > > Host > > > > > > without this password ... > > > > > > For me i have to right click on the Hosts panel, select "new" > and it > > > asks > > > > > > me to give name, address and Root password. > > > > > > I have already register this Host from oVirt Node Hypervisor, i > add > > > my > > > > > > Management Server and there is no problem i can see "Certificate > > > Status : > > > > > > Verified" but this Host don't appears in the Web page ... > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > Sent: Tuesday, April 30, 2013 11:06:14 PM > > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > For me single mode it's when you add "single" at the end of > the > > > > > kernel > > > > > > > > commande line like that you boot on shell commande as > > > > > > > > root at localhostand > > > > > > > > you can do what you want. > > > > > > > > > > > > > > Oh... this is "single user mode"... :) > > > > > > > > > > > > > > > > > > > > > > > I will try it soon! > > > > > > > > > > > > > > > > Thank you > > > > > > > > > > > > > > > > Florian > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > What is 'single mode'? > > > > > > > > > > > > > > > > > > You should be able to set root password via node TUI, at > ovirt > > > tab. > > > > > > > > > Or... you can simply perform registration via the node > TUI, so > > > you > > > > > > > don't > > > > > > > > > need to specify password at all. > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > > > Sent: Tuesday, April 30, 2013 7:28:12 PM > > > > > > > > > > Subject: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I try to add Host from oVirt Engine Web Administration, > but > > > it > > > > > asks > > > > > > > me to > > > > > > > > > > give a Root Password (It's not the same that i used to > log in > > > > > admin > > > > > > > on > > > > > > > > > the > > > > > > > > > > Node). > > > > > > > > > > Do i really need this Root Password? Because i can't > have it > > > and > > > > > i > > > > > > > don't > > > > > > > > > want > > > > > > > > > > to change it by using single mode... > > > > > > > > > > There is an other solution to add Hosts? > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > > > Florian BRUSCHET > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > 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: From alonbl at redhat.com Tue Apr 30 21:49:04 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 30 Apr 2013 17:49:04 -0400 (EDT) Subject: [Engine-devel] Root password to add Host In-Reply-To: References: <2014599378.3138189.1367355384770.JavaMail.root@redhat.com> <522710063.3140932.1367356180370.JavaMail.root@redhat.com> <65420993.3146107.1367357703748.JavaMail.root@redhat.com> Message-ID: <713180332.3148415.1367358544236.JavaMail.root@redhat.com> Which version do you use? this should not happen... what is the output of: $ openssl x509 -in /etc/pki/ovirt-engine/certs/engine.cer -text ----- Original Message ----- > From: "Florian BRUSCHET" > To: "Alon Bar-Lev" > Cc: "engine-devel" > Sent: Wednesday, May 1, 2013 12:47:13 AM > Subject: Re: [Engine-devel] Root password to add Host > > Sure, > > 2013-04-30 23:44:35,984 ERROR > [org.ovirt.engine.core.pki.PKIResourceServlet] (ajp--127.0.0.1-8702-4) > Cannot send public key resource '/etc/pki/ovirt-engine/certs/engine.cer' > format 'SSH': java.security.cert.CertificateParsingException: invalid > DER-encoded certificate data > at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1723) > [rt.jar:1.6.0_24] > at sun.security.x509.X509CertImpl.(X509CertImpl.java:320) > [rt.jar:1.6.0_24] > at > sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:121) > [rt.jar:1.6.0_24] > at > java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:322) > [rt.jar:1.6.0_24] > at > org.ovirt.engine.core.pki.PKIResourceServlet.doGet(PKIResourceServlet.java:83) > [classes:] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) > [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) > [jbossweb-7.0.13.Final.jar:] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) > [jbossweb-7.0.13.Final.jar:] > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) > [jbossweb-7.0.13.Final.jar:] > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) > [jbossweb-7.0.13.Final.jar:] > at > org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) > [jboss-as-web-7.1.1.Final.jar:7.1.1.Final] > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) > [jbossweb-7.0.13.Final.jar:] > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > [jbossweb-7.0.13.Final.jar:] > at org.jboss.web.rewrite.RewriteValve.invoke(RewriteValve.java:466) > [jbossweb-7.0.13.Final.jar:] > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > [jbossweb-7.0.13.Final.jar:] > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) > [jbossweb-7.0.13.Final.jar:] > at > org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) > [jbossweb-7.0.13.Final.jar:] > at > org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) > [jbossweb-7.0.13.Final.jar:] > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) > [jbossweb-7.0.13.Final.jar:] > at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24] > > > > 2013/4/30 Alon Bar-Lev > > > > > Can you please attach /var/log/ovirt-engine/engine.log? > > > > ----- Original Message ----- > > > From: "Florian BRUSCHET" > > > To: "Alon Bar-Lev" > > > Cc: "engine-devel" > > > Sent: Wednesday, May 1, 2013 12:33:38 AM > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > Ok this what I have done, I see it, I specify the engine address, then he > > > ask me to "Retrieve Certificate" i do it, it works. After I choose "Save > > & > > > Register", i can see "Activating VDMS", and "All changes were applied > > > successfully". But nothing in the engine ... > > > I tryed the other way but don't work too ... for this solution i'm nearly > > > sure that it's cause the password is wrong, it isn't the one which i > > > specified in ovirt-node. > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > Please reply to 'all'. > > > > > > > > When you login as admin you should be presented with Text User > > Interface. > > > > Within this interface there should be options on the left and a dialog > > on > > > > the right. > > > > At the left you should see 'ovirt-engine' or similar option, when > > > > selecting it, you should see on the right an input field of address of > > the > > > > ovirt-engine server, specifying the engine address and selecting apply > > will > > > > initiate registration into the engine. > > > > > > > > Once registered, you should see the host in the engine, select it and > > > > click on "Approve". > > > > > > > > Another option is to specify password at the same dialog without > > filling > > > > the engine address. This password may be used as the password withi the > > > > 'Add Host' dialog. > > > > > > > > Alon > > > > > > > > ----- Original Message ----- > > > > > From: "Florian BRUSCHET" > > > > > To: "Alon Bar-Lev" > > > > > Sent: Wednesday, May 1, 2013 12:00:01 AM > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > I think I don't really understand what you call TUI? > > > > > Yes I'm log as admin on ovirt-node to use Hypervisor > > > > > > > > > > (And sorry if I make some language faults English isn't my native > > > > language > > > > > ^^) > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > You cannot do this via agent by via the TUI of the ovirt-node. > > > > > > > > > > > > Just to make sure, you are using ovirt-node as hypervisor, right? > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Florian BRUSCHET" > > > > > > > To: "Alon Bar-Lev" > > > > > > > Sent: Tuesday, April 30, 2013 11:47:53 PM > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > Oh ok, i didn't know ... > > > > > > > > > > > > > > I was looking my oVirt Engine and i don't understand how i can > > add an > > > > > > Host > > > > > > > without this password ... > > > > > > > For me i have to right click on the Hosts panel, select "new" > > and it > > > > asks > > > > > > > me to give name, address and Root password. > > > > > > > I have already register this Host from oVirt Node Hypervisor, i > > add > > > > my > > > > > > > Management Server and there is no problem i can see "Certificate > > > > Status : > > > > > > > Verified" but this Host don't appears in the Web page ... > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > Sent: Tuesday, April 30, 2013 11:06:14 PM > > > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > For me single mode it's when you add "single" at the end of > > the > > > > > > kernel > > > > > > > > > commande line like that you boot on shell commande as > > > > > > > > > root at localhostand > > > > > > > > > you can do what you want. > > > > > > > > > > > > > > > > Oh... this is "single user mode"... :) > > > > > > > > > > > > > > > > > > > > > > > > > > I will try it soon! > > > > > > > > > > > > > > > > > > Thank you > > > > > > > > > > > > > > > > > > Florian > > > > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > What is 'single mode'? > > > > > > > > > > > > > > > > > > > > You should be able to set root password via node TUI, at > > ovirt > > > > tab. > > > > > > > > > > Or... you can simply perform registration via the node > > TUI, so > > > > you > > > > > > > > don't > > > > > > > > > > need to specify password at all. > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > > > > Sent: Tuesday, April 30, 2013 7:28:12 PM > > > > > > > > > > > Subject: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > I try to add Host from oVirt Engine Web Administration, > > but > > > > it > > > > > > asks > > > > > > > > me to > > > > > > > > > > > give a Root Password (It's not the same that i used to > > log in > > > > > > admin > > > > > > > > on > > > > > > > > > > the > > > > > > > > > > > Node). > > > > > > > > > > > Do i really need this Root Password? Because i can't > > have it > > > > and > > > > > > i > > > > > > > > don't > > > > > > > > > > want > > > > > > > > > > > to change it by using single mode... > > > > > > > > > > > There is an other solution to add Hosts? > > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > > > > > Florian BRUSCHET > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From florian.bruschet at gmail.com Tue Apr 30 21:56:07 2013 From: florian.bruschet at gmail.com (Florian BRUSCHET) Date: Tue, 30 Apr 2013 23:56:07 +0200 Subject: [Engine-devel] Root password to add Host In-Reply-To: <713180332.3148415.1367358544236.JavaMail.root@redhat.com> References: <2014599378.3138189.1367355384770.JavaMail.root@redhat.com> <522710063.3140932.1367356180370.JavaMail.root@redhat.com> <65420993.3146107.1367357703748.JavaMail.root@redhat.com> <713180332.3148415.1367358544236.JavaMail.root@redhat.com> Message-ID: I use oVirt 3.x, to install i follow this guide : http://wiki.centos.org/HowTos/oVirt And ovirt-node version is 2.6.0 [root at scenic ~]# openssl x509 -in /etc/pki/ovirt-engine/certs/engine.cer -text Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=lix.polytechnique.fr, CN=CA-scenic.lix.polytechnique.fr.20433 Validity Not Before: Apr 29 15:11:10 2013 Not After : Apr 4 15:11:12 2018 GMT Subject: C=US, O=lix.polytechnique.fr, CN= scenic.lix.polytechnique.fr Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ce:7a:2e:c1:9a:86:2c:c2:76:5e:ea:8b:59:18: 62:7d:7a:9f:55:ff:71:15:f7:93:3f:40:1e:70:5d: 80:43:ea:c7:f4:50:0a:a6:47:2a:f8:07:4d:0c:0a: 4d:01:1e:97:de:36:63:40:df:30:7a:40:9d:34:93: d6:a8:43:c6:b3:62:c1:de:db:57:d1:fb:b9:c6:e2: 34:65:f2:67:e1:8c:91:67:3f:99:a6:2b:7b:8a:51: ad:9c:43:c3:a5:cd:c5:a2:29:e9:99:db:ba:f4:76: d0:e5:41:97:31:fc:13:94:53:af:90:ca:06:aa:7d: 68:04:62:66:a5:90:4b:11:de:07:34:ec:68:89:9c: 13:7b:a2:ba:1f:2a:28:6b:ba:9a:b3:ba:97:5c:96: cd:1e:2e:e7:fc:bf:20:a2:a5:57:f3:73:8d:12:db: 81:00:53:50:a6:54:e9:14:1e:46:69:08:e2:80:b1: 30:97:89:d3:a1:a2:7a:47:a3:c9:2e:c9:ce:14:74: 92:27:02:58:41:d8:e1:dd:9e:99:26:fa:b0:ad:6c: e0:11:3f:17:7d:f7:63:27:62:a3:d0:28:f3:1a:91: ca:65:b7:69:9b:b6:86:85:70:a6:ac:5c:51:e2:ff: e9:f2:28:78:24:21:28:0c:d0:95:a4:f8:e5:67:15: d6:77 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 4A:E0:DF:6D:4D:AD:03:26:30:B5:D4:D4:DC:69:C5:DA:74:B2:66:AB Authority Information Access: CA Issuers - URI: http://scenic.lix.polytechnique.fr:80/ca.crt X509v3 Authority Key Identifier: keyid:7E:D8:AE:56:25:C5:B0:34:96:5A:EA:AF:E9:2D:F3:E0:06:1C:19:D0 DirName:/C=US/O= lix.polytechnique.fr/CN=CA-scenic.lix.polytechnique.fr.20433 serial:01 X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: critical TLS Web Server Authentication, TLS Web Client Authentication Signature Algorithm: sha1WithRSAEncryption 89:f3:e5:af:a8:98:44:fa:60:52:93:4f:7c:e8:62:78:40:f8: c7:a7:e1:c3:38:b5:7d:4c:5b:7a:df:5d:1b:05:2c:ca:43:ce: a2:8a:f6:fd:02:3e:98:6f:bc:ea:a6:78:f7:e4:7a:4f:49:0c: 86:cb:b6:23:2e:b7:93:f1:e8:ba:76:05:21:00:ed:cc:f2:ee: 0e:17:dc:21:0a:21:9e:ce:e1:bf:b5:11:d4:a5:d3:31:dd:f4: e3:c7:ea:40:26:27:45:79:9f:2d:79:91:41:03:61:26:51:31: 54:d5:06:90:cf:d4:a0:8b:b7:8a:b0:02:b4:37:24:0f:b2:26: 99:a9:39:78:48:8a:1b:03:89:64:68:de:9e:cb:fc:99:d6:41: 3d:3d:d9:15:8f:f6:ef:3f:b2:51:c8:dd:60:a8:c5:29:88:20: 69:b9:8a:23:eb:9b:64:94:cd:ad:e2:f9:7c:0e:d7:92:cf:cb: 7d:dd:3b:2d:67:13:1d:c3:0a:51:28:e7:b7:44:36:fa:43:83: 80:13:51:ff:f7:1b:22:c0:80:c5:c1:85:90:87:a6:17:46:44: dc:88:1f:16:69:ee:27:44:89:c0:2b:2a:4d:f9:46:fc:50:f1: 2c:af:af:c1:30:ee:6f:6c:b5:cd:f5:e7:73:99:b0:ff:36:2c: 87:32:66:0e -----BEGIN CERTIFICATE----- MIIEXjCCA0agAwIBAgIBAjANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUbGl4LnBvbHl0ZWNobmlxdWUuZnIxLTArBgNVBAMTJENBLXNjZW5p Yy5saXgucG9seXRlY2huaXF1ZS5mci4yMDQzMzAiFxExMzA0MjkxNTExMTArMDAw MBcNMTgwNDA0MTUxMTEyWjBSMQswCQYDVQQGEwJVUzEdMBsGA1UECgwUbGl4LnBv bHl0ZWNobmlxdWUuZnIxJDAiBgNVBAMMG3NjZW5pYy5saXgucG9seXRlY2huaXF1 ZS5mcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM56LsGahizCdl7q i1kYYn16n1X/cRX3kz9AHnBdgEPqx/RQCqZHKvgHTQwKTQEel942Y0DfMHpAnTST 1qhDxrNiwd7bV9H7ucbiNGXyZ+GMkWc/maYre4pRrZxDw6XNxaIp6ZnbuvR20OVB lzH8E5RTr5DKBqp9aARiZqWQSxHeBzTsaImcE3uiuh8qKGu6mrO6l1yWzR4u5/y/ IKKlV/NzjRLbgQBTUKZU6RQeRmkI4oCxMJeJ06GiekejyS7JzhR0kicCWEHY4d2e mSb6sK1s4BE/F333Yydio9Ao8xqRymW3aZu2hoVwpqxcUeL/6fIoeCQhKAzQlaT4 5WcV1ncCAwEAAaOCATAwggEsMB0GA1UdDgQWBBRK4N9tTa0DJjC11NTcacXadLJm qzBIBggrBgEFBQcBAQQ8MDowOAYIKwYBBQUHMAKGLGh0dHA6Ly9zY2VuaWMubGl4 LnBvbHl0ZWNobmlxdWUuZnI6ODAvY2EuY3J0MIGDBgNVHSMEfDB6gBR+2K5WJcWw NJZa6q/pLfPgBhwZ0KFfpF0wWzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFGxpeC5w b2x5dGVjaG5pcXVlLmZyMS0wKwYDVQQDEyRDQS1zY2VuaWMubGl4LnBvbHl0ZWNo bmlxdWUuZnIuMjA0MzOCAQEwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYD VR0lAQH/BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IB AQCJ8+WvqJhE+mBSk0986GJ4QPjHp+HDOLV9TFt6310bBSzKQ86iivb9Aj6Yb7zq pnj35HpPSQyGy7YjLreT8ei6dgUhAO3M8u4OF9whCiGezuG/tRHUpdMx3fTjx+pA JidFeZ8teZFBA2EmUTFU1QaQz9Sgi7eKsAK0NyQPsiaZqTl4SIobA4lkaN6ey/yZ 1kE9PdkVj/bvP7JRyN1gqMUpiCBpuYoj65tklM2t4vl8DteSz8t93TstZxMdwwpR KOe3RDb6Q4OAE1H/9xsiwIDFwYWQh6YXRkTciB8Wae4nRInAKypN+Ub8UPEsr6/B MO5vbLXN9edzmbD/NiyHMmYO -----END CERTIFICATE----- 2013/4/30 Alon Bar-Lev > Which version do you use? > > this should not happen... > > what is the output of: > > $ openssl x509 -in /etc/pki/ovirt-engine/certs/engine.cer -text > > ----- Original Message ----- > > From: "Florian BRUSCHET" > > To: "Alon Bar-Lev" > > Cc: "engine-devel" > > Sent: Wednesday, May 1, 2013 12:47:13 AM > > Subject: Re: [Engine-devel] Root password to add Host > > > > Sure, > > > > 2013-04-30 23:44:35,984 ERROR > > [org.ovirt.engine.core.pki.PKIResourceServlet] (ajp--127.0.0.1-8702-4) > > Cannot send public key resource '/etc/pki/ovirt-engine/certs/engine.cer' > > format 'SSH': java.security.cert.CertificateParsingException: invalid > > DER-encoded certificate data > > at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1723) > > [rt.jar:1.6.0_24] > > at sun.security.x509.X509CertImpl.(X509CertImpl.java:320) > > [rt.jar:1.6.0_24] > > at > > > sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:121) > > [rt.jar:1.6.0_24] > > at > > > java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:322) > > [rt.jar:1.6.0_24] > > at > > > org.ovirt.engine.core.pki.PKIResourceServlet.doGet(PKIResourceServlet.java:83) > > [classes:] > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) > > [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > > [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] > > at > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) > > [jbossweb-7.0.13.Final.jar:] > > at > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) > > [jbossweb-7.0.13.Final.jar:] > > at > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) > > [jbossweb-7.0.13.Final.jar:] > > at > > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) > > [jbossweb-7.0.13.Final.jar:] > > at > > > org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) > > [jboss-as-web-7.1.1.Final.jar:7.1.1.Final] > > at > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) > > [jbossweb-7.0.13.Final.jar:] > > at > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > > [jbossweb-7.0.13.Final.jar:] > > at > org.jboss.web.rewrite.RewriteValve.invoke(RewriteValve.java:466) > > [jbossweb-7.0.13.Final.jar:] > > at > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > > [jbossweb-7.0.13.Final.jar:] > > at > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) > > [jbossweb-7.0.13.Final.jar:] > > at > > org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) > > [jbossweb-7.0.13.Final.jar:] > > at > > > org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) > > [jbossweb-7.0.13.Final.jar:] > > at > > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) > > [jbossweb-7.0.13.Final.jar:] > > at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24] > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > Can you please attach /var/log/ovirt-engine/engine.log? > > > > > > ----- Original Message ----- > > > > From: "Florian BRUSCHET" > > > > To: "Alon Bar-Lev" > > > > Cc: "engine-devel" > > > > Sent: Wednesday, May 1, 2013 12:33:38 AM > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > Ok this what I have done, I see it, I specify the engine address, > then he > > > > ask me to "Retrieve Certificate" i do it, it works. After I choose > "Save > > > & > > > > Register", i can see "Activating VDMS", and "All changes were applied > > > > successfully". But nothing in the engine ... > > > > I tryed the other way but don't work too ... for this solution i'm > nearly > > > > sure that it's cause the password is wrong, it isn't the one which i > > > > specified in ovirt-node. > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > Please reply to 'all'. > > > > > > > > > > When you login as admin you should be presented with Text User > > > Interface. > > > > > Within this interface there should be options on the left and a > dialog > > > on > > > > > the right. > > > > > At the left you should see 'ovirt-engine' or similar option, when > > > > > selecting it, you should see on the right an input field of > address of > > > the > > > > > ovirt-engine server, specifying the engine address and selecting > apply > > > will > > > > > initiate registration into the engine. > > > > > > > > > > Once registered, you should see the host in the engine, select it > and > > > > > click on "Approve". > > > > > > > > > > Another option is to specify password at the same dialog without > > > filling > > > > > the engine address. This password may be used as the password > withi the > > > > > 'Add Host' dialog. > > > > > > > > > > Alon > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Florian BRUSCHET" > > > > > > To: "Alon Bar-Lev" > > > > > > Sent: Wednesday, May 1, 2013 12:00:01 AM > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > I think I don't really understand what you call TUI? > > > > > > Yes I'm log as admin on ovirt-node to use Hypervisor > > > > > > > > > > > > (And sorry if I make some language faults English isn't my native > > > > > language > > > > > > ^^) > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > You cannot do this via agent by via the TUI of the ovirt-node. > > > > > > > > > > > > > > Just to make sure, you are using ovirt-node as hypervisor, > right? > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > Sent: Tuesday, April 30, 2013 11:47:53 PM > > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > Oh ok, i didn't know ... > > > > > > > > > > > > > > > > I was looking my oVirt Engine and i don't understand how i > can > > > add an > > > > > > > Host > > > > > > > > without this password ... > > > > > > > > For me i have to right click on the Hosts panel, select "new" > > > and it > > > > > asks > > > > > > > > me to give name, address and Root password. > > > > > > > > I have already register this Host from oVirt Node > Hypervisor, i > > > add > > > > > my > > > > > > > > Management Server and there is no problem i can see > "Certificate > > > > > Status : > > > > > > > > Verified" but this Host don't appears in the Web page ... > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > > Sent: Tuesday, April 30, 2013 11:06:14 PM > > > > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > > > For me single mode it's when you add "single" at the end > of > > > the > > > > > > > kernel > > > > > > > > > > commande line like that you boot on shell commande as > > > > > > > > > > root at localhostand > > > > > > > > > > you can do what you want. > > > > > > > > > > > > > > > > > > Oh... this is "single user mode"... :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I will try it soon! > > > > > > > > > > > > > > > > > > > > Thank you > > > > > > > > > > > > > > > > > > > > Florian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > What is 'single mode'? > > > > > > > > > > > > > > > > > > > > > > You should be able to set root password via node TUI, > at > > > ovirt > > > > > tab. > > > > > > > > > > > Or... you can simply perform registration via the node > > > TUI, so > > > > > you > > > > > > > > > don't > > > > > > > > > > > need to specify password at all. > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > > > > > Sent: Tuesday, April 30, 2013 7:28:12 PM > > > > > > > > > > > > Subject: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > I try to add Host from oVirt Engine Web > Administration, > > > but > > > > > it > > > > > > > asks > > > > > > > > > me to > > > > > > > > > > > > give a Root Password (It's not the same that i used > to > > > log in > > > > > > > admin > > > > > > > > > on > > > > > > > > > > > the > > > > > > > > > > > > Node). > > > > > > > > > > > > Do i really need this Root Password? Because i can't > > > have it > > > > > and > > > > > > > i > > > > > > > > > don't > > > > > > > > > > > want > > > > > > > > > > > > to change it by using single mode... > > > > > > > > > > > > There is an other solution to add Hosts? > > > > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > > > > > > > Florian BRUSCHET > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > 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: From alonbl at redhat.com Tue Apr 30 21:59:05 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 30 Apr 2013 17:59:05 -0400 (EDT) Subject: [Engine-devel] Root password to add Host In-Reply-To: References: <522710063.3140932.1367356180370.JavaMail.root@redhat.com> <65420993.3146107.1367357703748.JavaMail.root@redhat.com> <713180332.3148415.1367358544236.JavaMail.root@redhat.com> Message-ID: <2063948352.3149451.1367359145052.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Florian BRUSCHET" > To: "Alon Bar-Lev" > Cc: "engine-devel" > Sent: Wednesday, May 1, 2013 12:56:07 AM > Subject: Re: [Engine-devel] Root password to add Host > > I use oVirt 3.x, to install i follow this guide : > http://wiki.centos.org/HowTos/oVirt The x is quite important... rpm -q ovirt-engine Also, please send your java version: java -version > And ovirt-node version is 2.6.0 > > [root at scenic ~]# openssl x509 -in /etc/pki/ovirt-engine/certs/engine.cer > -text > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 2 (0x2) > Signature Algorithm: sha1WithRSAEncryption > Issuer: C=US, O=lix.polytechnique.fr, > CN=CA-scenic.lix.polytechnique.fr.20433 > Validity > Not Before: Apr 29 15:11:10 2013 > Not After : Apr 4 15:11:12 2018 GMT > Subject: C=US, O=lix.polytechnique.fr, CN= > scenic.lix.polytechnique.fr > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > Modulus: > 00:ce:7a:2e:c1:9a:86:2c:c2:76:5e:ea:8b:59:18: > 62:7d:7a:9f:55:ff:71:15:f7:93:3f:40:1e:70:5d: > 80:43:ea:c7:f4:50:0a:a6:47:2a:f8:07:4d:0c:0a: > 4d:01:1e:97:de:36:63:40:df:30:7a:40:9d:34:93: > d6:a8:43:c6:b3:62:c1:de:db:57:d1:fb:b9:c6:e2: > 34:65:f2:67:e1:8c:91:67:3f:99:a6:2b:7b:8a:51: > ad:9c:43:c3:a5:cd:c5:a2:29:e9:99:db:ba:f4:76: > d0:e5:41:97:31:fc:13:94:53:af:90:ca:06:aa:7d: > 68:04:62:66:a5:90:4b:11:de:07:34:ec:68:89:9c: > 13:7b:a2:ba:1f:2a:28:6b:ba:9a:b3:ba:97:5c:96: > cd:1e:2e:e7:fc:bf:20:a2:a5:57:f3:73:8d:12:db: > 81:00:53:50:a6:54:e9:14:1e:46:69:08:e2:80:b1: > 30:97:89:d3:a1:a2:7a:47:a3:c9:2e:c9:ce:14:74: > 92:27:02:58:41:d8:e1:dd:9e:99:26:fa:b0:ad:6c: > e0:11:3f:17:7d:f7:63:27:62:a3:d0:28:f3:1a:91: > ca:65:b7:69:9b:b6:86:85:70:a6:ac:5c:51:e2:ff: > e9:f2:28:78:24:21:28:0c:d0:95:a4:f8:e5:67:15: > d6:77 > Exponent: 65537 (0x10001) > X509v3 extensions: > X509v3 Subject Key Identifier: > 4A:E0:DF:6D:4D:AD:03:26:30:B5:D4:D4:DC:69:C5:DA:74:B2:66:AB > Authority Information Access: > CA Issuers - URI: > http://scenic.lix.polytechnique.fr:80/ca.crt > > X509v3 Authority Key Identifier: > > keyid:7E:D8:AE:56:25:C5:B0:34:96:5A:EA:AF:E9:2D:F3:E0:06:1C:19:D0 > DirName:/C=US/O= > lix.polytechnique.fr/CN=CA-scenic.lix.polytechnique.fr.20433 > serial:01 > > X509v3 Basic Constraints: > CA:FALSE > X509v3 Key Usage: critical > Digital Signature, Key Encipherment > X509v3 Extended Key Usage: critical > TLS Web Server Authentication, TLS Web Client Authentication > Signature Algorithm: sha1WithRSAEncryption > 89:f3:e5:af:a8:98:44:fa:60:52:93:4f:7c:e8:62:78:40:f8: > c7:a7:e1:c3:38:b5:7d:4c:5b:7a:df:5d:1b:05:2c:ca:43:ce: > a2:8a:f6:fd:02:3e:98:6f:bc:ea:a6:78:f7:e4:7a:4f:49:0c: > 86:cb:b6:23:2e:b7:93:f1:e8:ba:76:05:21:00:ed:cc:f2:ee: > 0e:17:dc:21:0a:21:9e:ce:e1:bf:b5:11:d4:a5:d3:31:dd:f4: > e3:c7:ea:40:26:27:45:79:9f:2d:79:91:41:03:61:26:51:31: > 54:d5:06:90:cf:d4:a0:8b:b7:8a:b0:02:b4:37:24:0f:b2:26: > 99:a9:39:78:48:8a:1b:03:89:64:68:de:9e:cb:fc:99:d6:41: > 3d:3d:d9:15:8f:f6:ef:3f:b2:51:c8:dd:60:a8:c5:29:88:20: > 69:b9:8a:23:eb:9b:64:94:cd:ad:e2:f9:7c:0e:d7:92:cf:cb: > 7d:dd:3b:2d:67:13:1d:c3:0a:51:28:e7:b7:44:36:fa:43:83: > 80:13:51:ff:f7:1b:22:c0:80:c5:c1:85:90:87:a6:17:46:44: > dc:88:1f:16:69:ee:27:44:89:c0:2b:2a:4d:f9:46:fc:50:f1: > 2c:af:af:c1:30:ee:6f:6c:b5:cd:f5:e7:73:99:b0:ff:36:2c: > 87:32:66:0e > -----BEGIN CERTIFICATE----- > MIIEXjCCA0agAwIBAgIBAjANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJVUzEd > MBsGA1UEChMUbGl4LnBvbHl0ZWNobmlxdWUuZnIxLTArBgNVBAMTJENBLXNjZW5p > Yy5saXgucG9seXRlY2huaXF1ZS5mci4yMDQzMzAiFxExMzA0MjkxNTExMTArMDAw > MBcNMTgwNDA0MTUxMTEyWjBSMQswCQYDVQQGEwJVUzEdMBsGA1UECgwUbGl4LnBv > bHl0ZWNobmlxdWUuZnIxJDAiBgNVBAMMG3NjZW5pYy5saXgucG9seXRlY2huaXF1 > ZS5mcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM56LsGahizCdl7q > i1kYYn16n1X/cRX3kz9AHnBdgEPqx/RQCqZHKvgHTQwKTQEel942Y0DfMHpAnTST > 1qhDxrNiwd7bV9H7ucbiNGXyZ+GMkWc/maYre4pRrZxDw6XNxaIp6ZnbuvR20OVB > lzH8E5RTr5DKBqp9aARiZqWQSxHeBzTsaImcE3uiuh8qKGu6mrO6l1yWzR4u5/y/ > IKKlV/NzjRLbgQBTUKZU6RQeRmkI4oCxMJeJ06GiekejyS7JzhR0kicCWEHY4d2e > mSb6sK1s4BE/F333Yydio9Ao8xqRymW3aZu2hoVwpqxcUeL/6fIoeCQhKAzQlaT4 > 5WcV1ncCAwEAAaOCATAwggEsMB0GA1UdDgQWBBRK4N9tTa0DJjC11NTcacXadLJm > qzBIBggrBgEFBQcBAQQ8MDowOAYIKwYBBQUHMAKGLGh0dHA6Ly9zY2VuaWMubGl4 > LnBvbHl0ZWNobmlxdWUuZnI6ODAvY2EuY3J0MIGDBgNVHSMEfDB6gBR+2K5WJcWw > NJZa6q/pLfPgBhwZ0KFfpF0wWzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFGxpeC5w > b2x5dGVjaG5pcXVlLmZyMS0wKwYDVQQDEyRDQS1zY2VuaWMubGl4LnBvbHl0ZWNo > bmlxdWUuZnIuMjA0MzOCAQEwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYD > VR0lAQH/BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IB > AQCJ8+WvqJhE+mBSk0986GJ4QPjHp+HDOLV9TFt6310bBSzKQ86iivb9Aj6Yb7zq > pnj35HpPSQyGy7YjLreT8ei6dgUhAO3M8u4OF9whCiGezuG/tRHUpdMx3fTjx+pA > JidFeZ8teZFBA2EmUTFU1QaQz9Sgi7eKsAK0NyQPsiaZqTl4SIobA4lkaN6ey/yZ > 1kE9PdkVj/bvP7JRyN1gqMUpiCBpuYoj65tklM2t4vl8DteSz8t93TstZxMdwwpR > KOe3RDb6Q4OAE1H/9xsiwIDFwYWQh6YXRkTciB8Wae4nRInAKypN+Ub8UPEsr6/B > MO5vbLXN9edzmbD/NiyHMmYO > -----END CERTIFICATE----- > > > > 2013/4/30 Alon Bar-Lev > > > Which version do you use? > > > > this should not happen... > > > > what is the output of: > > > > $ openssl x509 -in /etc/pki/ovirt-engine/certs/engine.cer -text > > > > ----- Original Message ----- > > > From: "Florian BRUSCHET" > > > To: "Alon Bar-Lev" > > > Cc: "engine-devel" > > > Sent: Wednesday, May 1, 2013 12:47:13 AM > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > Sure, > > > > > > 2013-04-30 23:44:35,984 ERROR > > > [org.ovirt.engine.core.pki.PKIResourceServlet] (ajp--127.0.0.1-8702-4) > > > Cannot send public key resource '/etc/pki/ovirt-engine/certs/engine.cer' > > > format 'SSH': java.security.cert.CertificateParsingException: invalid > > > DER-encoded certificate data > > > at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1723) > > > [rt.jar:1.6.0_24] > > > at sun.security.x509.X509CertImpl.(X509CertImpl.java:320) > > > [rt.jar:1.6.0_24] > > > at > > > > > sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:121) > > > [rt.jar:1.6.0_24] > > > at > > > > > java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:322) > > > [rt.jar:1.6.0_24] > > > at > > > > > org.ovirt.engine.core.pki.PKIResourceServlet.doGet(PKIResourceServlet.java:83) > > > [classes:] > > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) > > > [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] > > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > > > [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] > > > at > > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) > > > [jbossweb-7.0.13.Final.jar:] > > > at > > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) > > > [jbossweb-7.0.13.Final.jar:] > > > at > > > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) > > > [jbossweb-7.0.13.Final.jar:] > > > at > > > > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) > > > [jbossweb-7.0.13.Final.jar:] > > > at > > > > > org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) > > > [jboss-as-web-7.1.1.Final.jar:7.1.1.Final] > > > at > > > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) > > > [jbossweb-7.0.13.Final.jar:] > > > at > > > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > > > [jbossweb-7.0.13.Final.jar:] > > > at > > org.jboss.web.rewrite.RewriteValve.invoke(RewriteValve.java:466) > > > [jbossweb-7.0.13.Final.jar:] > > > at > > > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > > > [jbossweb-7.0.13.Final.jar:] > > > at > > > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) > > > [jbossweb-7.0.13.Final.jar:] > > > at > > > org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) > > > [jbossweb-7.0.13.Final.jar:] > > > at > > > > > org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) > > > [jbossweb-7.0.13.Final.jar:] > > > at > > > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) > > > [jbossweb-7.0.13.Final.jar:] > > > at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24] > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > Can you please attach /var/log/ovirt-engine/engine.log? > > > > > > > > ----- Original Message ----- > > > > > From: "Florian BRUSCHET" > > > > > To: "Alon Bar-Lev" > > > > > Cc: "engine-devel" > > > > > Sent: Wednesday, May 1, 2013 12:33:38 AM > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > Ok this what I have done, I see it, I specify the engine address, > > then he > > > > > ask me to "Retrieve Certificate" i do it, it works. After I choose > > "Save > > > > & > > > > > Register", i can see "Activating VDMS", and "All changes were applied > > > > > successfully". But nothing in the engine ... > > > > > I tryed the other way but don't work too ... for this solution i'm > > nearly > > > > > sure that it's cause the password is wrong, it isn't the one which i > > > > > specified in ovirt-node. > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > Please reply to 'all'. > > > > > > > > > > > > When you login as admin you should be presented with Text User > > > > Interface. > > > > > > Within this interface there should be options on the left and a > > dialog > > > > on > > > > > > the right. > > > > > > At the left you should see 'ovirt-engine' or similar option, when > > > > > > selecting it, you should see on the right an input field of > > address of > > > > the > > > > > > ovirt-engine server, specifying the engine address and selecting > > apply > > > > will > > > > > > initiate registration into the engine. > > > > > > > > > > > > Once registered, you should see the host in the engine, select it > > and > > > > > > click on "Approve". > > > > > > > > > > > > Another option is to specify password at the same dialog without > > > > filling > > > > > > the engine address. This password may be used as the password > > withi the > > > > > > 'Add Host' dialog. > > > > > > > > > > > > Alon > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Florian BRUSCHET" > > > > > > > To: "Alon Bar-Lev" > > > > > > > Sent: Wednesday, May 1, 2013 12:00:01 AM > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > I think I don't really understand what you call TUI? > > > > > > > Yes I'm log as admin on ovirt-node to use Hypervisor > > > > > > > > > > > > > > (And sorry if I make some language faults English isn't my native > > > > > > language > > > > > > > ^^) > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > You cannot do this via agent by via the TUI of the ovirt-node. > > > > > > > > > > > > > > > > Just to make sure, you are using ovirt-node as hypervisor, > > right? > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > Sent: Tuesday, April 30, 2013 11:47:53 PM > > > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > Oh ok, i didn't know ... > > > > > > > > > > > > > > > > > > I was looking my oVirt Engine and i don't understand how i > > can > > > > add an > > > > > > > > Host > > > > > > > > > without this password ... > > > > > > > > > For me i have to right click on the Hosts panel, select "new" > > > > and it > > > > > > asks > > > > > > > > > me to give name, address and Root password. > > > > > > > > > I have already register this Host from oVirt Node > > Hypervisor, i > > > > add > > > > > > my > > > > > > > > > Management Server and there is no problem i can see > > "Certificate > > > > > > Status : > > > > > > > > > Verified" but this Host don't appears in the Web page ... > > > > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > > > Sent: Tuesday, April 30, 2013 11:06:14 PM > > > > > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > > > > > For me single mode it's when you add "single" at the end > > of > > > > the > > > > > > > > kernel > > > > > > > > > > > commande line like that you boot on shell commande as > > > > > > > > > > > root at localhostand > > > > > > > > > > > you can do what you want. > > > > > > > > > > > > > > > > > > > > Oh... this is "single user mode"... :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I will try it soon! > > > > > > > > > > > > > > > > > > > > > > Thank you > > > > > > > > > > > > > > > > > > > > > > Florian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > What is 'single mode'? > > > > > > > > > > > > > > > > > > > > > > > > You should be able to set root password via node TUI, > > at > > > > ovirt > > > > > > tab. > > > > > > > > > > > > Or... you can simply perform registration via the node > > > > TUI, so > > > > > > you > > > > > > > > > > don't > > > > > > > > > > > > need to specify password at all. > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > > > > > > Sent: Tuesday, April 30, 2013 7:28:12 PM > > > > > > > > > > > > > Subject: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > I try to add Host from oVirt Engine Web > > Administration, > > > > but > > > > > > it > > > > > > > > asks > > > > > > > > > > me to > > > > > > > > > > > > > give a Root Password (It's not the same that i used > > to > > > > log in > > > > > > > > admin > > > > > > > > > > on > > > > > > > > > > > > the > > > > > > > > > > > > > Node). > > > > > > > > > > > > > Do i really need this Root Password? Because i can't > > > > have it > > > > > > and > > > > > > > > i > > > > > > > > > > don't > > > > > > > > > > > > want > > > > > > > > > > > > > to change it by using single mode... > > > > > > > > > > > > > There is an other solution to add Hosts? > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > > > > > > > > > Florian BRUSCHET > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From florian.bruschet at gmail.com Tue Apr 30 22:00:55 2013 From: florian.bruschet at gmail.com (Florian BRUSCHET) Date: Wed, 1 May 2013 00:00:55 +0200 Subject: [Engine-devel] Root password to add Host In-Reply-To: <2063948352.3149451.1367359145052.JavaMail.root@redhat.com> References: <522710063.3140932.1367356180370.JavaMail.root@redhat.com> <65420993.3146107.1367357703748.JavaMail.root@redhat.com> <713180332.3148415.1367358544236.JavaMail.root@redhat.com> <2063948352.3149451.1367359145052.JavaMail.root@redhat.com> Message-ID: Oh sure, [root at scenic ~]# rpm -q ovirt-engine ovirt-engine-3.1.0-3.26.3.el6.centos.alt.noarch [root at scenic ~]# java -version java version "1.7.0_19" OpenJDK Runtime Environment (rhel-2.3.9.1.el6_4-x86_64) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) 2013/4/30 Alon Bar-Lev > > > ----- Original Message ----- > > From: "Florian BRUSCHET" > > To: "Alon Bar-Lev" > > Cc: "engine-devel" > > Sent: Wednesday, May 1, 2013 12:56:07 AM > > Subject: Re: [Engine-devel] Root password to add Host > > > > I use oVirt 3.x, to install i follow this guide : > > http://wiki.centos.org/HowTos/oVirt > > The x is quite important... > rpm -q ovirt-engine > > Also, please send your java version: > java -version > > > And ovirt-node version is 2.6.0 > > > > [root at scenic ~]# openssl x509 -in /etc/pki/ovirt-engine/certs/engine.cer > > -text > > Certificate: > > Data: > > Version: 3 (0x2) > > Serial Number: 2 (0x2) > > Signature Algorithm: sha1WithRSAEncryption > > Issuer: C=US, O=lix.polytechnique.fr, > > CN=CA-scenic.lix.polytechnique.fr.20433 > > Validity > > Not Before: Apr 29 15:11:10 2013 > > Not After : Apr 4 15:11:12 2018 GMT > > Subject: C=US, O=lix.polytechnique.fr, CN= > > scenic.lix.polytechnique.fr > > Subject Public Key Info: > > Public Key Algorithm: rsaEncryption > > Public-Key: (2048 bit) > > Modulus: > > 00:ce:7a:2e:c1:9a:86:2c:c2:76:5e:ea:8b:59:18: > > 62:7d:7a:9f:55:ff:71:15:f7:93:3f:40:1e:70:5d: > > 80:43:ea:c7:f4:50:0a:a6:47:2a:f8:07:4d:0c:0a: > > 4d:01:1e:97:de:36:63:40:df:30:7a:40:9d:34:93: > > d6:a8:43:c6:b3:62:c1:de:db:57:d1:fb:b9:c6:e2: > > 34:65:f2:67:e1:8c:91:67:3f:99:a6:2b:7b:8a:51: > > ad:9c:43:c3:a5:cd:c5:a2:29:e9:99:db:ba:f4:76: > > d0:e5:41:97:31:fc:13:94:53:af:90:ca:06:aa:7d: > > 68:04:62:66:a5:90:4b:11:de:07:34:ec:68:89:9c: > > 13:7b:a2:ba:1f:2a:28:6b:ba:9a:b3:ba:97:5c:96: > > cd:1e:2e:e7:fc:bf:20:a2:a5:57:f3:73:8d:12:db: > > 81:00:53:50:a6:54:e9:14:1e:46:69:08:e2:80:b1: > > 30:97:89:d3:a1:a2:7a:47:a3:c9:2e:c9:ce:14:74: > > 92:27:02:58:41:d8:e1:dd:9e:99:26:fa:b0:ad:6c: > > e0:11:3f:17:7d:f7:63:27:62:a3:d0:28:f3:1a:91: > > ca:65:b7:69:9b:b6:86:85:70:a6:ac:5c:51:e2:ff: > > e9:f2:28:78:24:21:28:0c:d0:95:a4:f8:e5:67:15: > > d6:77 > > Exponent: 65537 (0x10001) > > X509v3 extensions: > > X509v3 Subject Key Identifier: > > > 4A:E0:DF:6D:4D:AD:03:26:30:B5:D4:D4:DC:69:C5:DA:74:B2:66:AB > > Authority Information Access: > > CA Issuers - URI: > > http://scenic.lix.polytechnique.fr:80/ca.crt > > > > X509v3 Authority Key Identifier: > > > > keyid:7E:D8:AE:56:25:C5:B0:34:96:5A:EA:AF:E9:2D:F3:E0:06:1C:19:D0 > > DirName:/C=US/O= > > lix.polytechnique.fr/CN=CA-scenic.lix.polytechnique.fr.20433 > > serial:01 > > > > X509v3 Basic Constraints: > > CA:FALSE > > X509v3 Key Usage: critical > > Digital Signature, Key Encipherment > > X509v3 Extended Key Usage: critical > > TLS Web Server Authentication, TLS Web Client > Authentication > > Signature Algorithm: sha1WithRSAEncryption > > 89:f3:e5:af:a8:98:44:fa:60:52:93:4f:7c:e8:62:78:40:f8: > > c7:a7:e1:c3:38:b5:7d:4c:5b:7a:df:5d:1b:05:2c:ca:43:ce: > > a2:8a:f6:fd:02:3e:98:6f:bc:ea:a6:78:f7:e4:7a:4f:49:0c: > > 86:cb:b6:23:2e:b7:93:f1:e8:ba:76:05:21:00:ed:cc:f2:ee: > > 0e:17:dc:21:0a:21:9e:ce:e1:bf:b5:11:d4:a5:d3:31:dd:f4: > > e3:c7:ea:40:26:27:45:79:9f:2d:79:91:41:03:61:26:51:31: > > 54:d5:06:90:cf:d4:a0:8b:b7:8a:b0:02:b4:37:24:0f:b2:26: > > 99:a9:39:78:48:8a:1b:03:89:64:68:de:9e:cb:fc:99:d6:41: > > 3d:3d:d9:15:8f:f6:ef:3f:b2:51:c8:dd:60:a8:c5:29:88:20: > > 69:b9:8a:23:eb:9b:64:94:cd:ad:e2:f9:7c:0e:d7:92:cf:cb: > > 7d:dd:3b:2d:67:13:1d:c3:0a:51:28:e7:b7:44:36:fa:43:83: > > 80:13:51:ff:f7:1b:22:c0:80:c5:c1:85:90:87:a6:17:46:44: > > dc:88:1f:16:69:ee:27:44:89:c0:2b:2a:4d:f9:46:fc:50:f1: > > 2c:af:af:c1:30:ee:6f:6c:b5:cd:f5:e7:73:99:b0:ff:36:2c: > > 87:32:66:0e > > -----BEGIN CERTIFICATE----- > > MIIEXjCCA0agAwIBAgIBAjANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJVUzEd > > MBsGA1UEChMUbGl4LnBvbHl0ZWNobmlxdWUuZnIxLTArBgNVBAMTJENBLXNjZW5p > > Yy5saXgucG9seXRlY2huaXF1ZS5mci4yMDQzMzAiFxExMzA0MjkxNTExMTArMDAw > > MBcNMTgwNDA0MTUxMTEyWjBSMQswCQYDVQQGEwJVUzEdMBsGA1UECgwUbGl4LnBv > > bHl0ZWNobmlxdWUuZnIxJDAiBgNVBAMMG3NjZW5pYy5saXgucG9seXRlY2huaXF1 > > ZS5mcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM56LsGahizCdl7q > > i1kYYn16n1X/cRX3kz9AHnBdgEPqx/RQCqZHKvgHTQwKTQEel942Y0DfMHpAnTST > > 1qhDxrNiwd7bV9H7ucbiNGXyZ+GMkWc/maYre4pRrZxDw6XNxaIp6ZnbuvR20OVB > > lzH8E5RTr5DKBqp9aARiZqWQSxHeBzTsaImcE3uiuh8qKGu6mrO6l1yWzR4u5/y/ > > IKKlV/NzjRLbgQBTUKZU6RQeRmkI4oCxMJeJ06GiekejyS7JzhR0kicCWEHY4d2e > > mSb6sK1s4BE/F333Yydio9Ao8xqRymW3aZu2hoVwpqxcUeL/6fIoeCQhKAzQlaT4 > > 5WcV1ncCAwEAAaOCATAwggEsMB0GA1UdDgQWBBRK4N9tTa0DJjC11NTcacXadLJm > > qzBIBggrBgEFBQcBAQQ8MDowOAYIKwYBBQUHMAKGLGh0dHA6Ly9zY2VuaWMubGl4 > > LnBvbHl0ZWNobmlxdWUuZnI6ODAvY2EuY3J0MIGDBgNVHSMEfDB6gBR+2K5WJcWw > > NJZa6q/pLfPgBhwZ0KFfpF0wWzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFGxpeC5w > > b2x5dGVjaG5pcXVlLmZyMS0wKwYDVQQDEyRDQS1zY2VuaWMubGl4LnBvbHl0ZWNo > > bmlxdWUuZnIuMjA0MzOCAQEwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYD > > VR0lAQH/BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IB > > AQCJ8+WvqJhE+mBSk0986GJ4QPjHp+HDOLV9TFt6310bBSzKQ86iivb9Aj6Yb7zq > > pnj35HpPSQyGy7YjLreT8ei6dgUhAO3M8u4OF9whCiGezuG/tRHUpdMx3fTjx+pA > > JidFeZ8teZFBA2EmUTFU1QaQz9Sgi7eKsAK0NyQPsiaZqTl4SIobA4lkaN6ey/yZ > > 1kE9PdkVj/bvP7JRyN1gqMUpiCBpuYoj65tklM2t4vl8DteSz8t93TstZxMdwwpR > > KOe3RDb6Q4OAE1H/9xsiwIDFwYWQh6YXRkTciB8Wae4nRInAKypN+Ub8UPEsr6/B > > MO5vbLXN9edzmbD/NiyHMmYO > > -----END CERTIFICATE----- > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > Which version do you use? > > > > > > this should not happen... > > > > > > what is the output of: > > > > > > $ openssl x509 -in /etc/pki/ovirt-engine/certs/engine.cer -text > > > > > > ----- Original Message ----- > > > > From: "Florian BRUSCHET" > > > > To: "Alon Bar-Lev" > > > > Cc: "engine-devel" > > > > Sent: Wednesday, May 1, 2013 12:47:13 AM > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > Sure, > > > > > > > > 2013-04-30 23:44:35,984 ERROR > > > > [org.ovirt.engine.core.pki.PKIResourceServlet] > (ajp--127.0.0.1-8702-4) > > > > Cannot send public key resource > '/etc/pki/ovirt-engine/certs/engine.cer' > > > > format 'SSH': java.security.cert.CertificateParsingException: invalid > > > > DER-encoded certificate data > > > > at > sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1723) > > > > [rt.jar:1.6.0_24] > > > > at > sun.security.x509.X509CertImpl.(X509CertImpl.java:320) > > > > [rt.jar:1.6.0_24] > > > > at > > > > > > > > sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:121) > > > > [rt.jar:1.6.0_24] > > > > at > > > > > > > > java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:322) > > > > [rt.jar:1.6.0_24] > > > > at > > > > > > > > org.ovirt.engine.core.pki.PKIResourceServlet.doGet(PKIResourceServlet.java:83) > > > > [classes:] > > > > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:734) > > > > [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] > > > > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > > > > [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] > > > > at > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) > > > > [jbossweb-7.0.13.Final.jar:] > > > > at > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) > > > > [jbossweb-7.0.13.Final.jar:] > > > > at > > > > > > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) > > > > [jbossweb-7.0.13.Final.jar:] > > > > at > > > > > > > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) > > > > [jbossweb-7.0.13.Final.jar:] > > > > at > > > > > > > > org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) > > > > [jboss-as-web-7.1.1.Final.jar:7.1.1.Final] > > > > at > > > > > > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) > > > > [jbossweb-7.0.13.Final.jar:] > > > > at > > > > > > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > > > > [jbossweb-7.0.13.Final.jar:] > > > > at > > > org.jboss.web.rewrite.RewriteValve.invoke(RewriteValve.java:466) > > > > [jbossweb-7.0.13.Final.jar:] > > > > at > > > > > > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > > > > [jbossweb-7.0.13.Final.jar:] > > > > at > > > > > > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) > > > > [jbossweb-7.0.13.Final.jar:] > > > > at > > > > org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) > > > > [jbossweb-7.0.13.Final.jar:] > > > > at > > > > > > > > org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) > > > > [jbossweb-7.0.13.Final.jar:] > > > > at > > > > > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) > > > > [jbossweb-7.0.13.Final.jar:] > > > > at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24] > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > Can you please attach /var/log/ovirt-engine/engine.log? > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Florian BRUSCHET" > > > > > > To: "Alon Bar-Lev" > > > > > > Cc: "engine-devel" > > > > > > Sent: Wednesday, May 1, 2013 12:33:38 AM > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > Ok this what I have done, I see it, I specify the engine address, > > > then he > > > > > > ask me to "Retrieve Certificate" i do it, it works. After I > choose > > > "Save > > > > > & > > > > > > Register", i can see "Activating VDMS", and "All changes were > applied > > > > > > successfully". But nothing in the engine ... > > > > > > I tryed the other way but don't work too ... for this solution > i'm > > > nearly > > > > > > sure that it's cause the password is wrong, it isn't the one > which i > > > > > > specified in ovirt-node. > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > Please reply to 'all'. > > > > > > > > > > > > > > When you login as admin you should be presented with Text User > > > > > Interface. > > > > > > > Within this interface there should be options on the left and a > > > dialog > > > > > on > > > > > > > the right. > > > > > > > At the left you should see 'ovirt-engine' or similar option, > when > > > > > > > selecting it, you should see on the right an input field of > > > address of > > > > > the > > > > > > > ovirt-engine server, specifying the engine address and > selecting > > > apply > > > > > will > > > > > > > initiate registration into the engine. > > > > > > > > > > > > > > Once registered, you should see the host in the engine, select > it > > > and > > > > > > > click on "Approve". > > > > > > > > > > > > > > Another option is to specify password at the same dialog > without > > > > > filling > > > > > > > the engine address. This password may be used as the password > > > withi the > > > > > > > 'Add Host' dialog. > > > > > > > > > > > > > > Alon > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > Sent: Wednesday, May 1, 2013 12:00:01 AM > > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > I think I don't really understand what you call TUI? > > > > > > > > Yes I'm log as admin on ovirt-node to use Hypervisor > > > > > > > > > > > > > > > > (And sorry if I make some language faults English isn't my > native > > > > > > > language > > > > > > > > ^^) > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > > You cannot do this via agent by via the TUI of the > ovirt-node. > > > > > > > > > > > > > > > > > > Just to make sure, you are using ovirt-node as hypervisor, > > > right? > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > > Sent: Tuesday, April 30, 2013 11:47:53 PM > > > > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > > > Oh ok, i didn't know ... > > > > > > > > > > > > > > > > > > > > I was looking my oVirt Engine and i don't understand how > i > > > can > > > > > add an > > > > > > > > > Host > > > > > > > > > > without this password ... > > > > > > > > > > For me i have to right click on the Hosts panel, select > "new" > > > > > and it > > > > > > > asks > > > > > > > > > > me to give name, address and Root password. > > > > > > > > > > I have already register this Host from oVirt Node > > > Hypervisor, i > > > > > add > > > > > > > my > > > > > > > > > > Management Server and there is no problem i can see > > > "Certificate > > > > > > > Status : > > > > > > > > > > Verified" but this Host don't appears in the Web page ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > > > > Sent: Tuesday, April 30, 2013 11:06:14 PM > > > > > > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > > > > > > > For me single mode it's when you add "single" at the > end > > > of > > > > > the > > > > > > > > > kernel > > > > > > > > > > > > commande line like that you boot on shell commande as > > > > > > > > > > > > root at localhostand > > > > > > > > > > > > you can do what you want. > > > > > > > > > > > > > > > > > > > > > > Oh... this is "single user mode"... :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I will try it soon! > > > > > > > > > > > > > > > > > > > > > > > > Thank you > > > > > > > > > > > > > > > > > > > > > > > > Florian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > What is 'single mode'? > > > > > > > > > > > > > > > > > > > > > > > > > > You should be able to set root password via node > TUI, > > > at > > > > > ovirt > > > > > > > tab. > > > > > > > > > > > > > Or... you can simply perform registration via the > node > > > > > TUI, so > > > > > > > you > > > > > > > > > > > don't > > > > > > > > > > > > > need to specify password at all. > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Florian BRUSCHET" < > florian.bruschet at gmail.com > > > > > > > > > > > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > > > > > > > Sent: Tuesday, April 30, 2013 7:28:12 PM > > > > > > > > > > > > > > Subject: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I try to add Host from oVirt Engine Web > > > Administration, > > > > > but > > > > > > > it > > > > > > > > > asks > > > > > > > > > > > me to > > > > > > > > > > > > > > give a Root Password (It's not the same that i > used > > > to > > > > > log in > > > > > > > > > admin > > > > > > > > > > > on > > > > > > > > > > > > > the > > > > > > > > > > > > > > Node). > > > > > > > > > > > > > > Do i really need this Root Password? Because i > can't > > > > > have it > > > > > > > and > > > > > > > > > i > > > > > > > > > > > don't > > > > > > > > > > > > > want > > > > > > > > > > > > > > to change it by using single mode... > > > > > > > > > > > > > > There is an other solution to add Hosts? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Florian BRUSCHET > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > 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: From alonbl at redhat.com Tue Apr 30 22:04:24 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 30 Apr 2013 18:04:24 -0400 (EDT) Subject: [Engine-devel] Root password to add Host In-Reply-To: References: <65420993.3146107.1367357703748.JavaMail.root@redhat.com> <713180332.3148415.1367358544236.JavaMail.root@redhat.com> <2063948352.3149451.1367359145052.JavaMail.root@redhat.com> Message-ID: <788173516.3150077.1367359464809.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Florian BRUSCHET" > To: "Alon Bar-Lev" > Cc: "engine-devel" > Sent: Wednesday, May 1, 2013 1:00:55 AM > Subject: Re: [Engine-devel] Root password to add Host > > Oh sure, > > [root at scenic ~]# rpm -q ovirt-engine > ovirt-engine-3.1.0-3.26.3.el6.centos.alt.noarch Any reason not to use 3.2 ? Much has been changed since... >From what I gather, it is something to do with java... although the format of the certificate file is PEM it tries to read it as DER, first time I see this. > > > [root at scenic ~]# java -version > java version "1.7.0_19" > OpenJDK Runtime Environment (rhel-2.3.9.1.el6_4-x86_64) > OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) > > > > 2013/4/30 Alon Bar-Lev > > > > > > > ----- Original Message ----- > > > From: "Florian BRUSCHET" > > > To: "Alon Bar-Lev" > > > Cc: "engine-devel" > > > Sent: Wednesday, May 1, 2013 12:56:07 AM > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > I use oVirt 3.x, to install i follow this guide : > > > http://wiki.centos.org/HowTos/oVirt > > > > The x is quite important... > > rpm -q ovirt-engine > > > > Also, please send your java version: > > java -version > > > > > And ovirt-node version is 2.6.0 > > > > > > [root at scenic ~]# openssl x509 -in /etc/pki/ovirt-engine/certs/engine.cer > > > -text > > > Certificate: > > > Data: > > > Version: 3 (0x2) > > > Serial Number: 2 (0x2) > > > Signature Algorithm: sha1WithRSAEncryption > > > Issuer: C=US, O=lix.polytechnique.fr, > > > CN=CA-scenic.lix.polytechnique.fr.20433 > > > Validity > > > Not Before: Apr 29 15:11:10 2013 > > > Not After : Apr 4 15:11:12 2018 GMT > > > Subject: C=US, O=lix.polytechnique.fr, CN= > > > scenic.lix.polytechnique.fr > > > Subject Public Key Info: > > > Public Key Algorithm: rsaEncryption > > > Public-Key: (2048 bit) > > > Modulus: > > > 00:ce:7a:2e:c1:9a:86:2c:c2:76:5e:ea:8b:59:18: > > > 62:7d:7a:9f:55:ff:71:15:f7:93:3f:40:1e:70:5d: > > > 80:43:ea:c7:f4:50:0a:a6:47:2a:f8:07:4d:0c:0a: > > > 4d:01:1e:97:de:36:63:40:df:30:7a:40:9d:34:93: > > > d6:a8:43:c6:b3:62:c1:de:db:57:d1:fb:b9:c6:e2: > > > 34:65:f2:67:e1:8c:91:67:3f:99:a6:2b:7b:8a:51: > > > ad:9c:43:c3:a5:cd:c5:a2:29:e9:99:db:ba:f4:76: > > > d0:e5:41:97:31:fc:13:94:53:af:90:ca:06:aa:7d: > > > 68:04:62:66:a5:90:4b:11:de:07:34:ec:68:89:9c: > > > 13:7b:a2:ba:1f:2a:28:6b:ba:9a:b3:ba:97:5c:96: > > > cd:1e:2e:e7:fc:bf:20:a2:a5:57:f3:73:8d:12:db: > > > 81:00:53:50:a6:54:e9:14:1e:46:69:08:e2:80:b1: > > > 30:97:89:d3:a1:a2:7a:47:a3:c9:2e:c9:ce:14:74: > > > 92:27:02:58:41:d8:e1:dd:9e:99:26:fa:b0:ad:6c: > > > e0:11:3f:17:7d:f7:63:27:62:a3:d0:28:f3:1a:91: > > > ca:65:b7:69:9b:b6:86:85:70:a6:ac:5c:51:e2:ff: > > > e9:f2:28:78:24:21:28:0c:d0:95:a4:f8:e5:67:15: > > > d6:77 > > > Exponent: 65537 (0x10001) > > > X509v3 extensions: > > > X509v3 Subject Key Identifier: > > > > > 4A:E0:DF:6D:4D:AD:03:26:30:B5:D4:D4:DC:69:C5:DA:74:B2:66:AB > > > Authority Information Access: > > > CA Issuers - URI: > > > http://scenic.lix.polytechnique.fr:80/ca.crt > > > > > > X509v3 Authority Key Identifier: > > > > > > keyid:7E:D8:AE:56:25:C5:B0:34:96:5A:EA:AF:E9:2D:F3:E0:06:1C:19:D0 > > > DirName:/C=US/O= > > > lix.polytechnique.fr/CN=CA-scenic.lix.polytechnique.fr.20433 > > > serial:01 > > > > > > X509v3 Basic Constraints: > > > CA:FALSE > > > X509v3 Key Usage: critical > > > Digital Signature, Key Encipherment > > > X509v3 Extended Key Usage: critical > > > TLS Web Server Authentication, TLS Web Client > > Authentication > > > Signature Algorithm: sha1WithRSAEncryption > > > 89:f3:e5:af:a8:98:44:fa:60:52:93:4f:7c:e8:62:78:40:f8: > > > c7:a7:e1:c3:38:b5:7d:4c:5b:7a:df:5d:1b:05:2c:ca:43:ce: > > > a2:8a:f6:fd:02:3e:98:6f:bc:ea:a6:78:f7:e4:7a:4f:49:0c: > > > 86:cb:b6:23:2e:b7:93:f1:e8:ba:76:05:21:00:ed:cc:f2:ee: > > > 0e:17:dc:21:0a:21:9e:ce:e1:bf:b5:11:d4:a5:d3:31:dd:f4: > > > e3:c7:ea:40:26:27:45:79:9f:2d:79:91:41:03:61:26:51:31: > > > 54:d5:06:90:cf:d4:a0:8b:b7:8a:b0:02:b4:37:24:0f:b2:26: > > > 99:a9:39:78:48:8a:1b:03:89:64:68:de:9e:cb:fc:99:d6:41: > > > 3d:3d:d9:15:8f:f6:ef:3f:b2:51:c8:dd:60:a8:c5:29:88:20: > > > 69:b9:8a:23:eb:9b:64:94:cd:ad:e2:f9:7c:0e:d7:92:cf:cb: > > > 7d:dd:3b:2d:67:13:1d:c3:0a:51:28:e7:b7:44:36:fa:43:83: > > > 80:13:51:ff:f7:1b:22:c0:80:c5:c1:85:90:87:a6:17:46:44: > > > dc:88:1f:16:69:ee:27:44:89:c0:2b:2a:4d:f9:46:fc:50:f1: > > > 2c:af:af:c1:30:ee:6f:6c:b5:cd:f5:e7:73:99:b0:ff:36:2c: > > > 87:32:66:0e > > > -----BEGIN CERTIFICATE----- > > > MIIEXjCCA0agAwIBAgIBAjANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJVUzEd > > > MBsGA1UEChMUbGl4LnBvbHl0ZWNobmlxdWUuZnIxLTArBgNVBAMTJENBLXNjZW5p > > > Yy5saXgucG9seXRlY2huaXF1ZS5mci4yMDQzMzAiFxExMzA0MjkxNTExMTArMDAw > > > MBcNMTgwNDA0MTUxMTEyWjBSMQswCQYDVQQGEwJVUzEdMBsGA1UECgwUbGl4LnBv > > > bHl0ZWNobmlxdWUuZnIxJDAiBgNVBAMMG3NjZW5pYy5saXgucG9seXRlY2huaXF1 > > > ZS5mcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM56LsGahizCdl7q > > > i1kYYn16n1X/cRX3kz9AHnBdgEPqx/RQCqZHKvgHTQwKTQEel942Y0DfMHpAnTST > > > 1qhDxrNiwd7bV9H7ucbiNGXyZ+GMkWc/maYre4pRrZxDw6XNxaIp6ZnbuvR20OVB > > > lzH8E5RTr5DKBqp9aARiZqWQSxHeBzTsaImcE3uiuh8qKGu6mrO6l1yWzR4u5/y/ > > > IKKlV/NzjRLbgQBTUKZU6RQeRmkI4oCxMJeJ06GiekejyS7JzhR0kicCWEHY4d2e > > > mSb6sK1s4BE/F333Yydio9Ao8xqRymW3aZu2hoVwpqxcUeL/6fIoeCQhKAzQlaT4 > > > 5WcV1ncCAwEAAaOCATAwggEsMB0GA1UdDgQWBBRK4N9tTa0DJjC11NTcacXadLJm > > > qzBIBggrBgEFBQcBAQQ8MDowOAYIKwYBBQUHMAKGLGh0dHA6Ly9zY2VuaWMubGl4 > > > LnBvbHl0ZWNobmlxdWUuZnI6ODAvY2EuY3J0MIGDBgNVHSMEfDB6gBR+2K5WJcWw > > > NJZa6q/pLfPgBhwZ0KFfpF0wWzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFGxpeC5w > > > b2x5dGVjaG5pcXVlLmZyMS0wKwYDVQQDEyRDQS1zY2VuaWMubGl4LnBvbHl0ZWNo > > > bmlxdWUuZnIuMjA0MzOCAQEwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYD > > > VR0lAQH/BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IB > > > AQCJ8+WvqJhE+mBSk0986GJ4QPjHp+HDOLV9TFt6310bBSzKQ86iivb9Aj6Yb7zq > > > pnj35HpPSQyGy7YjLreT8ei6dgUhAO3M8u4OF9whCiGezuG/tRHUpdMx3fTjx+pA > > > JidFeZ8teZFBA2EmUTFU1QaQz9Sgi7eKsAK0NyQPsiaZqTl4SIobA4lkaN6ey/yZ > > > 1kE9PdkVj/bvP7JRyN1gqMUpiCBpuYoj65tklM2t4vl8DteSz8t93TstZxMdwwpR > > > KOe3RDb6Q4OAE1H/9xsiwIDFwYWQh6YXRkTciB8Wae4nRInAKypN+Ub8UPEsr6/B > > > MO5vbLXN9edzmbD/NiyHMmYO > > > -----END CERTIFICATE----- > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > Which version do you use? > > > > > > > > this should not happen... > > > > > > > > what is the output of: > > > > > > > > $ openssl x509 -in /etc/pki/ovirt-engine/certs/engine.cer -text > > > > > > > > ----- Original Message ----- > > > > > From: "Florian BRUSCHET" > > > > > To: "Alon Bar-Lev" > > > > > Cc: "engine-devel" > > > > > Sent: Wednesday, May 1, 2013 12:47:13 AM > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > Sure, > > > > > > > > > > 2013-04-30 23:44:35,984 ERROR > > > > > [org.ovirt.engine.core.pki.PKIResourceServlet] > > (ajp--127.0.0.1-8702-4) > > > > > Cannot send public key resource > > '/etc/pki/ovirt-engine/certs/engine.cer' > > > > > format 'SSH': java.security.cert.CertificateParsingException: invalid > > > > > DER-encoded certificate data > > > > > at > > sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1723) > > > > > [rt.jar:1.6.0_24] > > > > > at > > sun.security.x509.X509CertImpl.(X509CertImpl.java:320) > > > > > [rt.jar:1.6.0_24] > > > > > at > > > > > > > > > > > sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:121) > > > > > [rt.jar:1.6.0_24] > > > > > at > > > > > > > > > > > java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:322) > > > > > [rt.jar:1.6.0_24] > > > > > at > > > > > > > > > > > org.ovirt.engine.core.pki.PKIResourceServlet.doGet(PKIResourceServlet.java:83) > > > > > [classes:] > > > > > at > > javax.servlet.http.HttpServlet.service(HttpServlet.java:734) > > > > > [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] > > > > > at > > javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > > > > > [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] > > > > > at > > > > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > at > > > > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > at > > > > > > > > > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > at > > > > > > > > > > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > at > > > > > > > > > > > org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) > > > > > [jboss-as-web-7.1.1.Final.jar:7.1.1.Final] > > > > > at > > > > > > > > > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > at > > > > > > > > > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > at > > > > org.jboss.web.rewrite.RewriteValve.invoke(RewriteValve.java:466) > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > at > > > > > > > > > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > at > > > > > > > > > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > at > > > > > org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > at > > > > > > > > > > > org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > at > > > > > > > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24] > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > Can you please attach /var/log/ovirt-engine/engine.log? > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Florian BRUSCHET" > > > > > > > To: "Alon Bar-Lev" > > > > > > > Cc: "engine-devel" > > > > > > > Sent: Wednesday, May 1, 2013 12:33:38 AM > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > Ok this what I have done, I see it, I specify the engine address, > > > > then he > > > > > > > ask me to "Retrieve Certificate" i do it, it works. After I > > choose > > > > "Save > > > > > > & > > > > > > > Register", i can see "Activating VDMS", and "All changes were > > applied > > > > > > > successfully". But nothing in the engine ... > > > > > > > I tryed the other way but don't work too ... for this solution > > i'm > > > > nearly > > > > > > > sure that it's cause the password is wrong, it isn't the one > > which i > > > > > > > specified in ovirt-node. > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > Please reply to 'all'. > > > > > > > > > > > > > > > > When you login as admin you should be presented with Text User > > > > > > Interface. > > > > > > > > Within this interface there should be options on the left and a > > > > dialog > > > > > > on > > > > > > > > the right. > > > > > > > > At the left you should see 'ovirt-engine' or similar option, > > when > > > > > > > > selecting it, you should see on the right an input field of > > > > address of > > > > > > the > > > > > > > > ovirt-engine server, specifying the engine address and > > selecting > > > > apply > > > > > > will > > > > > > > > initiate registration into the engine. > > > > > > > > > > > > > > > > Once registered, you should see the host in the engine, select > > it > > > > and > > > > > > > > click on "Approve". > > > > > > > > > > > > > > > > Another option is to specify password at the same dialog > > without > > > > > > filling > > > > > > > > the engine address. This password may be used as the password > > > > withi the > > > > > > > > 'Add Host' dialog. > > > > > > > > > > > > > > > > Alon > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > Sent: Wednesday, May 1, 2013 12:00:01 AM > > > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > I think I don't really understand what you call TUI? > > > > > > > > > Yes I'm log as admin on ovirt-node to use Hypervisor > > > > > > > > > > > > > > > > > > (And sorry if I make some language faults English isn't my > > native > > > > > > > > language > > > > > > > > > ^^) > > > > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You cannot do this via agent by via the TUI of the > > ovirt-node. > > > > > > > > > > > > > > > > > > > > Just to make sure, you are using ovirt-node as hypervisor, > > > > right? > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > > > Sent: Tuesday, April 30, 2013 11:47:53 PM > > > > > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > > > > > Oh ok, i didn't know ... > > > > > > > > > > > > > > > > > > > > > > I was looking my oVirt Engine and i don't understand how > > i > > > > can > > > > > > add an > > > > > > > > > > Host > > > > > > > > > > > without this password ... > > > > > > > > > > > For me i have to right click on the Hosts panel, select > > "new" > > > > > > and it > > > > > > > > asks > > > > > > > > > > > me to give name, address and Root password. > > > > > > > > > > > I have already register this Host from oVirt Node > > > > Hypervisor, i > > > > > > add > > > > > > > > my > > > > > > > > > > > Management Server and there is no problem i can see > > > > "Certificate > > > > > > > > Status : > > > > > > > > > > > Verified" but this Host don't appears in the Web page ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > > > > > Sent: Tuesday, April 30, 2013 11:06:14 PM > > > > > > > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > > > > > > > > > For me single mode it's when you add "single" at the > > end > > > > of > > > > > > the > > > > > > > > > > kernel > > > > > > > > > > > > > commande line like that you boot on shell commande as > > > > > > > > > > > > > root at localhostand > > > > > > > > > > > > > you can do what you want. > > > > > > > > > > > > > > > > > > > > > > > > Oh... this is "single user mode"... :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I will try it soon! > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you > > > > > > > > > > > > > > > > > > > > > > > > > > Florian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > > > What is 'single mode'? > > > > > > > > > > > > > > > > > > > > > > > > > > > > You should be able to set root password via node > > TUI, > > > > at > > > > > > ovirt > > > > > > > > tab. > > > > > > > > > > > > > > Or... you can simply perform registration via the > > node > > > > > > TUI, so > > > > > > > > you > > > > > > > > > > > > don't > > > > > > > > > > > > > > need to specify password at all. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > From: "Florian BRUSCHET" < > > florian.bruschet at gmail.com > > > > > > > > > > > > > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > > > > > > > > Sent: Tuesday, April 30, 2013 7:28:12 PM > > > > > > > > > > > > > > > Subject: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I try to add Host from oVirt Engine Web > > > > Administration, > > > > > > but > > > > > > > > it > > > > > > > > > > asks > > > > > > > > > > > > me to > > > > > > > > > > > > > > > give a Root Password (It's not the same that i > > used > > > > to > > > > > > log in > > > > > > > > > > admin > > > > > > > > > > > > on > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > Node). > > > > > > > > > > > > > > > Do i really need this Root Password? Because i > > can't > > > > > > have it > > > > > > > > and > > > > > > > > > > i > > > > > > > > > > > > don't > > > > > > > > > > > > > > want > > > > > > > > > > > > > > > to change it by using single mode... > > > > > > > > > > > > > > > There is an other solution to add Hosts? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Florian BRUSCHET > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > Engine-devel mailing list > > > > > > > > > > > > > > > Engine-devel at ovirt.org > > > > > > > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From florian.bruschet at gmail.com Tue Apr 30 22:14:36 2013 From: florian.bruschet at gmail.com (Florian BRUSCHET) Date: Wed, 1 May 2013 00:14:36 +0200 Subject: [Engine-devel] Root password to add Host In-Reply-To: <788173516.3150077.1367359464809.JavaMail.root@redhat.com> References: <65420993.3146107.1367357703748.JavaMail.root@redhat.com> <713180332.3148415.1367358544236.JavaMail.root@redhat.com> <2063948352.3149451.1367359145052.JavaMail.root@redhat.com> <788173516.3150077.1367359464809.JavaMail.root@redhat.com> Message-ID: No, there is no reason. I think I will tryed to reinstall with 3.2 Really strange I agree ... 2013/5/1 Alon Bar-Lev > > > ----- Original Message ----- > > From: "Florian BRUSCHET" > > To: "Alon Bar-Lev" > > Cc: "engine-devel" > > Sent: Wednesday, May 1, 2013 1:00:55 AM > > Subject: Re: [Engine-devel] Root password to add Host > > > > Oh sure, > > > > [root at scenic ~]# rpm -q ovirt-engine > > ovirt-engine-3.1.0-3.26.3.el6.centos.alt.noarch > > Any reason not to use 3.2 ? Much has been changed since... > From what I gather, it is something to do with java... although the format > of the certificate file is PEM it tries to read it as DER, first time I see > this. > > > > > > > [root at scenic ~]# java -version > > java version "1.7.0_19" > > OpenJDK Runtime Environment (rhel-2.3.9.1.el6_4-x86_64) > > OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > ----- Original Message ----- > > > > From: "Florian BRUSCHET" > > > > To: "Alon Bar-Lev" > > > > Cc: "engine-devel" > > > > Sent: Wednesday, May 1, 2013 12:56:07 AM > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > I use oVirt 3.x, to install i follow this guide : > > > > http://wiki.centos.org/HowTos/oVirt > > > > > > The x is quite important... > > > rpm -q ovirt-engine > > > > > > Also, please send your java version: > > > java -version > > > > > > > And ovirt-node version is 2.6.0 > > > > > > > > [root at scenic ~]# openssl x509 -in > /etc/pki/ovirt-engine/certs/engine.cer > > > > -text > > > > Certificate: > > > > Data: > > > > Version: 3 (0x2) > > > > Serial Number: 2 (0x2) > > > > Signature Algorithm: sha1WithRSAEncryption > > > > Issuer: C=US, O=lix.polytechnique.fr, > > > > CN=CA-scenic.lix.polytechnique.fr.20433 > > > > Validity > > > > Not Before: Apr 29 15:11:10 2013 > > > > Not After : Apr 4 15:11:12 2018 GMT > > > > Subject: C=US, O=lix.polytechnique.fr, CN= > > > > scenic.lix.polytechnique.fr > > > > Subject Public Key Info: > > > > Public Key Algorithm: rsaEncryption > > > > Public-Key: (2048 bit) > > > > Modulus: > > > > 00:ce:7a:2e:c1:9a:86:2c:c2:76:5e:ea:8b:59:18: > > > > 62:7d:7a:9f:55:ff:71:15:f7:93:3f:40:1e:70:5d: > > > > 80:43:ea:c7:f4:50:0a:a6:47:2a:f8:07:4d:0c:0a: > > > > 4d:01:1e:97:de:36:63:40:df:30:7a:40:9d:34:93: > > > > d6:a8:43:c6:b3:62:c1:de:db:57:d1:fb:b9:c6:e2: > > > > 34:65:f2:67:e1:8c:91:67:3f:99:a6:2b:7b:8a:51: > > > > ad:9c:43:c3:a5:cd:c5:a2:29:e9:99:db:ba:f4:76: > > > > d0:e5:41:97:31:fc:13:94:53:af:90:ca:06:aa:7d: > > > > 68:04:62:66:a5:90:4b:11:de:07:34:ec:68:89:9c: > > > > 13:7b:a2:ba:1f:2a:28:6b:ba:9a:b3:ba:97:5c:96: > > > > cd:1e:2e:e7:fc:bf:20:a2:a5:57:f3:73:8d:12:db: > > > > 81:00:53:50:a6:54:e9:14:1e:46:69:08:e2:80:b1: > > > > 30:97:89:d3:a1:a2:7a:47:a3:c9:2e:c9:ce:14:74: > > > > 92:27:02:58:41:d8:e1:dd:9e:99:26:fa:b0:ad:6c: > > > > e0:11:3f:17:7d:f7:63:27:62:a3:d0:28:f3:1a:91: > > > > ca:65:b7:69:9b:b6:86:85:70:a6:ac:5c:51:e2:ff: > > > > e9:f2:28:78:24:21:28:0c:d0:95:a4:f8:e5:67:15: > > > > d6:77 > > > > Exponent: 65537 (0x10001) > > > > X509v3 extensions: > > > > X509v3 Subject Key Identifier: > > > > > > > 4A:E0:DF:6D:4D:AD:03:26:30:B5:D4:D4:DC:69:C5:DA:74:B2:66:AB > > > > Authority Information Access: > > > > CA Issuers - URI: > > > > http://scenic.lix.polytechnique.fr:80/ca.crt > > > > > > > > X509v3 Authority Key Identifier: > > > > > > > > keyid:7E:D8:AE:56:25:C5:B0:34:96:5A:EA:AF:E9:2D:F3:E0:06:1C:19:D0 > > > > DirName:/C=US/O= > > > > lix.polytechnique.fr/CN=CA-scenic.lix.polytechnique.fr.20433 > > > > serial:01 > > > > > > > > X509v3 Basic Constraints: > > > > CA:FALSE > > > > X509v3 Key Usage: critical > > > > Digital Signature, Key Encipherment > > > > X509v3 Extended Key Usage: critical > > > > TLS Web Server Authentication, TLS Web Client > > > Authentication > > > > Signature Algorithm: sha1WithRSAEncryption > > > > 89:f3:e5:af:a8:98:44:fa:60:52:93:4f:7c:e8:62:78:40:f8: > > > > c7:a7:e1:c3:38:b5:7d:4c:5b:7a:df:5d:1b:05:2c:ca:43:ce: > > > > a2:8a:f6:fd:02:3e:98:6f:bc:ea:a6:78:f7:e4:7a:4f:49:0c: > > > > 86:cb:b6:23:2e:b7:93:f1:e8:ba:76:05:21:00:ed:cc:f2:ee: > > > > 0e:17:dc:21:0a:21:9e:ce:e1:bf:b5:11:d4:a5:d3:31:dd:f4: > > > > e3:c7:ea:40:26:27:45:79:9f:2d:79:91:41:03:61:26:51:31: > > > > 54:d5:06:90:cf:d4:a0:8b:b7:8a:b0:02:b4:37:24:0f:b2:26: > > > > 99:a9:39:78:48:8a:1b:03:89:64:68:de:9e:cb:fc:99:d6:41: > > > > 3d:3d:d9:15:8f:f6:ef:3f:b2:51:c8:dd:60:a8:c5:29:88:20: > > > > 69:b9:8a:23:eb:9b:64:94:cd:ad:e2:f9:7c:0e:d7:92:cf:cb: > > > > 7d:dd:3b:2d:67:13:1d:c3:0a:51:28:e7:b7:44:36:fa:43:83: > > > > 80:13:51:ff:f7:1b:22:c0:80:c5:c1:85:90:87:a6:17:46:44: > > > > dc:88:1f:16:69:ee:27:44:89:c0:2b:2a:4d:f9:46:fc:50:f1: > > > > 2c:af:af:c1:30:ee:6f:6c:b5:cd:f5:e7:73:99:b0:ff:36:2c: > > > > 87:32:66:0e > > > > -----BEGIN CERTIFICATE----- > > > > MIIEXjCCA0agAwIBAgIBAjANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJVUzEd > > > > MBsGA1UEChMUbGl4LnBvbHl0ZWNobmlxdWUuZnIxLTArBgNVBAMTJENBLXNjZW5p > > > > Yy5saXgucG9seXRlY2huaXF1ZS5mci4yMDQzMzAiFxExMzA0MjkxNTExMTArMDAw > > > > MBcNMTgwNDA0MTUxMTEyWjBSMQswCQYDVQQGEwJVUzEdMBsGA1UECgwUbGl4LnBv > > > > bHl0ZWNobmlxdWUuZnIxJDAiBgNVBAMMG3NjZW5pYy5saXgucG9seXRlY2huaXF1 > > > > ZS5mcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM56LsGahizCdl7q > > > > i1kYYn16n1X/cRX3kz9AHnBdgEPqx/RQCqZHKvgHTQwKTQEel942Y0DfMHpAnTST > > > > 1qhDxrNiwd7bV9H7ucbiNGXyZ+GMkWc/maYre4pRrZxDw6XNxaIp6ZnbuvR20OVB > > > > lzH8E5RTr5DKBqp9aARiZqWQSxHeBzTsaImcE3uiuh8qKGu6mrO6l1yWzR4u5/y/ > > > > IKKlV/NzjRLbgQBTUKZU6RQeRmkI4oCxMJeJ06GiekejyS7JzhR0kicCWEHY4d2e > > > > mSb6sK1s4BE/F333Yydio9Ao8xqRymW3aZu2hoVwpqxcUeL/6fIoeCQhKAzQlaT4 > > > > 5WcV1ncCAwEAAaOCATAwggEsMB0GA1UdDgQWBBRK4N9tTa0DJjC11NTcacXadLJm > > > > qzBIBggrBgEFBQcBAQQ8MDowOAYIKwYBBQUHMAKGLGh0dHA6Ly9zY2VuaWMubGl4 > > > > LnBvbHl0ZWNobmlxdWUuZnI6ODAvY2EuY3J0MIGDBgNVHSMEfDB6gBR+2K5WJcWw > > > > NJZa6q/pLfPgBhwZ0KFfpF0wWzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFGxpeC5w > > > > b2x5dGVjaG5pcXVlLmZyMS0wKwYDVQQDEyRDQS1zY2VuaWMubGl4LnBvbHl0ZWNo > > > > bmlxdWUuZnIuMjA0MzOCAQEwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYD > > > > VR0lAQH/BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUAA4IB > > > > AQCJ8+WvqJhE+mBSk0986GJ4QPjHp+HDOLV9TFt6310bBSzKQ86iivb9Aj6Yb7zq > > > > pnj35HpPSQyGy7YjLreT8ei6dgUhAO3M8u4OF9whCiGezuG/tRHUpdMx3fTjx+pA > > > > JidFeZ8teZFBA2EmUTFU1QaQz9Sgi7eKsAK0NyQPsiaZqTl4SIobA4lkaN6ey/yZ > > > > 1kE9PdkVj/bvP7JRyN1gqMUpiCBpuYoj65tklM2t4vl8DteSz8t93TstZxMdwwpR > > > > KOe3RDb6Q4OAE1H/9xsiwIDFwYWQh6YXRkTciB8Wae4nRInAKypN+Ub8UPEsr6/B > > > > MO5vbLXN9edzmbD/NiyHMmYO > > > > -----END CERTIFICATE----- > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > Which version do you use? > > > > > > > > > > this should not happen... > > > > > > > > > > what is the output of: > > > > > > > > > > $ openssl x509 -in /etc/pki/ovirt-engine/certs/engine.cer -text > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Florian BRUSCHET" > > > > > > To: "Alon Bar-Lev" > > > > > > Cc: "engine-devel" > > > > > > Sent: Wednesday, May 1, 2013 12:47:13 AM > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > Sure, > > > > > > > > > > > > 2013-04-30 23:44:35,984 ERROR > > > > > > [org.ovirt.engine.core.pki.PKIResourceServlet] > > > (ajp--127.0.0.1-8702-4) > > > > > > Cannot send public key resource > > > '/etc/pki/ovirt-engine/certs/engine.cer' > > > > > > format 'SSH': java.security.cert.CertificateParsingException: > invalid > > > > > > DER-encoded certificate data > > > > > > at > > > sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1723) > > > > > > [rt.jar:1.6.0_24] > > > > > > at > > > sun.security.x509.X509CertImpl.(X509CertImpl.java:320) > > > > > > [rt.jar:1.6.0_24] > > > > > > at > > > > > > > > > > > > > > > sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:121) > > > > > > [rt.jar:1.6.0_24] > > > > > > at > > > > > > > > > > > > > > > java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:322) > > > > > > [rt.jar:1.6.0_24] > > > > > > at > > > > > > > > > > > > > > > org.ovirt.engine.core.pki.PKIResourceServlet.doGet(PKIResourceServlet.java:83) > > > > > > [classes:] > > > > > > at > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:734) > > > > > > [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] > > > > > > at > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > > > > > > [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) > > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) > > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) > > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) > > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > > at > > > > > > > > > > > > > > > org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) > > > > > > [jboss-as-web-7.1.1.Final.jar:7.1.1.Final] > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) > > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > > at > > > > > org.jboss.web.rewrite.RewriteValve.invoke(RewriteValve.java:466) > > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) > > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > > at > > > > > > org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) > > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > > at > > > > > > > > > > > > > > > org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) > > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > > at > > > > > > > > > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) > > > > > > [jbossweb-7.0.13.Final.jar:] > > > > > > at java.lang.Thread.run(Thread.java:679) > [rt.jar:1.6.0_24] > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > Can you please attach /var/log/ovirt-engine/engine.log? > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > Cc: "engine-devel" > > > > > > > > Sent: Wednesday, May 1, 2013 12:33:38 AM > > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > Ok this what I have done, I see it, I specify the engine > address, > > > > > then he > > > > > > > > ask me to "Retrieve Certificate" i do it, it works. After I > > > choose > > > > > "Save > > > > > > > & > > > > > > > > Register", i can see "Activating VDMS", and "All changes were > > > applied > > > > > > > > successfully". But nothing in the engine ... > > > > > > > > I tryed the other way but don't work too ... for this > solution > > > i'm > > > > > nearly > > > > > > > > sure that it's cause the password is wrong, it isn't the one > > > which i > > > > > > > > specified in ovirt-node. > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > > Please reply to 'all'. > > > > > > > > > > > > > > > > > > When you login as admin you should be presented with Text > User > > > > > > > Interface. > > > > > > > > > Within this interface there should be options on the left > and a > > > > > dialog > > > > > > > on > > > > > > > > > the right. > > > > > > > > > At the left you should see 'ovirt-engine' or similar > option, > > > when > > > > > > > > > selecting it, you should see on the right an input field of > > > > > address of > > > > > > > the > > > > > > > > > ovirt-engine server, specifying the engine address and > > > selecting > > > > > apply > > > > > > > will > > > > > > > > > initiate registration into the engine. > > > > > > > > > > > > > > > > > > Once registered, you should see the host in the engine, > select > > > it > > > > > and > > > > > > > > > click on "Approve". > > > > > > > > > > > > > > > > > > Another option is to specify password at the same dialog > > > without > > > > > > > filling > > > > > > > > > the engine address. This password may be used as the > password > > > > > withi the > > > > > > > > > 'Add Host' dialog. > > > > > > > > > > > > > > > > > > Alon > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > > Sent: Wednesday, May 1, 2013 12:00:01 AM > > > > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > > > I think I don't really understand what you call TUI? > > > > > > > > > > Yes I'm log as admin on ovirt-node to use Hypervisor > > > > > > > > > > > > > > > > > > > > (And sorry if I make some language faults English isn't > my > > > native > > > > > > > > > language > > > > > > > > > > ^^) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You cannot do this via agent by via the TUI of the > > > ovirt-node. > > > > > > > > > > > > > > > > > > > > > > Just to make sure, you are using ovirt-node as > hypervisor, > > > > > right? > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Florian BRUSCHET" > > > > > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > > > > Sent: Tuesday, April 30, 2013 11:47:53 PM > > > > > > > > > > > > Subject: Re: [Engine-devel] Root password to add Host > > > > > > > > > > > > > > > > > > > > > > > > Oh ok, i didn't know ... > > > > > > > > > > > > > > > > > > > > > > > > I was looking my oVirt Engine and i don't understand > how > > > i > > > > > can > > > > > > > add an > > > > > > > > > > > Host > > > > > > > > > > > > without this password ... > > > > > > > > > > > > For me i have to right click on the Hosts panel, > select > > > "new" > > > > > > > and it > > > > > > > > > asks > > > > > > > > > > > > me to give name, address and Root password. > > > > > > > > > > > > I have already register this Host from oVirt Node > > > > > Hypervisor, i > > > > > > > add > > > > > > > > > my > > > > > > > > > > > > Management Server and there is no problem i can see > > > > > "Certificate > > > > > > > > > Status : > > > > > > > > > > > > Verified" but this Host don't appears in the Web > page ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Florian BRUSCHET" < > florian.bruschet at gmail.com > > > > > > > > > > > > > > > > > > To: "Alon Bar-Lev" > > > > > > > > > > > > > > Sent: Tuesday, April 30, 2013 11:06:14 PM > > > > > > > > > > > > > > Subject: Re: [Engine-devel] Root password to add > Host > > > > > > > > > > > > > > > > > > > > > > > > > > > > For me single mode it's when you add "single" at > the > > > end > > > > > of > > > > > > > the > > > > > > > > > > > kernel > > > > > > > > > > > > > > commande line like that you boot on shell > commande as > > > > > > > > > > > > > > root at localhostand > > > > > > > > > > > > > > you can do what you want. > > > > > > > > > > > > > > > > > > > > > > > > > > Oh... this is "single user mode"... :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I will try it soon! > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you > > > > > > > > > > > > > > > > > > > > > > > > > > > > Florian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2013/4/30 Alon Bar-Lev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What is 'single mode'? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You should be able to set root password via > node > > > TUI, > > > > > at > > > > > > > ovirt > > > > > > > > > tab. > > > > > > > > > > > > > > > Or... you can simply perform registration via > the > > > node > > > > > > > TUI, so > > > > > > > > > you > > > > > > > > > > > > > don't > > > > > > > > > > > > > > > need to specify password at all. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > From: "Florian BRUSCHET" < > > > florian.bruschet at gmail.com > > > > > > > > > > > > > > > > > > > > > > To: engine-devel at ovirt.org > > > > > > > > > > > > > > > > Sent: Tuesday, April 30, 2013 7:28:12 PM > > > > > > > > > > > > > > > > Subject: [Engine-devel] Root password to add > Host > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I try to add Host from oVirt Engine Web > > > > > Administration, > > > > > > > but > > > > > > > > > it > > > > > > > > > > > asks > > > > > > > > > > > > > me to > > > > > > > > > > > > > > > > give a Root Password (It's not the same that > i > > > used > > > > > to > > > > > > > log in > > > > > > > > > > > admin > > > > > > > > > > > > > on > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > Node). > > > > > > > > > > > > > > > > Do i really need this Root Password? Because > i > > > can't > > > > > > > have it > > > > > > > > > and > > > > > > > > > > > i > > > > > > > > > > > > > don't > > > > > > > > > > > > > > > want > > > > > > > > > > > > > > > > to change it by using single mode... > > > > > > > > > > > > > > > > There is an other solution to add Hosts? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Florian BRUSCHET > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > 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: