[
https://issues.apache.org/jira/browse/HDDS-15729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Andika updated HDDS-15729:
-------------------------------
Description:
The PlacementPolicy (both Pipeline Placement Policy and the Container Placement
Policy) is poorly abstracted which is very hard to reason about. There are a
lot of leaky abstractions or logic specific to a replication config (e.g. Ratis
logic in interface that can also be applied to EC). I found myself getting lost
every time I look at the placement policy logic since it's hard to build a
mental model of the whole process. This task is to identify these abstractions
and fix them for better readability and maintainability, as well as document
the exact contracts and responsibilities of these policies. This will minimize
any surprises and potential bugs due to misunderstandings.
For example (not exhaustive)
* PlacementPolicy is supposed to be generic, but we have container placement
specific logic like validateContainerPlacement and
replicasToCopyToFixMisReplication and replicasToRemoveToFixOverreplication
* PipelinePlacementPolicy seems to only used for RATIS pipeline, but we have
EC pipeline, so it gives an impression that PipelinePlacementPolicy can also be
used for EC, which AFAIK is not the case.
*
** PipelinePlacementPolicy is only used for RATIS, then we should make it
explicit by changing the name to RatisPipelinePlacementPolicy
** PipelinePlacementPolicy also have internal "Ratis" related pipelines like
* We are still using PlacementPolicy for everything, even if
PipelinePlacementPolicy is more appropriate for pipeline related matters, which
forces PlacementPolicy to implement interfaces that it should not be
implementing
** For example, in RatisPipelineProvider we can change PlacementPolicy to
PipelinePlacementPolicy since we are dealing with pipeline
* Domain concepts like "anchor node" is not properly defined
* Most of the placement policy is still based on the assumption of rack/leaf
hierarchies
** We need to be able to be more flexible in supporting other schema
(datacenter, region, hall, spine, etc)
** For example, Ceph CRUSH allows administrator to arbitrarily setup the
schema and the CRUSH algorithm will be able to adapt to it (of course there is
risk on this and complexity, so we don't need to go to this far, but it's good
to consider)
was:
The PlacementPolicy (both Pipeline Placement Policy and the Container Placement
Policy) is poorly abstracted which is very hard to reason about. There are a
lot of leaky abstractions or logic specific to a replication config (e.g. Ratis
logic in interface that can also be applied to EC). I found myself getting lost
every time I look at the placement policy logic since it's hard to build a
mental model of the whole process. This task is to identify these abstractions
and fix them for better readability and maintainability, as well as document
the exact contracts and responsibilities of these policies. This will minimize
any surprises and potential bugs due to misunderstandings.
For example (not exhaustive)
* PlacementPolicy is supposed to be generic, but we have container placement
specific logic like validateContainerPlacement and
replicasToCopyToFixMisReplication and replicasToRemoveToFixOverreplication
* PipelinePlacementPolicy seems to only used for RATIS pipeline, but we have
EC pipeline, so it gives an impression that PipelinePlacementPolicy can also be
used for EC, which AFAIK is not the case.
*
** PipelinePlacementPolicy is only used for RATIS, then we should make it
explicit by changing the name to RatisPipelinePlacementPolicy
** PipelinePlacementPolicy also have internal "Ratis" related pipelines like
* We are still using PlacementPolicy for everything, even if
PipelinePlacementPolicy is more appropriate for pipeline related matters, which
forces PlacementPolicy to implement interfaces that it should not be
implementing
** For example, in RatisPipelineProvider we can change PlacementPolicy to
PipelinePlacementPolicy since we are dealing with pipeline
* Domain concepts like "anchor node" is not properly defined
* The whole placement policy is still based on the assumption of rack/leaf
hierarchies
** We need to be able to be more flexible in supporting other schema
(datacenter, region, hall, spine, etc)
** For example, Ceph CRUSH allows administrator to arbitrarily setup the
schema and the CRUSH algorithm will be able to adapt to it (of course there is
risk on this and complexity, so we don't need to go to this far, but it's good
to consider)
> Improve the PlacementPolicy code structure
> ------------------------------------------
>
> Key: HDDS-15729
> URL: https://issues.apache.org/jira/browse/HDDS-15729
> Project: Apache Ozone
> Issue Type: Improvement
> Reporter: Ivan Andika
> Assignee: Ivan Andika
> Priority: Major
>
> The PlacementPolicy (both Pipeline Placement Policy and the Container
> Placement Policy) is poorly abstracted which is very hard to reason about.
> There are a lot of leaky abstractions or logic specific to a replication
> config (e.g. Ratis logic in interface that can also be applied to EC). I
> found myself getting lost every time I look at the placement policy logic
> since it's hard to build a mental model of the whole process. This task is to
> identify these abstractions and fix them for better readability and
> maintainability, as well as document the exact contracts and responsibilities
> of these policies. This will minimize any surprises and potential bugs due to
> misunderstandings.
> For example (not exhaustive)
> * PlacementPolicy is supposed to be generic, but we have container placement
> specific logic like validateContainerPlacement and
> replicasToCopyToFixMisReplication and replicasToRemoveToFixOverreplication
> * PipelinePlacementPolicy seems to only used for RATIS pipeline, but we have
> EC pipeline, so it gives an impression that PipelinePlacementPolicy can also
> be used for EC, which AFAIK is not the case.
> *
> ** PipelinePlacementPolicy is only used for RATIS, then we should make it
> explicit by changing the name to RatisPipelinePlacementPolicy
> ** PipelinePlacementPolicy also have internal "Ratis" related pipelines like
> * We are still using PlacementPolicy for everything, even if
> PipelinePlacementPolicy is more appropriate for pipeline related matters,
> which forces PlacementPolicy to implement interfaces that it should not be
> implementing
> ** For example, in RatisPipelineProvider we can change PlacementPolicy to
> PipelinePlacementPolicy since we are dealing with pipeline
> * Domain concepts like "anchor node" is not properly defined
> * Most of the placement policy is still based on the assumption of rack/leaf
> hierarchies
> ** We need to be able to be more flexible in supporting other schema
> (datacenter, region, hall, spine, etc)
> ** For example, Ceph CRUSH allows administrator to arbitrarily setup the
> schema and the CRUSH algorithm will be able to adapt to it (of course there
> is risk on this and complexity, so we don't need to go to this far, but it's
> good to consider)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
