[FTS-894] Reevaluate and refactor configuration, optimizer and scheduler Created: 14/Feb/17  Updated: 27/Jul/17  Resolved: 15/May/17

Status: Closed
Project: FTS
Component/s: MySQL, Server
Affects Version/s: None
Fix Version/s: fts 3.7.0
Security Level: Public Data (This ticket is visible to anyone on the internet and will be indexed by search engines)

Type: Epic Priority: Minor
Reporter: Alejandro Alvarez Ayllon (Inactive) Assignee: Alejandro Alvarez Ayllon (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Child-Issue
is parent task of FTS-922 Allow to set minimum number of transf... Closed
is parent task of FTS-977 Update fts-rest to the new config schema Closed
is parent task of FTS-978 Document new configuration schema Closed
Duplicate
duplicates FTS-794 Validate auto-tunning setting does ac... Closed
Relates
relates to FTS-793 Provide an Optimizer API Closed
relates to FTS-890 getReadySessionReuseTransfers picks r... Closed
relates to FTS-891 Should not account for READY transfer... Closed
relates to FTS-951 Optimizer could count, and store, num... Closed
Epic Name: Configuration refactor
Component Watchers:
Actual Start:

 Description   

Need to reevaluate and refactor the way the configuration, scheduler and optimizer interact. For instance, I find confusing some checks on t_link_config when scheduling, because it disables the optimizer, but doesn't override with a number of actives.

In my opinion, scheduling should only be affected by the optimizer and the absolute storage limit (since one storage may be part of more than one link running).

All configuration related to number of actives and the like, should affect the optimizer. If the optimizer is disabled, leave the chosen value as is.

Other parameters may still be of use outside the optimizer (i.e. udt, ipv6...)



 Comments   
Comment by GitLab service [ 12/May/17 ]

Alejandro Alvarez Ayllon mentioned this issue in a commit of fts/fts-monitoring:
'FTS-894: Adapt views to new config'

Comment by GitLab service [ 12/May/17 ]

Alejandro Alvarez Ayllon mentioned this issue in a commit of fts/fts-monitoring:
'FTS-894: Adapt views to new config'

Comment by GitLab service [ 12/May/17 ]

Alejandro Alvarez Ayllon mentioned this issue in a commit of fts/fts-monitoring:
'FTS-894: Adapt views to new config'

Comment by GitLab service [ 15/May/17 ]

Alejandro Alvarez Ayllon mentioned this issue in a merge request of fts/fts-monitoring:
'FTS-894: Adapt views to new config'

Comment by GitLab service [ 15/May/17 ]

Alejandro Alvarez Ayllon mentioned this issue in a commit of fts/fts-monitoring:
'FTS-894: Fix link model and view'

Comment by Clockwork Droid [ 12/Jun/17 ]

Alejandro Alvarez Ayllon mentioned this issue in a commit of fts/fts3:
'FTS-894: Recover behavior with link not configured'

Comment by Clockwork Droid [ 27/Jul/17 ]

Alejandro Alvarez Ayllon mentioned this issue in a commit of fts/fts3:
'FTS-894: Adapt to new schema'

Comment by Clockwork Droid [ 27/Jul/17 ]

Alejandro Alvarez Ayllon mentioned this issue in a commit of fts/fts3:
'FTS-894: Apply vo shares for reuse too'

Comment by Clockwork Droid [ 27/Jul/17 ]

Alejandro Alvarez Ayllon mentioned this issue in a commit of fts/fts3:
'FTS-894: Add check for VOs without share'

Comment by Clockwork Droid [ 27/Jul/17 ]

Alejandro Alvarez Ayllon mentioned this issue in a commit of fts/fts3:
'FTS-894: Give more priority to debug level for SE'

Comment by Clockwork Droid [ 27/Jul/17 ]

Alejandro Alvarez Ayllon mentioned this issue in a commit of fts/fts3:
'FTS-894: Reenable VO shares but with weights'

Comment by Clockwork Droid [ 27/Jul/17 ]

Alejandro Alvarez Ayllon mentioned this issue in a commit of fts/fts3:
'FTS-894: Candidate schema'

Generated at Wed Jul 18 04:43:06 CEST 2018 using JIRA 7.8.4#78004-sha1:5704c55c9196a87d91490cbb295eb482fa3e65cf.