Default format for new DB in output reverted to ORA #2172

ggovi · 2014-01-25T10:23:09Z

The auto-generation of Condition DB schemas is reverted to construct by default the old layout (ORA). In order to generate output with the new format, the environment variable NEW_CONDDB has to be set.
Additional fixes concern:

test for fronTier
MetadataService error policy for non-existing tags

Packages involved:
CondCore/CondDB
CondCore/IOVService
CondCore/MetaDataService
CondCore/Utilities

cmsbuild · 2014-01-25T10:28:03Z

A new Pull Request was created by @ggovi for CMSSW_7_0_X.

Default format for new DB in output reverted to ORA

It involves the following packages:

CondCore/CondDB
CondCore/IOVService
CondCore/MetaDataService
CondCore/Utilities

@apfeiffer1, @diguida, @cmsbuild, @nclopezo, @rcastello, @ggovi, @Degano can you please review it and eventually sign? Thanks.
@ghellwig this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
@ktf you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

diguida · 2014-01-25T10:42:44Z

This was discussed yesterday. The CSA14 calibrations will be produced in 70X, but the new format will be deployed only after the DIGI-RECO campaign will be over. As a consequence, the calibrations should be produced in 70X by default in the old format. 71X is supposed to have the new system as default, since it will be used for validating it. Hence, please do not propagate this PR in 71X: it is intended only for 70X.

ggovi · 2014-01-25T22:51:34Z

Salvatore, thanks for the clarification. However, i was wondering if it was actually better to keep the ORA output in 7_1 as well UNTIL we will have deployed the new DropBox for the new DB. For specific tests, we can always set the environment variable on. In addition, this PR also contains fixes ( although small ones ) outside the DB format.

ktf · 2014-01-27T08:00:45Z

CondCore/CondDB/src/SessionImpl.cc

