migration module: add ability to copy to pool group w/o specifying the target #7623
Assignees
Labels
pool
Targeting the pool
Comments
|
The behavior has to be backward compatible in the folllowing way: Assumes, as before, that Whereas : without specifying pool group name triggers this migration into the same pool group invoked w/o has to fail just like it does now (this is somethig I have changed my mind about since Tuesday). I think this is safer as provides exact same behavior as before. |
greenc-FNAL
added a commit
that referenced
this issue
Sep 6, 2024
greenc-FNAL
added a commit
that referenced
this issue
Sep 17, 2024
greenc-FNAL
added a commit
that referenced
this issue
Sep 23, 2024
greenc-FNAL
added a commit
that referenced
this issue
Sep 24, 2024
greenc-FNAL
added a commit
that referenced
this issue
Sep 25, 2024
When `migration copy -pnfsid=X -target=pgroup` is executed without specification of a pool group, identify and use the pool group to which the source's pool(s) belong, if this is singular. Motivation: More intuitive implementation of a common use case. Modules: dcache dcache-vehicles Modification: * Change summary: * `MigrationModule` now allows empty target specification for `migration copy` IFF `-target=pgroup`. * New message `class PoolManagerGetPoolsByPoolGroupOfPoolMessage extends Message`. * New `class PoolListByPoolGroupOfPool extends AbstractMessageCallback<PoolManagerGetPoolsByPoolGroupOfPoolMessage> implements RefreshablePoolList` * New `messageArrived(PoolManagerGetPoolsByPoolGroupOfPoolMessage msg)` overload for `PoolManagerV5`. * Change history: * Implement #7623 * Implement logic described by #7623 (comment) * Fix handling of target list to account for possible omission * Generalize by renaming, per @DmitryLitvintsev suggestion * `PoolManagerGetPoolsBySourcePoolPoolGroupMessage` -> `PoolManagerGetPoolsByPoolGroupOfPoolMessage` * `PoolListBySourcePoolPoolGroup` -> `PoolListByPoolGroupOfPool` * `getPoolsBySourcePoolPoolGroup()` -> `getPoolsByPoolGroupOfPool()` * `(_?)sourcePool` -> `\1poolName` * `getSourcePool()` -> `getPoolName()` * "source pool" -> "pool" * Move check of number of pool groups returned from server to client Per https://rb.dcache.org/r/14316/#comment29381 N.B. The MigrationModule itself appears to have no access to the `poolList` upon job completion to verify its parameters, so the size check on the map is currently implemented in `PoolListByPoolGroupOfPool.success()`. Please advise if this is incorrect. * Address https://rb.dcache.org/r/14316/#comment29388 * Fix imports per https://rb.dcache.org/r/14316/#comment29389 * Reformat new code per official DCache style * Fix variable name per https://rb.dcache.org/r/14316/#comment29392 Result: `migration copy -pnfsid=X -target=pgroup` successfully identifies and uses an appropriate default pool group, where a unique one exists. Release notes: Pool migration : use pool group of source as default destination pool group on copy with `-target=pgroup` when identifiable and unique. Target: master Request: Patch: https://rb.dcache.org/r/14316/ Requires-notes: yes Requires-book: no Acked-by: Tigran Mkrtchyan, Dmitry Litvintsev
|
Implemented via cfeed0cc3ce399056472b5361b19dee433b0de4a |
khys95
pushed a commit
to khys95/dcache
that referenced
this issue
Oct 7, 2024
When `migration copy -pnfsid=X -target=pgroup` is executed without specification of a pool group, identify and use the pool group to which the source's pool(s) belong, if this is singular. Motivation: More intuitive implementation of a common use case. Modules: dcache dcache-vehicles Modification: * Change summary: * `MigrationModule` now allows empty target specification for `migration copy` IFF `-target=pgroup`. * New message `class PoolManagerGetPoolsByPoolGroupOfPoolMessage extends Message`. * New `class PoolListByPoolGroupOfPool extends AbstractMessageCallback<PoolManagerGetPoolsByPoolGroupOfPoolMessage> implements RefreshablePoolList` * New `messageArrived(PoolManagerGetPoolsByPoolGroupOfPoolMessage msg)` overload for `PoolManagerV5`. * Change history: * Implement dCache#7623 * Implement logic described by dCache#7623 (comment) * Fix handling of target list to account for possible omission * Generalize by renaming, per @DmitryLitvintsev suggestion * `PoolManagerGetPoolsBySourcePoolPoolGroupMessage` -> `PoolManagerGetPoolsByPoolGroupOfPoolMessage` * `PoolListBySourcePoolPoolGroup` -> `PoolListByPoolGroupOfPool` * `getPoolsBySourcePoolPoolGroup()` -> `getPoolsByPoolGroupOfPool()` * `(_?)sourcePool` -> `\1poolName` * `getSourcePool()` -> `getPoolName()` * "source pool" -> "pool" * Move check of number of pool groups returned from server to client Per https://rb.dcache.org/r/14316/#comment29381 N.B. The MigrationModule itself appears to have no access to the `poolList` upon job completion to verify its parameters, so the size check on the map is currently implemented in `PoolListByPoolGroupOfPool.success()`. Please advise if this is incorrect. * Address https://rb.dcache.org/r/14316/#comment29388 * Fix imports per https://rb.dcache.org/r/14316/#comment29389 * Reformat new code per official DCache style * Fix variable name per https://rb.dcache.org/r/14316/#comment29392 Result: `migration copy -pnfsid=X -target=pgroup` successfully identifies and uses an appropriate default pool group, where a unique one exists. Release notes: Pool migration : use pool group of source as default destination pool group on copy with `-target=pgroup` when identifiable and unique. Target: master Request: Patch: https://rb.dcache.org/r/14316/ Requires-notes: yes Requires-book: no Acked-by: Tigran Mkrtchyan, Dmitry Litvintsev
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Many a times a pool needs to be drained to be decomissioned. Typically the replicas need to go to the same pool group this pool belongs to. Currently you have to explicitly specify:
It would be nice just drop this extra parameters and by default
would copy replicas to pool group(s) the pool belongs to.
NB: pool may belong to multiple pool groups. Mabe alpha version of this functionality should refuse migration (fail) if pool belongs to multiple pool groups with clear message.
The text was updated successfully, but these errors were encountered: