- RC0 is out, please vote when you get a chance.
| 2||Refactoring Interfaces||pifta, marton, xiaoyu, anu , bharat|
- We discussed the interface renaming and refactoring issue at great depth.
- We can continue discussion in JIRAs, where more finer feedback will be possible.
- OM Client - The Ozone Manager client – The APIs from RPC client.
- OM Admin - If there are Admin only commands supported by OM then it will be part of this interface.
- SCM Client - We really have no users for this API today. But will help other services if they decide to use HDDS.
- SCM Admin - The Admin API for SCM.
- SCM Server - This interface will be used by OzoneManager, Recon and see if we can move the SCMSecurity service also into this end point.
- Datanode Client - The RPC client will use this interface to communicate with Data node
- Datanode Server - This interface will be used by data node to data node communication like copying blocks and containers for replication.We decided to create the following interfaces.
- SCM HB protocol - This is a special case, since the HBs and lots of command/info flows through this interface.
- We have decided to lose the word protocol from the proto files.
- We will try to have a service (that is a network port corresponding) to these services. This will make it easier for network admins to manage firewall configuration for admin commands.
|3||URI Refactoring Change||Anu, pifta, Clay, Xiaoyu|
We discussed the proposal from Sanjay in depth. There are few things that Clay mentioned.
He likes the like losing the bucket and volume for the following reasons.
- If the system is purely DNS driven, and not config driven, then creates a dependency that deployments need Dynamic DNS.
- His more important point was that this makes write code against FileSystem object much easier. You can create one FileSystem object and write into any bucket. That is a huge win from the programming perspective.
- Xiaoyu asked if we are planning to support the .trash feature with OzoneFS at all? We think it is simpler and easier to have a server side delete policy under Ozone.
- pifta wanted to make sure that Hive and other applications can work correctly.
- He pointed out that one of the issues is that user will get an error if they try to write a file right under the volume.
- Clay pointed out that it might be a "good" feature to have for a file system with Ozone's scale. The fact that you cannot write to a volume should make managing the FS easier.
|4||Discuss Error handling in Ratis||Clay|
Clay wanted to bring in FailSafe like API into Ratis. We discussed how Ozone handles failures when a Ratis pipeline hangs. Ozone just discards those pipelines, and open up other pipelines in the cluster. But we would like to have failsafe like API.
|5||Ratis Fails with 5 Servers||Clay||Clay was trying to run Ratis with 5 server instances, even the basic math server example does not work. He will file a issue and work on root causing the issue.|