You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafodion.apache.org by Roberta Marton <ro...@esgyn.com> on 2018/09/05 00:13:15 UTC
Trafodion 2.3 check list
I think we should document the list of tests we should run on Trafodion before we officially release the product.
This will help the release manager and the voters to make better decisions about the product.
When someone wants to validate the release, they can choose one or more tests.
Here is a list that I have thought about, feel free to add your own comments:
Identify the latest versions of Hortonworks, Cloudera, and Java we support.
Create a set of predefined tests to run for EsgynDB and native Hive objects. Nothing too big just basic DML and DDL requests.
* Verify that the signatures on all deliverables are good
* Perform the following tests on both Hortonworks and Cloudera platforms using the identified versions:
o Install the binaries using Python and Ambari installers and run set of predefined tests
o Build the source, build the binaries, install the binaries using Python and Ambari installers, and run some predefined tests
* Rerun the previous bullet with security features enabled (Kerberos & LDAP)
* Make sure installations work on single node and multi-node clusters.
* Build the clients and make sure they work on both Hortonworks and Cloudera
Roberta
RE: Trafodion 2.3 check list
Posted by Sandhya Sundaresan <sa...@esgyn.com>.
+1
Yes for the past couple years we've been doing this, it seems like the testing and initiating of fixes has been completely the Release Managers job.
I did delegate some client side testing for the various drivers we support and multi-node testing when I was in that role prior to sending out the vote. And it worked well. So I agree, delegating before the vote is even initiated is the way to go if the release manager does not have the bandwidth to do it all.
Thanks
Sandhya
-----Original Message-----
From: Steve Varnau <st...@esgyn.com>
Sent: Wednesday, September 5, 2018 9:41 AM
To: dev@trafodion.apache.org
Subject: RE: Trafodion 2.3 check list
Agree with Hans. When we create a release branch, then we should do a round of release testing. Many hands make light work.
--Steve
> -----Original Message-----
> From: Hans Zeller <ha...@esgyn.com>
> Sent: Wednesday, September 5, 2018 8:13 AM
> To: dev@trafodion.apache.org
> Subject: RE: Trafodion 2.3 check list
>
> +1
>
> What we do right now is to run some critical tests for the first time
> during the voting phase, which makes that process very inefficient.
>
> I wonder how we could make sure those tests are run before the vote starts.
> Maybe we should find volunteers to run them before the release and
> then just do a final check during the voting phase?
>
> Hans
>
> -----Original Message-----
> From: Roberta Marton <ro...@esgyn.com>
> Sent: Tuesday, September 4, 2018 5:13 PM
> To: dev@trafodion.apache.org
> Subject: Trafodion 2.3 check list
>
> I think we should document the list of tests we should run on
> Trafodion before we officially release the product.
> This will help the release manager and the voters to make better
> decisions about the product.
> When someone wants to validate the release, they can choose one or
> more tests.
> Here is a list that I have thought about, feel free to add your own comments:
>
> Identify the latest versions of Hortonworks, Cloudera, and Java we support.
> Create a set of predefined tests to run for EsgynDB and native Hive objects.
> Nothing too big just basic DML and DDL requests.
>
>
> * Verify that the signatures on all deliverables are good
>
> * Perform the following tests on both Hortonworks and Cloudera
> platforms using the identified versions:
>
> o Install the binaries using Python and Ambari installers and run set of
> predefined tests
>
> o Build the source, build the binaries, install the binaries using Python and
> Ambari installers, and run some predefined tests
>
> * Rerun the previous bullet with security features enabled (Kerberos &
> LDAP)
>
> * Make sure installations work on single node and multi-node clusters.
>
> * Build the clients and make sure they work on both Hortonworks and
> Cloudera
>
> Roberta
RE: Trafodion 2.3 check list
Posted by Steve Varnau <st...@esgyn.com>.
Agree with Hans. When we create a release branch, then we should do a round of release testing. Many hands make light work.
--Steve
> -----Original Message-----
> From: Hans Zeller <ha...@esgyn.com>
> Sent: Wednesday, September 5, 2018 8:13 AM
> To: dev@trafodion.apache.org
> Subject: RE: Trafodion 2.3 check list
>
> +1
>
> What we do right now is to run some critical tests for the first time during the
> voting phase, which makes that process very inefficient.
>
> I wonder how we could make sure those tests are run before the vote starts.
> Maybe we should find volunteers to run them before the release and then
> just do a final check during the voting phase?
>
> Hans
>
> -----Original Message-----
> From: Roberta Marton <ro...@esgyn.com>
> Sent: Tuesday, September 4, 2018 5:13 PM
> To: dev@trafodion.apache.org
> Subject: Trafodion 2.3 check list
>
> I think we should document the list of tests we should run on Trafodion
> before we officially release the product.
> This will help the release manager and the voters to make better decisions
> about the product.
> When someone wants to validate the release, they can choose one or more
> tests.
> Here is a list that I have thought about, feel free to add your own comments:
>
> Identify the latest versions of Hortonworks, Cloudera, and Java we support.
> Create a set of predefined tests to run for EsgynDB and native Hive objects.
> Nothing too big just basic DML and DDL requests.
>
>
> * Verify that the signatures on all deliverables are good
>
> * Perform the following tests on both Hortonworks and Cloudera
> platforms using the identified versions:
>
> o Install the binaries using Python and Ambari installers and run set of
> predefined tests
>
> o Build the source, build the binaries, install the binaries using Python and
> Ambari installers, and run some predefined tests
>
> * Rerun the previous bullet with security features enabled (Kerberos &
> LDAP)
>
> * Make sure installations work on single node and multi-node clusters.
>
> * Build the clients and make sure they work on both Hortonworks and
> Cloudera
>
> Roberta
RE: Trafodion 2.3 check list
Posted by Hans Zeller <ha...@esgyn.com>.
+1
What we do right now is to run some critical tests for the first time during the voting phase, which makes that process very inefficient.
I wonder how we could make sure those tests are run before the vote starts. Maybe we should find volunteers to run them before the release and then just do a final check during the voting phase?
Hans
-----Original Message-----
From: Roberta Marton <ro...@esgyn.com>
Sent: Tuesday, September 4, 2018 5:13 PM
To: dev@trafodion.apache.org
Subject: Trafodion 2.3 check list
I think we should document the list of tests we should run on Trafodion before we officially release the product.
This will help the release manager and the voters to make better decisions about the product.
When someone wants to validate the release, they can choose one or more tests.
Here is a list that I have thought about, feel free to add your own comments:
Identify the latest versions of Hortonworks, Cloudera, and Java we support.
Create a set of predefined tests to run for EsgynDB and native Hive objects. Nothing too big just basic DML and DDL requests.
* Verify that the signatures on all deliverables are good
* Perform the following tests on both Hortonworks and Cloudera platforms using the identified versions:
o Install the binaries using Python and Ambari installers and run set of predefined tests
o Build the source, build the binaries, install the binaries using Python and Ambari installers, and run some predefined tests
* Rerun the previous bullet with security features enabled (Kerberos & LDAP)
* Make sure installations work on single node and multi-node clusters.
* Build the clients and make sure they work on both Hortonworks and Cloudera
Roberta
RE: Trafodion 2.3 check list
Posted by Sean Broeder <se...@esgyn.com>.
Hi Roberta,
I think this is a good starting point expect for the EsgynDB related requirements.
My assumption, perhaps naively, is that unless there is a new release driver or completed JIRA in the release that the dependent software components or release distribution would remain the same as the previous release. It seems like trying to determine which distro, compiler, or java version should be supported during the vote is inefficient and problematic. It would be helpful to have these issues determined and documented well before the vote, so I like your idea of a checklist that could be modified or updated based on the release content.
Thanks,
Sean
-----Original Message-----
From: Roberta Marton <ro...@esgyn.com>
Sent: Tuesday, September 4, 2018 5:13 PM
To: dev@trafodion.apache.org
Subject: Trafodion 2.3 check list
I think we should document the list of tests we should run on Trafodion before we officially release the product.
This will help the release manager and the voters to make better decisions about the product.
When someone wants to validate the release, they can choose one or more tests.
Here is a list that I have thought about, feel free to add your own comments:
Identify the latest versions of Hortonworks, Cloudera, and Java we support.
Create a set of predefined tests to run for EsgynDB and native Hive objects. Nothing too big just basic DML and DDL requests.
* Verify that the signatures on all deliverables are good
* Perform the following tests on both Hortonworks and Cloudera platforms using the identified versions:
o Install the binaries using Python and Ambari installers and run set of predefined tests
o Build the source, build the binaries, install the binaries using Python and Ambari installers, and run some predefined tests
* Rerun the previous bullet with security features enabled (Kerberos & LDAP)
* Make sure installations work on single node and multi-node clusters.
* Build the clients and make sure they work on both Hortonworks and Cloudera
Roberta