[
https://issues.apache.org/jira/browse/HDFS-11768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anu Engineer updated HDFS-11768:
--------------------------------
Attachment: HDFS-11768-HDFS-7240.002.patch
Attaching patch v2. Addressed all comments from [~msingh], [~cheersyang] and
[~xyao]. This patch is around 50% bigger than the earlier patch due to moving
pipeline and keyvalue messages to ozone.proto.
Please see below for detailed comments.
[~msingh]
bq. 1) KeySpaceManager.proro, in most of the proto files, "Proto" is suffixed
to message names.
Fixed.
bq. 2) ScmConfigKeys, OZONE_KSM_PORT_KEY should be removed as there are no
accessors right now.
Removed.
[~cheersyang]
bq. Create volume API: I am a bit confused with adminName and ownerName, I
thought a volume can be created by any valid user (not just ozone admin) and
the creator should be its owner. I don't understand the point to have an admin
and an owner.
Please look at the page 16 of the Ozone Rest Spec.
https://issues.apache.org/jira/secure/attachment/12799549/ozone_user_v0.pdf
In short, we use volumes entities that can only be created or updated by
admins. We allow admins to create and set quota on volumes. Users can create
large number of buckets and keys. We restrict total number of volumes per user
too.
bq. The response status from all volume operations seem to be similar, does it
make sense to reuse enum Status for all messages? And volume operations may
fail with I/O errors, does it make sense to add IO_ERROR to Status?
Fixed.
bq. VolumeInfo seems to need more fields, e.g data created, data modified,
size, volume status and volumeID. Or this might fit to a new message
VolumeStatus which can be used in InfoVolume.
Agreed, but the actual API implimentation will take care of that.
bq. Delete volume API: why it is only allowed to delete a volume without any
bucket within? It seems pretty common for user to delete a volume owned by
themselves.
This is to avoid huge recursive jobs on KSM and datanodes which can be
triggered with simple commands. This allows us to avoid taking locks that span
whole bucket.
[~xyao]
bq. ScmConfigKeysis it better to place ksm keys in a similar class such as
KsmConfigKeys ?
Fixed.
bq. line 111 - java doc should be main entry for starting KeySpaceManager
Fixed.
bq. Should we rename KeyspaceManager.proto -> KeySpaceManager.proto
Fixed
bq. Line 33: can you add a comment on keyValueMap or rename?
Fixed.
bq. rename to KeySpaceManagerProtocol.java for consistency.
Fixed
bq. Should we have a separate KsmConfigKeys.java for these KSM keys
Fixed.
bq. Can we pull KeyValue from DatanodeContainerProtocol.proto into Ozone.proto
as it seems to be the only one used here.
Fixed.
bq. Can we add a test for KSM address/port similar to testGetScmDataNodeAddress?
Fixed.
bq. KeyspaceManagerProtocolServerSideTranslatorPB.java
Fixed.
> Ozone: KSM: Create Key Space manager service
> --------------------------------------------
>
> Key: HDFS-11768
> URL: https://issues.apache.org/jira/browse/HDFS-11768
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ozone
> Affects Versions: HDFS-7240
> Reporter: Anu Engineer
> Assignee: Anu Engineer
> Attachments: HDFS-11768-HDFS-7240.001.patch,
> HDFS-11768-HDFS-7240.002.patch, ozone-key-space.pdf
>
>
> KSM is the namespace manager for Ozone. KSM relies on SCM to achieve block
> functions. Ozone handler -- The rest protocol frontend talks to KSM and SCM
> to get datanode addresses.
> This JIRA will add the service as well as add the protobuf definitions needed
> to work with KSM.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
