RAC transition FAQ

Revision as of 16:40, 22 March 2019 by Pinto (talk | contribs) (→‎Storage)


This article is a draft

This is not a complete article: This is a draft, a work in progress that is intended to be published into an article, which may or may not be ready for inclusion in the main wiki. It should not necessarily be considered factual or authoritative.




Allocations from the 2019 Resource Allocation Competition come into effect on 2019 April 4. Here are some notes on how we expect the transition from 2018 to 2019 allocations to go.

Storage

  • There will be a 30 days overlap between 2018 and 2019 storage allocations, starting on Apr/04.
  • In principle adopt the largest of the 2 quotas (2018, 2019) during the transition period
  • If the new allocations have moved from one site to another, for small amounts users are expected to transfer material across by themselves (via globus, scp, rsync, etc). For larger amounts (>200TB?) maybe staff will need to help, upon request.
  • In the meantime, groups re-allocated from arbutus|cedar|graham|niagara to beluga are encouraged to start migrating their data now (beluga storage is already active).
  • Contributed storage systems have different dates of activation and decommissioning. For these we'll be doing the SUM(2018, 2019) for quotas during the 30 days transition period.
  • For every other PI we use default quotas
  • After the transition period, the quotas on the original sites from which data has been migrated will also be set to default. Users are expected to delete data from those original sites as well, if the quotas are above the default. Otherwise staff will delete everything.

Job scheduling

  • RAC 2019 allocations may not be active exactly on April 4th
  • Default allocations may face decreased priority as the RAC 2019 allocations become active and the RAC 2018 allocations are deactivated.
  • The scheduler team is planning to compact the database at approximately the same time as the new awards become active. We hope to schedule this during off-hours. During the compaction and archive process, the database may be unresponsive. Specifically, sacct and sacctmgr may be unresponsive for several hours.