Difference: CheckList (1 vs. 7)

Revision 72008-11-21 - ZoltanMathe

Line: 1 to 1
 
META TOPICPARENT name="BKDev"

What to check before putting the system in production:

(after the meeting with Zoltan, Miguel and Elisa, on Fri Oct 17 2008)
Line: 62 to 62
  jobs_before_delete
Added:
>
>

What to check before provide the new Bookkeeping system to the users:

After we migrated to production system we have to decide when retired the old system. we have same point what we have to solve.
We have 2 important point before we retried the old bkk:

* 1 genCatalog functionality

*2 We have to query the new bkk to gets the ancestors. (DIRAC3 has to use the new BKK.)

They are inportant points, but they are not very urgent:

* 3 testing the new GUI I recevied feedbacks from users. Ongoing

* 4 BKK instalation on local machine. Zoltan ( I will test the development system(volhcb04))

* 5 Bkk user documentation. Zoltan Ongoing

 

-- ElisaLanciotti - 17 Oct 2008

Revision 62008-11-10 - ZoltanMathe

Line: 1 to 1
 
META TOPICPARENT name="BKDev"

What to check before putting the system in production:

(after the meeting with Zoltan, Miguel and Elisa, on Fri Oct 17 2008)
Line: 9 to 9
 
  • 3 Check the new schema (keys, indexes, ...). In the processing_pass tables we should put indexes on the foreign keys (passid). Zoltan. Done
Changed:
<
<
  • 4 Materialized view creation ( automatic or agent?). Zoltan thinks we do not need a view. After the migration, he will test how it works without using a view. The agent is done Zoltan. Miguel Ongoing
>
>
  • 4 Materialized view creation ( automatic or agent?). Zoltan thinks we do not need a view. After the migration, he will test how it works without using a view. The agent is done Zoltan. Miguel fixed the code, we decide we are not using agent for update Done
 
  • 5 Remove the not used attributes (for ex, In jobs table DaqPeriodId,Generator). I can't remove because the active production BKK registration will fail. Ongoing
Line: 23 to 23
 1 grid-job = 6*BK-jobs where 1 grid-job has 500 events. So, if we set the total number of events to be simulated in 1 year equal to 2*10^9 it gives the total number: 2.4*10^7 BK-jobs per year + the real data. To be safe, let's say 4*10^7 new jobs in the BK per year. ok