+	  std::unique_ptr<IGTSchema> gtSchema( new GTSchema( coralSession->nominalSchema() ) );
+	  bool newCondDb = iovSchema->exists();
+	  if( !newCondDb && !readOnly ){
+	    const char* new_conddb_env = ::getenv( NEW_CONDDB );


getenv is taboo. Please use the parameter set.

Hi Chris,

[...]

bool newCondDb = iovSchema->exists();

if( !newCondDb && !readOnly ){

const char\* new_conddb_env = ::getenv( NEW_CONDDB );

getenv is taboo. Please use the parameter set.

this variable will be a temporary fix and is used only by experts for
testing and validating.

And as it is mainly used in standalone executables (condb_...) could you
please explain how to use the parameter set there in an easy way ?

Thanks,
cheers, andreas

cmsbuild · 2014-01-27T11:28:15Z

+1
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-2172/2160/summary.html

apfeiffer1 · 2014-01-27T15:53:16Z

+1

ggovi · 2014-01-27T16:41:46Z

Hi,

to provide a fast solution I have temporarily removed the ENV-based option

cmsbuild · 2014-01-27T16:46:14Z

Pull request #2172 was updated. @apfeiffer1, @diguida, @cmsbuild, @nclopezo, @rcastello, @ggovi, @Degano can you please check and sign again.

ktf · 2014-01-27T18:46:10Z

This looks ok to me. Please remember to bring it up in ORP tomorrow.

cmsbuild · 2014-01-27T20:11:55Z

+1
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-2172/32/summary.html

apfeiffer1 · 2014-01-27T20:18:04Z

+1

diguida · 2014-01-27T20:23:41Z

Hi @ggovi !
We discussed this in the meeting today. We agreed ( @apfeiffer1 can further comment, I could have misunderstood) to keep for the moment also 7.1.X using the OLD system by default (developers can switch it on for their tests). Then, when the final steps of the internal verification/validation are done, I think it would be good to switch the default in 7.1.X to the new system: in this way, you can start doing the complete integration and validation. At that point (end of Q1) also the dropbox for the new system should be in place, so it is safe to switch: developers creating calibrations in 7.1.X will be warned to use the new dropbox.
Does this seem reasonable to you all?

apfeiffer1 · 2014-01-27T20:25:38Z

+1

On Mon, Jan 27, 2014 at 9:23 PM, Salvatore Di Guida <
notifications@github.com> wrote:

Hi @ggovi https://github.com/ggovi !
We discussed this in the meeting today. We agreed ( @apfeiffer1 https://github.com/apfeiffer1can further comment, I could have misunderstood) to keep for the moment
also 7.1.X using the OLD system by default (developers can switch it on for
their tests). Then, when the final steps of the internal
verification/validation are done, I think it would be good to switch the
default in 7.1.X to the new system: in this way, you can start doing the
complete integration and validation. At that point (end of Q1) also the
dropbox for the new system should be in place, so it is safe to switch:
developers creating calibrations in 7.1.X will be warned to use the new
dropbox.
Does this seem reasonable to you all?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2172#issuecomment-33417570
.

Thanks,
cheers, andreas

cmsbuild · 2014-01-29T15:04:36Z

Pull request #2172 was updated. @apfeiffer1, @diguida, @cmsbuild, @nclopezo, @rcastello, @ggovi, @Degano can you please check and sign again.

apfeiffer1 · 2014-01-30T08:13:28Z

+1
apparently my previous "+1" on the latest commit does not count (though it is equivalent to this one, mathematically).

cmsbuild · 2014-01-30T08:39:35Z

+1
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-2172/19/summary.html

diguida · 2014-01-31T14:43:06Z

+1
@ggovi and I run the test.
TODO: understand why our tests did not spot the issue, even if the setup is the same.

cmsbuild · 2014-01-31T14:47:46Z

Pull request #2172 was updated. @ggovi, @cmsbuild, @apfeiffer1, @Degano, @nclopezo can you please check and sign again.

apfeiffer1 · 2014-01-31T14:56:25Z

+1
provided Jenkins agrees ...

On Fri, Jan 31, 2014 at 3:47 PM, cmsbuild notifications@github.com wrote:

Pull request #2172 #2172 was
updated. @ggovi https://github.com/ggovi, @cmsbuildhttps://github.com/cmsbuild,
@apfeiffer1 https://github.com/apfeiffer1, @deganohttps://github.com/degano,
@nclopezo https://github.com/nclopezo can you please check and sign
again.

Reply to this email directly or view it on GitHubhttps://github.com//pull/2172#issuecomment-33799449
.

Thanks,
cheers, andreas

cmsbuild · 2014-01-31T14:57:45Z

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_0_X IBs unless changes or unless it breaks tests. @ktf can you please take care of it?

cmsbuild · 2014-01-31T16:35:22Z

+1
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-2172/6/summary.html

cmsbuild · 2014-01-31T16:37:45Z

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_0_X IBs unless changes (tests are also fine). @ktf can you please take care of it?

davidlange6 · 2014-02-02T17:27:38Z

+1

Db -- Default format for new DB in output reverted to ORA

Advance data for RecoJets/JetProducers.

Default format for new DB in output reverted to ORA

e71798e

ktf reviewed Jan 27, 2014
View reviewed changes

Removed ENV- variable option

3ef800b

Frontier Initalized - Avoid the throw-catch's in coral

8444f71

Fix for HLT reconnect

ad55234

ktf added a commit that referenced this pull request Feb 2, 2014

Merge pull request #2172 from ggovi/new-conddb-phase2

0b670a8

Db -- Default format for new DB in output reverted to ORA

ktf merged commit 0b670a8 into cms-sw:CMSSW_7_0_X Feb 2, 2014

nclopezo added this to the CMSSW_7_0_0 milestone Feb 7, 2014

nclopezo removed this from the CMSSW_7_0_0_pre13 milestone Feb 7, 2014

ggovi pushed a commit to ggovi/cmssw that referenced this pull request Jan 11, 2017

Merge pull request cms-sw#2172 from degano/data_recojets_80X

34c1403

Advance data for RecoJets/JetProducers.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Default format for new DB in output reverted to ORA #2172

Default format for new DB in output reverted to ORA #2172

ggovi commented Jan 25, 2014

cmsbuild commented Jan 25, 2014

diguida commented Jan 25, 2014

ggovi commented Jan 25, 2014

ktf Jan 27, 2014

apfeiffer1 Jan 27, 2014

cmsbuild commented Jan 27, 2014

apfeiffer1 commented Jan 27, 2014

ggovi commented Jan 27, 2014

cmsbuild commented Jan 27, 2014

ktf commented Jan 27, 2014

cmsbuild commented Jan 27, 2014

apfeiffer1 commented Jan 27, 2014

diguida commented Jan 27, 2014

apfeiffer1 commented Jan 27, 2014

cmsbuild commented Jan 29, 2014

apfeiffer1 commented Jan 30, 2014

cmsbuild commented Jan 30, 2014

diguida commented Jan 31, 2014

cmsbuild commented Jan 31, 2014

apfeiffer1 commented Jan 31, 2014

cmsbuild commented Jan 31, 2014

cmsbuild commented Jan 31, 2014

cmsbuild commented Jan 31, 2014

davidlange6 commented Feb 2, 2014

Default format for new DB in output reverted to ORA #2172

Default format for new DB in output reverted to ORA #2172

Conversation

ggovi commented Jan 25, 2014

cmsbuild commented Jan 25, 2014

diguida commented Jan 25, 2014

ggovi commented Jan 25, 2014

ktf Jan 27, 2014

Choose a reason for hiding this comment

apfeiffer1 Jan 27, 2014

Choose a reason for hiding this comment

cmsbuild commented Jan 27, 2014

apfeiffer1 commented Jan 27, 2014

ggovi commented Jan 27, 2014

cmsbuild commented Jan 27, 2014

ktf commented Jan 27, 2014

cmsbuild commented Jan 27, 2014

apfeiffer1 commented Jan 27, 2014

diguida commented Jan 27, 2014

apfeiffer1 commented Jan 27, 2014

cmsbuild commented Jan 29, 2014

apfeiffer1 commented Jan 30, 2014

cmsbuild commented Jan 30, 2014

diguida commented Jan 31, 2014

cmsbuild commented Jan 31, 2014

apfeiffer1 commented Jan 31, 2014

cmsbuild commented Jan 31, 2014

cmsbuild commented Jan 31, 2014

cmsbuild commented Jan 31, 2014

davidlange6 commented Feb 2, 2014