You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2019/05/28 08:42:01 UTC
[jira] [Work logged] (HDDS-1596) Create service endpoint to
download configuration from SCM
[ https://issues.apache.org/jira/browse/HDDS-1596?focusedWorklogId=249194&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-249194 ]
ASF GitHub Bot logged work on HDDS-1596:
----------------------------------------
Author: ASF GitHub Bot
Created on: 28/May/19 08:41
Start Date: 28/May/19 08:41
Worklog Time Spent: 10m
Work Description: elek commented on pull request #861: HDDS-1596. Create service endpoint to download configuration from SCM
URL: https://github.com/apache/hadoop/pull/861
As written in the design doc (see the parent issue) it was proposed to download the configuration from the scm by the other services.
I propose to create a separated endpoint to provide the ozone configuration. /conf can't be used as it contains *all* the configuration and we need only the modified configuration.
The easiest way to implement this feature is:
* Create a simple rest endpoint which publishes all the configuration
* Download the configurations to $HADOOP_CONF_DIR/ozone-global.xml during the service startup.
* Add ozone-global.xml as an additional config source (before ozone-site.xml but after ozone-default.xml)
* The download can be optional
With this approach we keep the support of the existing manual configuration (ozone-site.xml has higher priority) but we can download the configuration to a separated file during the startup, which will be loaded.
There is no magic: the configuration file is saved and it's easy to debug what's going on as the OzoneConfiguration is loaded from the $HADOOP_CONF_DIR as before.
Possible follow-up steps:
* Migrate all the other services (recon, s3g) to the new approach. (possible newbie jiras)
* Improve the CLI to define the SCM address. (As of now we use ozone.scm.names)
* Create a service/hostname registration mechanism and autofill some of the configuration based on the topology information.
See: https://issues.apache.org/jira/browse/HDDS-1596
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 249194)
Time Spent: 10m
Remaining Estimate: 0h
> Create service endpoint to download configuration from SCM
> ----------------------------------------------------------
>
> Key: HDDS-1596
> URL: https://issues.apache.org/jira/browse/HDDS-1596
> Project: Hadoop Distributed Data Store
> Issue Type: Sub-task
> Reporter: Elek, Marton
> Assignee: Elek, Marton
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As written in the design doc (see the parent issue) it was proposed to download the configuration from the scm by the other services.
> I propose to create a separated endpoint to provide the ozone configuration. /conf can't be used as it contains *all* the configuration and we need only the modified configuration.
> The easiest way to implement this feature is:
> * Create a simple rest endpoint which publishes all the configuration
> * Download the configurations to $HADOOP_CONF_DIR/ozone-global.xml during the service startup.
> * Add ozone-global.xml as an additional config source (before ozone-site.xml but after ozone-default.xml)
> * The download can be optional
> With this approach we keep the support of the existing manual configuration (ozone-site.xml has higher priority) but we can download the configuration to a separated file during the startup, which will be loaded.
> There is no magic: the configuration file is saved and it's easy to debug what's going on as the OzoneConfiguration is loaded from the $HADOOP_CONF_DIR as before.
> Possible follow-up steps:
> * Migrate all the other services (recon, s3g) to the new approach. (possible newbie jiras)
> * Improve the CLI to define the SCM address. (As of now we use ozone.scm.names)
> * Create a service/hostname registration mechanism and autofill some of the configuration based on the topology information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org