enhancement: extend the p2p preheat policy

[chlins]

Propose to extend the p2p preheat policy for enhancing the preheat scenario in AI era.

[reasonerjt]

If the extra_attrs are provider specific, how will Harbor send the extra_attrs?
IMO this has to be answered to make sure other p2p providers can consume the new attributes.

Additionally, why not make the "scope" also part of extra_attrs, if at this moment only dragonfly can consume it?

[chlins]

In the harbor codebase, each p2p provider will have a driver implementation capable of parsing or handling extra_attrs independently to determine how to transmit them. We emphasize the scope separately from extra_attrs because it's a universally applicable, vendor-neutral property in p2p scenarios. Placing it as a standalone attribute is more user-friendly than including it within extra_attrs, as the latter is intended for vendor-specific attributes. We consider scope a standard p2p option.

Currently, I think we do not have much choice for image p2p solution, harbor integrates dragonfly and kraken, and it seems kraken project is no longer in an active maintenance state, as it's last release version was still published four years ago.

[reasonerjt]

In the harbor codebase, each p2p provider will have a driver implementation capable of parsing or handling extra_attrs independently to determine how to transmit them.

Is it already in the code base to handle extra_attrs? I don't see how the Driver interface handles the extra_attrs or even the policy. If there are any changes need to made in the driver side they should also be reflected in this design.

We emphasize the scope separately from extra_attrs because it's a universally applicable, vendor-neutral property in p2p scenarios.

I agree "scope" can be a common concept for P2P scenario, but different vendors may parse the param differently, for example, a vendor may support distributing the artifacts to certain regions or nodes with certain labels. Therefore, I wish to suggest we leave it in the "extra_attrs" to provide more flexibilities for providers.

[chlins]

We don't need to change the Driver interface, we only need to add the field in the Preheat function parameters, then the driver self can get it and process it by their own logic. I can supplement this field into the design.

I agree with what you said that different vendors may have different requirements, such as region or label, etc., so these custom items for vendors can all be placed in extra. However, I still believe that scope should be a very general and clear concept that can be shared or recognized by all p2p solutions, so the separate abstraction can bring a better user experience. Because although extra can contain anything, from my personal perspective, the user experience of extra is not very friendly, and its concept is quite broad.