Changed:
<
<
  • 10 Remove the trigger which automatically deletes the files when a job is deleted (this can be substituted by a foreign key with the property of delete in cascade. Ongoing We decide I will remove this trigger in the production system
>
>
  • 10 Remove the trigger which automatically deletes the files when a job is deleted (this can be substituted by a foreign key with the property of delete in cascade. Done
 
  • 11 Establish if the data, once inserted into the bk database, are read-only or can be removed. This is very important for Miguel, because it determines the type of backup he has to set for the DB. If they are read-only, he can make a much simpler and less expansive backup. The point is: in principle we are not going to remove entries from the BK, but we will want to update them! (got-replica flag and data quality) so I don't know if a read-only backup works in this case. Ask to Miguel

Revision 52008-11-03 - ZoltanMathe

Line: 1 to 1
 
META TOPICPARENT name="BKDev"

What to check before putting the system in production:

(after the meeting with Zoltan, Miguel and Elisa, on Fri Oct 17 2008)

  • 1 Pass_index ( I have to copy some simulation condition). Zoltan. Done
Changed:
<
<
  • 2 Fill the processing_pass table (new productions). Joel is filling this table. It is not problem if it is not done before the migration, because he can fill it in the production system. ( the only problem is that the users can't see the new productions). Ongoing
>
>
  • 2 Fill the processing_pass table (new productions).Script to be provided to add new productions to the book-Keeping, Zoltan. Done. Populate the processing pass table. Joel. Ongoing
 
  • 3 Check the new schema (keys, indexes, ...). In the processing_pass tables we should put indexes on the foreign keys (passid). Zoltan. Done
Changed:
<
<
  • 4 Materialized view creation ( automatic or agent?). Zoltan thinks we do not need a view. After the migration, he will test how it works without using a view. The agent is done.
>
>
  • 4 Materialized view creation ( automatic or agent?). Zoltan thinks we do not need a view. After the migration, he will test how it works without using a view. The agent is done Zoltan. Miguel Ongoing
 
  • 5 Remove the not used attributes (for ex, In jobs table DaqPeriodId,Generator). I can't remove because the active production BKK registration will fail. Ongoing

Revision 42008-11-03 - ElisaLanciotti

Line: 1 to 1
 
META TOPICPARENT name="BKDev"

What to check before putting the system in production:

(after the meeting with Zoltan, Miguel and Elisa, on Fri Oct 17 2008)
Line: 20 to 20
 
  • 8 Set the Simcondid as primary key in the simulationConditions table (Elisa). Done

  • 9 Find out which is the increase rate of jobs and file. Can we foresee how many new files and jobs will be inserted into the database per year? (Philippe)
Added:
>
>
1 grid-job = 6*BK-jobs where 1 grid-job has 500 events. So, if we set the total number of events to be simulated in 1 year equal to 2*10^9 it gives the total number: 2.4*10^7 BK-jobs per year + the real data. To be safe, let's say 4*10^7 new jobs in the BK per year. ok
 
  • 10 Remove the trigger which automatically deletes the files when a job is deleted (this can be substituted by a foreign key with the property of delete in cascade. Ongoing We decide I will remove this trigger in the production system
Changed:
<
<
  • 11 Establish if the data, once inserted into the bk database, are read-only or can be removed. This is very important for Miguel, because it determines the type of backup he has to set for the DB. If they are read-only, he can make a much simpler and less expansive backup.
>
>
  • 11 Establish if the data, once inserted into the bk database, are read-only or can be removed. This is very important for Miguel, because it determines the type of backup he has to set for the DB. If they are read-only, he can make a much simpler and less expansive backup. The point is: in principle we are not going to remove entries from the BK, but we will want to update them! (got-replica flag and data quality) so I don't know if a read-only backup works in this case. Ask to Miguel
 
  • 12 Provide the list of objects which have to be migrated to the production system:

Revision 32008-11-03 - ZoltanMathe

Line: 1 to 1
 
META TOPICPARENT name="BKDev"

What to check before putting the system in production:

(after the meeting with Zoltan, Miguel and Elisa, on Fri Oct 17 2008)
Line: 7 to 7
 
  • 2 Fill the processing_pass table (new productions). Joel is filling this table. It is not problem if it is not done before the migration, because he can fill it in the production system. ( the only problem is that the users can't see the new productions). Ongoing
Changed:
<
<
  • 3 Check the new schema (keys, indexes, ...). In the processing_pass tables we should put indexes on the foreign keys (passid). Zoltan. Ongoing
>
>
  • 3 Check the new schema (keys, indexes, ...). In the processing_pass tables we should put indexes on the foreign keys (passid). Zoltan. Done
 
  • 4 Materialized view creation ( automatic or agent?). Zoltan thinks we do not need a view. After the migration, he will test how it works without using a view. The agent is done.
Changed:
<
<
  • 5 Remove the not used attributes (for ex, In jobs table DaqPeriodId,Generator). Blocked by point 7. Ongoing
>
>
  • 5 Remove the not used attributes (for ex, In jobs table DaqPeriodId,Generator). I can't remove because the active production BKK registration will fail. Ongoing
 
  • 6 We have to reimplement a materialized view. Zoltan. Done
Changed:
<
<
  • 7 We have to change the BKK API, because I removed the DaqPeriod. Zoltan. Ongoing
>
>
  • 7 We have to change the BKK API, because I removed the DaqPeriod. Zoltan. Done
 
  • 8 Set the Simcondid as primary key in the simulationConditions table (Elisa). Done

  • 9 Find out which is the increase rate of jobs and file. Can we foresee how many new files and jobs will be inserted into the database per year? (Philippe)
Changed:
<
<
  • 10 Remove the trigger which automatically deletes the files when a job is deleted (this can be substituted by a foreign key with the property of delete in cascade. Ongoing
>
>
  • 10 Remove the trigger which automatically deletes the files when a job is deleted (this can be substituted by a foreign key with the property of delete in cascade. Ongoing We decide I will remove this trigger in the production system
 
  • 11 Establish if the data, once inserted into the bk database, are read-only or can be removed. This is very important for Miguel, because it determines the type of backup he has to set for the DB. If they are read-only, he can make a much simpler and less expansive backup.
Line: 43 to 43
  Packages
Added:
>
>
BKK_ORACLE
BKK_MONITORING
 Sequences
Added:
>
>
pass_index_seq
groupid_seq
PRODUCTION_SEQ
jobId_seq
fileId_seq
configurationId_seq
simulationCondID_seq
 Triggers
Added:
>
>
jobs_before_delete
 

Revision 22008-11-03 - ElisaLanciotti

Line: 1 to 1
 
META TOPICPARENT name="BKDev"

What to check before putting the system in production:

(after the meeting with Zoltan, Miguel and Elisa, on Fri Oct 17 2008)
Changed:
<
<
  • 1 Pass_index ( I have to copy some simulation condition). Zoltan
  • 2 Fill the processing_pass table (new productions). Zoltan
  • 3 Check the new schema (keys, indexes, ...). In the processing_pass tables we should put indexes on the foreign keys (passid). Zoltan
  • 4 Materialized view creation ( automatic or agent?). Zoltan
  • 5 Remove the not used attributes (for ex, In jobs table DaqPeriodId,Generator)
  • 6 We have to reimplement a materialized view. Zoltan
  • 7 We have to change the BKK API, because I removed the DaqPeriod. Zoltan
  • 8 Set the Simcondid as primary key in the simulationConditions table (Elisa)
  • 9 Find out which is the increase rate of jobs and file. Can we foresee how many new files and jobs will be inserted into the database? (Elisa, Philippe)
  • 10 Remove the trigger which automatically deletes the files when a job is deleted (this can be substituted by a foreign key with the property of delete in cascade
>
>
  • 1 Pass_index ( I have to copy some simulation condition). Zoltan. Done

  • 2 Fill the processing_pass table (new productions). Joel is filling this table. It is not problem if it is not done before the migration, because he can fill it in the production system. ( the only problem is that the users can't see the new productions). Ongoing

  • 3 Check the new schema (keys, indexes, ...). In the processing_pass tables we should put indexes on the foreign keys (passid). Zoltan. Ongoing

  • 4 Materialized view creation ( automatic or agent?). Zoltan thinks we do not need a view. After the migration, he will test how it works without using a view. The agent is done.

  • 5 Remove the not used attributes (for ex, In jobs table DaqPeriodId,Generator). Blocked by point 7. Ongoing

  • 6 We have to reimplement a materialized view. Zoltan. Done

  • 7 We have to change the BKK API, because I removed the DaqPeriod. Zoltan. Ongoing

  • 8 Set the Simcondid as primary key in the simulationConditions table (Elisa). Done

  • 9 Find out which is the increase rate of jobs and file. Can we foresee how many new files and jobs will be inserted into the database per year? (Philippe)

  • 10 Remove the trigger which automatically deletes the files when a job is deleted (this can be substituted by a foreign key with the property of delete in cascade. Ongoing
 
  • 11 Establish if the data, once inserted into the bk database, are read-only or can be removed. This is very important for Miguel, because it determines the type of backup he has to set for the DB. If they are read-only, he can make a much simpler and less expansive backup.
Added:
>
>
  • 12 Provide the list of objects which have to be migrated to the production system:

Tables

JOBS
FILES
INPUTFILES
CONFIGURATIONS
FILETYPES
EVENTTYPES
DATA_TAKING_CONDITIONS
SIMULATIONCONDITIONS
PROCESSING_PASS
PASS_INDEX
PASS_GROUP

Packages

Sequences

Triggers

 

-- ElisaLanciotti - 17 Oct 2008

Revision 12008-10-17 - ElisaLanciotti

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="BKDev"

What to check before putting the system in production:

(after the meeting with Zoltan, Miguel and Elisa, on Fri Oct 17 2008)

  • 1 Pass_index ( I have to copy some simulation condition). Zoltan
  • 2 Fill the processing_pass table (new productions). Zoltan
  • 3 Check the new schema (keys, indexes, ...). In the processing_pass tables we should put indexes on the foreign keys (passid). Zoltan
  • 4 Materialized view creation ( automatic or agent?). Zoltan
  • 5 Remove the not used attributes (for ex, In jobs table DaqPeriodId,Generator)
  • 6 We have to reimplement a materialized view. Zoltan
  • 7 We have to change the BKK API, because I removed the DaqPeriod. Zoltan
  • 8 Set the Simcondid as primary key in the simulationConditions table (Elisa)
  • 9 Find out which is the increase rate of jobs and file. Can we foresee how many new files and jobs will be inserted into the database? (Elisa, Philippe)
  • 10 Remove the trigger which automatically deletes the files when a job is deleted (this can be substituted by a foreign key with the property of delete in cascade
  • 11 Establish if the data, once inserted into the bk database, are read-only or can be removed. This is very important for Miguel, because it determines the type of backup he has to set for the DB. If they are read-only, he can make a much simpler and less expansive backup.

-- ElisaLanciotti - 17 Oct 2008

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback