[RTFACT-13732] Ability to specify shards for repository Created: 16/Feb/17  Updated: 04/May/20

Status: Open
Project: Artifactory Binary Repository
Component/s: Artifact Storage, Filestore
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: High
Reporter: Omar Faiz (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 6
Labels: None

Issue Links:
is duplicated by RTFACT-18453 Assign different filesystem per repos... Resolved
is duplicated by RTFACT-18671 Ability to choose different filestore... Resolved


Users would like to be able to specify which repositories will be in specific shards in their filestore. For example, docker images would be set onto a shard that is a 250GB SSD, while others are on slower filestore systems.

Comment by Mike Klusman [ 09/May/18 ]

This type of behavior would be a nice to have in the event particularly heavy used repositories could be placed onto better storage hardware and less active repositories could be moved to slower spindle hardware.  If the capability of targeting filestores which have differing read/write access (or are not co-located – i.e. network limited) was possible, then high demand repositories could be properly "positioned' to take advantage of appropriate hardware especially if the overall hardware components are of differing sizes. 

Comment by Philippe Busque [ 05/Apr/19 ]

We are migrating from Nexus to Artifactory.

We kept all our 'old' build into an 'archive' repository on a different disk volume (fewer backup, slower disk, fewer maintenance) while all our active build were keep in a more reliable volume (hourly backup, faster disk, daily maintenance task).


We're a bit disappointed that this feature is missing and we would really like to see this feature built in Artifactory too.  Since Artifactory already has a notion of build store, I should be doable to define multiple one and have the choice to pick which one we want during the creation of a repository (and the ability to move between filestore).

Generated at Wed Aug 12 01:37:27 UTC 2020 using Jira 8.5.3#805003-sha1:b4933e02eaff29a49114274fe59e1f99d9d963d7.