[jira] [Commented] (AMBARI-23945) Infra Solr migration: use less params for migration steps (make it easier to use)
[ https://issues.apache.org/jira/browse/AMBARI-23945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519922#comment-16519922 ] Hudson commented on AMBARI-23945: - FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #9503 (See [https://builds.apache.org/job/Ambari-trunk-Commit/9503/]) AMBARI-23945. Infra Solr Migration: add number of docs check. (oleewere: [https://gitbox.apache.org/repos/asf?p=ambari.git=commit=9ce3191371701ebdc4cafd830b8b2712dc293d25]) * (edit) ambari-infra/ambari-infra-solr-client/src/main/python/migrationHelper.py > Infra Solr migration: use less params for migration steps (make it easier to > use) > - > > Key: AMBARI-23945 > URL: https://issues.apache.org/jira/browse/AMBARI-23945 > Project: Ambari > Issue Type: Bug > Components: ambari-infra >Affects Versions: 2.7.0 >Reporter: Olivér Szabó >Assignee: Olivér Szabó >Priority: Major > Labels: pull-request-available > Fix For: 2.7.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMBARI-24164) Add a config section for "livy-client.conf" settings for Livy
Tao Li created AMBARI-24164: --- Summary: Add a config section for "livy-client.conf" settings for Livy Key: AMBARI-24164 URL: https://issues.apache.org/jira/browse/AMBARI-24164 Project: Ambari Issue Type: Improvement Components: stacks Affects Versions: 2.6.2 Reporter: Tao Li "livy-client.conf" settings have not been integrated with Ambari, so these settings are not configurable through Ambari. But I do have a scenario when I need to change these settings. Should we add this to Ambari? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24163) Infra Solr: solrDataManager.py should support transport data without timestamp field
[ https://issues.apache.org/jira/browse/AMBARI-24163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated AMBARI-24163: Labels: pull-request-available (was: ) > Infra Solr: solrDataManager.py should support transport data without > timestamp field > > > Key: AMBARI-24163 > URL: https://issues.apache.org/jira/browse/AMBARI-24163 > Project: Ambari > Issue Type: Bug > Components: ambari-infra >Affects Versions: 2.7.0 >Reporter: Olivér Szabó >Assignee: Olivér Szabó >Priority: Blocker > Labels: pull-request-available > Fix For: 2.7.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24163) Infra Solr: solrDataManager.py should support transport data without timestamp field
[ https://issues.apache.org/jira/browse/AMBARI-24163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivér Szabó updated AMBARI-24163: -- Summary: Infra Solr: solrDataManager.py should support transport data without timestamp field (was: Infra Solr: solrDataManager.py should support transport data without date field) > Infra Solr: solrDataManager.py should support transport data without > timestamp field > > > Key: AMBARI-24163 > URL: https://issues.apache.org/jira/browse/AMBARI-24163 > Project: Ambari > Issue Type: Bug > Components: ambari-infra >Affects Versions: 2.7.0 >Reporter: Olivér Szabó >Assignee: Olivér Szabó >Priority: Blocker > Fix For: 2.7.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMBARI-24163) Infra Solr: solrDataManager.py should support transport data without date field
Olivér Szabó created AMBARI-24163: - Summary: Infra Solr: solrDataManager.py should support transport data without date field Key: AMBARI-24163 URL: https://issues.apache.org/jira/browse/AMBARI-24163 Project: Ambari Issue Type: Bug Components: ambari-infra Affects Versions: 2.7.0 Reporter: Olivér Szabó Assignee: Olivér Szabó Fix For: 2.7.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMBARI-24162) Support for cluster-settings (remove cluster-env)
Balázs Bence Sári created AMBARI-24162: -- Summary: Support for cluster-settings (remove cluster-env) Key: AMBARI-24162 URL: https://issues.apache.org/jira/browse/AMBARI-24162 Project: Ambari Issue Type: Task Components: ambari-server Affects Versions: 3.0.0 Reporter: Balázs Bence Sári Assignee: Balázs Bence Sári Fix For: 3.0.0 Per the configuration refactoring occuring for Management Pack support, all configuration types will be scoped at the service level, rather than at the cluster level. The Blueprint processor will need to be updated, in order to treat all configuration at the service level. The Blueprint processor will need to take the configuration specified in a Blueprint, and convert this (where possible) to a service-level configuration in the internal representation of the configuration. The Blueprint processor will need to implement support for "cluster-settings", which replaces the "cluster-env" configuration type. We should accept older Blueprints with "cluster-env", and make the necessary conversions on the server side during deployment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMBARI-23009) Refactor Repository/Desired FK for All Tables
[
https://issues.apache.org/jira/browse/AMBARI-23009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley resolved AMBARI-23009.
--
Resolution: Fixed
> Refactor Repository/Desired FK for All Tables
> -
>
> Key: AMBARI-23009
> URL: https://issues.apache.org/jira/browse/AMBARI-23009
> Project: Ambari
> Issue Type: Epic
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Attachments: ERD.png
>
>
> We need to remove/refactor the {{repo_version}} table. This means the
> relationships tied to {{repo_version}} will also need to be replaced. Some of
> the high-level work items are:
> - Associate MPack's with Repositories
> - Remove {{host_version}} and add new relationships for mpack installations
> on hosts
> - Change Upgrades to track Mpacks not repos
> !ERD.png!
> \\
> - Removed repo_version table as it no longer serves a purpose (multiple
> mpacks of different versions can now come from the same repo)
> - Replaced the {{host_version}} table with {{mpack_host_state}} to represent
> whether an mpack was correct installed on appropriate hosts
> - Changed upgrade history to track the differences between 2 mpacks for a
> service group. This links back to an upgrade as well so we can have 2 SG's
> with 2 mpack source/targets in a single upgrade (think HDPCore and EDW in 1
> upgrade plan)
> The entity associations would look like:
> {code}
> /*
> Each Mpack has a collection of OS's, each OS with different URLs
> Redhat6, Redhat7, Ubuntu12
> */
> MPackEntity.getRepos() -> List
> /*
> The OS can have any number of URLs
> HDP: http://repo.ambari.apache.org/hdp
> HDP-UTILS: http://repo.ambari.apache.org/hdp-utils
> HDP-GPL: http://repo.ambari.apache.org/hdp-gpl
> */
> RepoOsEntity.getRepoDefinitions() -> List
> /*
> HDP-Core-Default
> Mpack 3.0.0.0 -> 3.0.0.1
> MPack 3.0.0.1 -> 3.1.0.0
> */
> ServiceGroupEntity.getUpgradeHistory() -> List
> UpgradeHistoryEntity.getSourceMPack() -> MPackEntity
> UpgradeHistoryEntity.getTargetMPack() -> MPackEntity
> /*
> Mpack HDP Core 3.0.0.0 -> Hosts 1, 2, and 3 are OK
> Mpack HDP Core 3.1.0.0 -> Hosts 1 and 2 are OK, Host 3 is INSTALL_FAILED
> */
> MPackEntity.getHostInstallState() -> List
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (AMBARI-24156) Remove RepositoryVersionEntity and Begin Switching Checks To Use UpgradePlan
[
https://issues.apache.org/jira/browse/AMBARI-24156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley resolved AMBARI-24156.
--
Resolution: Fixed
> Remove RepositoryVersionEntity and Begin Switching Checks To Use UpgradePlan
>
>
> Key: AMBARI-24156
> URL: https://issues.apache.org/jira/browse/AMBARI-24156
> Project: Ambari
> Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Critical
> Labels: pull-request-available
> Fix For: 3.0.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> This commit includes the following changes:
> - Final removal of all {{RepositoryVersionEntity}} references
> - Switching pre-upgrade checks over to using an Upgrade Plan
> -- Mostly just giving them a {{null}} plan
> -- In some cases, iterating over Service Groups to get the source/target
> mpacks
> - Cleaning up a lot of much in the pre-checks to make them cleaner and easier
> to extend by mpacks
> - Removal of reliance on a single Upgrade Pack in the pre-checks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24158) Provide a way to disable topology validation in cluster creation request
[
https://issues.apache.org/jira/browse/AMBARI-24158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated AMBARI-24158:
Labels: pull-request-available (was: )
> Provide a way to disable topology validation in cluster creation request
>
>
> Key: AMBARI-24158
> URL: https://issues.apache.org/jira/browse/AMBARI-24158
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Affects Versions: 3.0.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.0.0
>
>
> The topology validation that takes place during blueprint creation request
> can be disabled by passing {{validate_topology=false}} as query param.
> Validation also has a side-effect of adding any auto-deployable
> components/dependencies to the topology.
> For mpack-based deployment most of the validation is moved to the cluster
> creation request, since mpacks may not be available prior to that. We need
> to provide a way to disable validation in this request, too. Using the same
> {{validate_topology=false}} flag may be the best for this purpose.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AMBARI-24161) Cannot distinguish components on Host Details page due to shortened display name (Ambari should show full component name on mouse over)
Yesha Vora created AMBARI-24161: --- Summary: Cannot distinguish components on Host Details page due to shortened display name (Ambari should show full component name on mouse over) Key: AMBARI-24161 URL: https://issues.apache.org/jira/browse/AMBARI-24161 Project: Ambari Issue Type: Bug Reporter: Yesha Vora Yarn has 2 version of timeline service . 1) TIMELINE SERVICE V1.5 2) TIMELINE SERVICE V2.0 READER When both of these services are installed on one host, go to Component page . Component Page only shows first few chars "Timeline Service... ". Ambari UI shows "Timeline Service.." for both Timeline service 1.5 and 2.0 . Thus, user can not identify which is Timeline service 1.5 or 2.0 ambari should show the full component name when user brings mouse pointer on the component name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-24157) Backup External Metastore Database Task should communicate properly with the user
[ https://issues.apache.org/jira/browse/AMBARI-24157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519534#comment-16519534 ] Hudson commented on AMBARI-24157: - FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #9502 (See [https://builds.apache.org/job/Ambari-trunk-Commit/9502/]) AMBARI-24157 Backup External Metastore Database Task should communicate (mgergely: [https://gitbox.apache.org/repos/asf?p=ambari.git=commit=fa1542dd7f703bace1b3642f500ee2b241cdd46d]) * (edit) ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/pre_upgrade.py > Backup External Metastore Database Task should communicate properly with the > user > - > > Key: AMBARI-24157 > URL: https://issues.apache.org/jira/browse/AMBARI-24157 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.7.0 >Reporter: Miklos Gergely >Assignee: Miklos Gergely >Priority: Blocker > Labels: pull-request-available > Fix For: 2.7.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > In case of external Hive database the backup step should not fail if the db > is not found, but there should be an additional step telling the user that > they should check the previous step's log if the backup was successful. If it > wasn't, then they should follow the instructions to do the backup manually. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMBARI-24085) setup-sso in Ambari fails when SSL is enabled
[
https://issues.apache.org/jira/browse/AMBARI-24085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas resolved AMBARI-24085.
---
Resolution: Fixed
> setup-sso in Ambari fails when SSL is enabled
> -
>
> Key: AMBARI-24085
> URL: https://issues.apache.org/jira/browse/AMBARI-24085
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.7.0
>Reporter: SuryaKranthi Koneru
>Assignee: Robert Levas
>Priority: Critical
> Labels: pull-request-available
> Fix For: 2.7.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When SSL is enabled and the python version is 2.7.14, accessing the Ambari
> server via the {{ambari-server}} CLI fails with CERTIFICATE_VERIFY_FAILED.
>
> {noformat:title=Example}
> -bash-4.2# ambari-server setup-sso -v
> Using python /usr/bin/python
> Setting up SSO authentication properties...
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> INFO: Setup SSO.
> INFO: about to run command: ps -p 33705
> INFO:
> process_pid=107113
> INFO: Loading properties from /etc/ambari-server/conf/ambari.properties
> Enter Ambari Admin login: admin
> Enter Ambari Admin password:
> INFO: Fetching SSO configuration from DB
> INFO: Fetching information from Ambari's REST API
> Traceback (most recent call last):
> File "/usr/sbin/ambari-server.py", line 1056, in
> mainBody()
> File "/usr/sbin/ambari-server.py", line 1026, in mainBody
> main(options, args, parser)
> File "/usr/sbin/ambari-server.py", line 976, in main
> action_obj.execute()
> File "/usr/sbin/ambari-server.py", line 90, in execute
> self.need_restart = self.fn(*self.args, **self.kwargs)
> File "/usr/lib/ambari-server/lib/ambari_server/setupSso.py", line 266, in
> setup_sso
> properties = get_sso_properties(ambari_properties, admin_login,
> admin_password)
> File "/usr/lib/ambari-server/lib/ambari_server/setupSso.py", line 221, in
> get_sso_properties
> response_code, json_data = get_json_via_rest_api(properties, admin_login,
> admin_password, SSO_CONFIG_API_ENTRYPOINT)
> File "/usr/lib/ambari-server/lib/ambari_server/serverUtils.py", line 206, in
> get_json_via_rest_api
> with closing(urllib2.urlopen(request)) as response:
> File "/usr/lib64/python2.7/urllib2.py", line 154, in urlopen
> return opener.open(url, data, timeout)
> File "/usr/lib64/python2.7/urllib2.py", line 429, in open
> response = self._open(req, data)
> File "/usr/lib64/python2.7/urllib2.py", line 447, in _open
> '_open', req)
> File "/usr/lib64/python2.7/urllib2.py", line 407, in _call_chain
> result = func(*args)
> File "/usr/lib64/python2.7/urllib2.py", line 1243, in https_open
> context=self._context)
> File "/usr/lib64/python2.7/urllib2.py", line 1200, in do_open
> raise URLError(err)
> urllib2.URLError: verify failed (_ssl.c:661)>
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (AMBARI-24157) Backup External Metastore Database Task should communicate properly with the user
[ https://issues.apache.org/jira/browse/AMBARI-24157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miklos Gergely resolved AMBARI-24157. - Resolution: Fixed > Backup External Metastore Database Task should communicate properly with the > user > - > > Key: AMBARI-24157 > URL: https://issues.apache.org/jira/browse/AMBARI-24157 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.7.0 >Reporter: Miklos Gergely >Assignee: Miklos Gergely >Priority: Blocker > Labels: pull-request-available > Fix For: 2.7.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > In case of external Hive database the backup step should not fail if the db > is not found, but there should be an additional step telling the user that > they should check the previous step's log if the backup was successful. If it > wasn't, then they should follow the instructions to do the backup manually. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-24146) Metrics migrated during AMS upgrade are not saved into metadata table
[ https://issues.apache.org/jira/browse/AMBARI-24146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519423#comment-16519423 ] Hudson commented on AMBARI-24146: - FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #9501 (See [https://builds.apache.org/job/Ambari-trunk-Commit/9501/]) [AMBARI-24146] Metrics migrated during AMS upgrade are not saved into… (github: [https://gitbox.apache.org/repos/asf?p=ambari.git=commit=736722dfd28e2acb480ad45d2d4b3ba8b8f609bb]) * (edit) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/ambari/metrics/core/timeline/upgrade/core/MetricsDataMigrationLauncher.java * (edit) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/ambari/metrics/core/timeline/PhoenixHBaseAccessor.java * (edit) ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/TimelineMetricMetadata.java * (edit) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/ambari/metrics/core/timeline/discovery/TimelineMetricMetadataManager.java * (edit) ambari-metrics/ambari-metrics-timelineservice/src/main/java/org/apache/ambari/metrics/core/timeline/query/PhoenixTransactSQL.java > Metrics migrated during AMS upgrade are not saved into metadata table > - > > Key: AMBARI-24146 > URL: https://issues.apache.org/jira/browse/AMBARI-24146 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.7.0 >Reporter: Dmytro Sen >Assignee: Dmytro Sen >Priority: Blocker > Labels: pull-request-available > Fix For: 2.7.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > the data migration itself works, but the UUIDs calculated for those metrics > are not inserted into METADATA_UUID table > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-24160) Inaccurate error message showed during service removal in some circumstances
[ https://issues.apache.org/jira/browse/AMBARI-24160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519379#comment-16519379 ] Hudson commented on AMBARI-24160: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #9500 (See [https://builds.apache.org/job/Ambari-trunk-Commit/9500/]) [AMBARI-24160] Inaccurate error message showed during service removal in (hapy.lestat: [https://gitbox.apache.org/repos/asf?p=ambari.git=commit=303ba2e18eebcb3aa7d89104a1b2ecff702b44b4]) * (edit) ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ServiceResourceProvider.java > Inaccurate error message showed during service removal in some circumstances > -- > > Key: AMBARI-24160 > URL: https://issues.apache.org/jira/browse/AMBARI-24160 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.7.0 >Reporter: Dmytro Grinenko >Assignee: Dmytro Grinenko >Priority: Blocker > Labels: pull-request-available > Fix For: 2.7.0 > > Time Spent: 40m > Remaining Estimate: 0h > > When stop action for removed service failed and after this were posted DELETE > request through API, error message will display desired status of the > component instead of the current -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-24153) Customize Service step issues
[ https://issues.apache.org/jira/browse/AMBARI-24153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519371#comment-16519371 ] Andrii Tkach commented on AMBARI-24153: --- committed to trunk > Customize Service step issues > - > > Key: AMBARI-24153 > URL: https://issues.apache.org/jira/browse/AMBARI-24153 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.7.0 >Reporter: Andrii Tkach >Assignee: Andrii Tkach >Priority: Blocker > Labels: pull-request-available > Fix For: 2.7.0 > > Attachments: Screen Shot 2018-06-19 at 6.38.49 AM.png, Screen Shot > 2018-06-19 at 7.02.25 AM.png, > screencapture-104-196-91-59-8080-2018-06-19-06_36_27 (1).png > > Time Spent: 40m > Remaining Estimate: 0h > > There are some issues in Step 7 of the Installer Wizard > 1. Even if there are some *required* changes in the 'Database' tab it allows > to go to the next step. Next should only be enabled if the required property > has been provided with an input > 2. If there are some CRITICAL errors, the top notification bell should be > 'Red' (similar to what we see if there is an empty required property) > 3. If I click on any of the above critical error properties it takes me to a > wrong page. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24160) Inaccurate error message showed during service removal in some circumstances
[ https://issues.apache.org/jira/browse/AMBARI-24160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmytro Grinenko updated AMBARI-24160: - Resolution: Fixed Status: Resolved (was: Patch Available) > Inaccurate error message showed during service removal in some circumstances > -- > > Key: AMBARI-24160 > URL: https://issues.apache.org/jira/browse/AMBARI-24160 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.7.0 >Reporter: Dmytro Grinenko >Assignee: Dmytro Grinenko >Priority: Blocker > Labels: pull-request-available > Fix For: 2.7.0 > > Time Spent: 40m > Remaining Estimate: 0h > > When stop action for removed service failed and after this were posted DELETE > request through API, error message will display desired status of the > component instead of the current -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24101) Blueprint MPack Auto-Download needs more detailed error reporting
[ https://issues.apache.org/jira/browse/AMBARI-24101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balázs Bence Sári updated AMBARI-24101: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Blueprint MPack Auto-Download needs more detailed error reporting > - > > Key: AMBARI-24101 > URL: https://issues.apache.org/jira/browse/AMBARI-24101 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 3.0.0 >Reporter: Balázs Bence Sári >Assignee: Balázs Bence Sári >Priority: Major > Labels: pull-request-available > Fix For: 3.0.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The current error message does indicate which MPack is causing the issue, and > the ambari-server logs do show the exceptions causing the problem, but it > might be a good idea to make this error more obvious in the client error > message as well. > This JIRA tracks the work to investigate this problem, to determine if more > error-related information can be added to the client response when failures > of this type are detected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24160) Inaccurate error message showed during service removal in some circumstances
[ https://issues.apache.org/jira/browse/AMBARI-24160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmytro Grinenko updated AMBARI-24160: - Status: Patch Available (was: In Progress) > Inaccurate error message showed during service removal in some circumstances > -- > > Key: AMBARI-24160 > URL: https://issues.apache.org/jira/browse/AMBARI-24160 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.7.0 >Reporter: Dmytro Grinenko >Assignee: Dmytro Grinenko >Priority: Blocker > Labels: pull-request-available > Fix For: 2.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > When stop action for removed service failed and after this were posted DELETE > request through API, error message will display desired status of the > component instead of the current -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24160) Inaccurate error message showed during service removal in some circumstances
[ https://issues.apache.org/jira/browse/AMBARI-24160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated AMBARI-24160: Labels: pull-request-available (was: ) > Inaccurate error message showed during service removal in some circumstances > -- > > Key: AMBARI-24160 > URL: https://issues.apache.org/jira/browse/AMBARI-24160 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.7.0 >Reporter: Dmytro Grinenko >Assignee: Dmytro Grinenko >Priority: Blocker > Labels: pull-request-available > Fix For: 2.7.0 > > > When stop action for removed service failed and after this were posted DELETE > request through API, error message will display desired status of the > component instead of the current -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMBARI-24160) Inaccurate error message showed during service removal in some circumstances
Dmytro Grinenko created AMBARI-24160: Summary: Inaccurate error message showed during service removal in some circumstances Key: AMBARI-24160 URL: https://issues.apache.org/jira/browse/AMBARI-24160 Project: Ambari Issue Type: Bug Affects Versions: 2.7.0 Reporter: Dmytro Grinenko Assignee: Dmytro Grinenko Fix For: 2.7.0 When stop action for removed service failed and after this were posted DELETE request through API, error message will display desired status of the component instead of the current -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-24159) SSL connection error while registering hosts
[ https://issues.apache.org/jira/browse/AMBARI-24159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519229#comment-16519229 ] Valencia Edna Serrao commented on AMBARI-24159: --- I have found a workaround for this issue at [https://community.hortonworks.com/articles/188269/javapython-updates-and-ambari-agent-tls-settings.html.] Workaround: edit file /etc/amabri-agent/conf/ambari-agent.ini file [security] force_https_protocol=PROTOCOL_TLSv1_2 It would be great to know whether we can have a fix for this issue in upcoming Ambari versions. > SSL connection error while registering hosts > > > Key: AMBARI-24159 > URL: https://issues.apache.org/jira/browse/AMBARI-24159 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.6.1 > Environment: Java : # java -version > openjdk version "1.8.0_171" > OpenJDK Runtime Environment (build 1.8.0_171-b10) > OpenJDK 64-Bit Server VM (build 25.171-b10, mixed mode) > Python : # python --version > Python 2.7.5 > >Reporter: Valencia Edna Serrao >Priority: Major > Labels: TLS1.2, ambari-agent, security > > I'm working with ambari v2.6.1.5-3. While registering hosts, following error > is reported in the ambari-agent logs: > INFO 2018-06-21 10:14:00,524 NetUtil.py:70 - Connecting to > [https://testvm:8440/ca] > ERROR 2018-06-21 10:14:00,532 NetUtil.py:96 - EOF occurred in violation of > protocol (_ssl.c:579) > ERROR 2018-06-21 10:14:00,533 NetUtil.py:97 - SSLError: Failed to connect. > Please check openssl library versions. > Refer to: [https://bugzilla.redhat.com/show_bug.cgi?id=1022468] for more > details. > WARNING 2018-06-21 10:14:00,533 NetUtil.py:124 - Server at > [https://testvm:8440|https://testvm:8440/] is not reachable, sleeping for 10 > seconds... > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMBARI-24159) SSL connection error while registering hosts
[ https://issues.apache.org/jira/browse/AMBARI-24159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valencia Edna Serrao updated AMBARI-24159: -- Description: I'm working with ambari v2.6.1.5-3. While registering hosts, following error is reported in the ambari-agent logs: INFO 2018-06-21 10:14:00,524 NetUtil.py:70 - Connecting to [https://testvm:8440/ca] ERROR 2018-06-21 10:14:00,532 NetUtil.py:96 - EOF occurred in violation of protocol (_ssl.c:579) ERROR 2018-06-21 10:14:00,533 NetUtil.py:97 - SSLError: Failed to connect. Please check openssl library versions. Refer to: [https://bugzilla.redhat.com/show_bug.cgi?id=1022468] for more details. WARNING 2018-06-21 10:14:00,533 NetUtil.py:124 - Server at [https://testvm:8440|https://testvm:8440/] is not reachable, sleeping for 10 seconds... was: I'm working with ambari v2.6.1.5-3, while registering hosts, following error is reported in the ambari-agent logs: INFO 2018-06-21 10:14:00,524 NetUtil.py:70 - Connecting to https://testvm:8440/ca ERROR 2018-06-21 10:14:00,532 NetUtil.py:96 - EOF occurred in violation of protocol (_ssl.c:579) ERROR 2018-06-21 10:14:00,533 NetUtil.py:97 - SSLError: Failed to connect. Please check openssl library versions. Refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1022468 for more details. WARNING 2018-06-21 10:14:00,533 NetUtil.py:124 - Server at https://testvm:8440 is not reachable, sleeping for 10 seconds... > SSL connection error while registering hosts > > > Key: AMBARI-24159 > URL: https://issues.apache.org/jira/browse/AMBARI-24159 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.6.1 > Environment: Java : # java -version > openjdk version "1.8.0_171" > OpenJDK Runtime Environment (build 1.8.0_171-b10) > OpenJDK 64-Bit Server VM (build 25.171-b10, mixed mode) > Python : # python --version > Python 2.7.5 > >Reporter: Valencia Edna Serrao >Priority: Major > Labels: TLS1.2, ambari-agent, security > > I'm working with ambari v2.6.1.5-3. While registering hosts, following error > is reported in the ambari-agent logs: > INFO 2018-06-21 10:14:00,524 NetUtil.py:70 - Connecting to > [https://testvm:8440/ca] > ERROR 2018-06-21 10:14:00,532 NetUtil.py:96 - EOF occurred in violation of > protocol (_ssl.c:579) > ERROR 2018-06-21 10:14:00,533 NetUtil.py:97 - SSLError: Failed to connect. > Please check openssl library versions. > Refer to: [https://bugzilla.redhat.com/show_bug.cgi?id=1022468] for more > details. > WARNING 2018-06-21 10:14:00,533 NetUtil.py:124 - Server at > [https://testvm:8440|https://testvm:8440/] is not reachable, sleeping for 10 > seconds... > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMBARI-24159) SSL connection error while registering hosts
Valencia Edna Serrao created AMBARI-24159: - Summary: SSL connection error while registering hosts Key: AMBARI-24159 URL: https://issues.apache.org/jira/browse/AMBARI-24159 Project: Ambari Issue Type: Bug Components: ambari-agent Affects Versions: 2.6.1 Environment: Java : # java -version openjdk version "1.8.0_171" OpenJDK Runtime Environment (build 1.8.0_171-b10) OpenJDK 64-Bit Server VM (build 25.171-b10, mixed mode) Python : # python --version Python 2.7.5 Reporter: Valencia Edna Serrao I'm working with ambari v2.6.1.5-3, while registering hosts, following error is reported in the ambari-agent logs: INFO 2018-06-21 10:14:00,524 NetUtil.py:70 - Connecting to https://testvm:8440/ca ERROR 2018-06-21 10:14:00,532 NetUtil.py:96 - EOF occurred in violation of protocol (_ssl.c:579) ERROR 2018-06-21 10:14:00,533 NetUtil.py:97 - SSLError: Failed to connect. Please check openssl library versions. Refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1022468 for more details. WARNING 2018-06-21 10:14:00,533 NetUtil.py:124 - Server at https://testvm:8440 is not reachable, sleeping for 10 seconds... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMBARI-24158) Provide a way to disable topology validation in cluster creation request
Doroszlai, Attila created AMBARI-24158:
--
Summary: Provide a way to disable topology validation in cluster
creation request
Key: AMBARI-24158
URL: https://issues.apache.org/jira/browse/AMBARI-24158
Project: Ambari
Issue Type: Task
Components: ambari-server
Affects Versions: 3.0.0
Reporter: Doroszlai, Attila
Assignee: Doroszlai, Attila
Fix For: 3.0.0
The topology validation that takes place during blueprint creation request can
be disabled by passing {{validate_topology=false}} as query param. Validation
also has a side-effect of adding any auto-deployable components/dependencies to
the topology.
For mpack-based deployment most of the validation is moved to the cluster
creation request, since mpacks may not be available prior to that. We need to
provide a way to disable validation in this request, too. Using the same
{{validate_topology=false}} flag may be the best for this purpose.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-24149) Agent fails to auto-start HDFS when using LZO
[
https://issues.apache.org/jira/browse/AMBARI-24149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519101#comment-16519101
]
Hudson commented on AMBARI-24149:
-
FAILURE: Integrated in Jenkins build Ambari-branch-2.6 #692 (See
[https://builds.apache.org/job/Ambari-branch-2.6/692/])
AMBARI-24149. Agent fails to auto-start HDFS when using LZO (aonishuk)
(aonishuk:
[https://gitbox.apache.org/repos/asf?p=ambari.git=commit=039d95c27493b61d7141c6bc6c924870332cf63a])
* (edit)
ambari-common/src/main/python/resource_management/libraries/functions/lzo_utils.py
> Agent fails to auto-start HDFS when using LZO
> -
>
> Key: AMBARI-24149
> URL: https://issues.apache.org/jira/browse/AMBARI-24149
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.6.1
>Reporter: Doroszlai, Attila
>Assignee: Andrew Onischuk
>Priority: Major
> Labels: pull-request-available
> Attachments: AMBARI-24149.patch
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Service auto-start for HDFS fails with the following error when using LZO
> libraries:
> {noformat:title=auto_errors-...txt}
> ...
> File
> "/var/lib/ambari-agent/cache/common-services/HDFS/2.1.0.2.0/package/scripts/hdfs.py",
> line 137, in hdfs
> install_lzo_if_needed()
> File
> "/usr/lib/ambari-agent/lib/resource_management/libraries/functions/lzo_utils.py",
> line 87, in install_lzo_if_needed
> Script.repository_util.create_repo_files()
> File
> "/usr/lib/ambari-agent/lib/resource_management/libraries/functions/repository_util.py",
> line 53, in create_repo_files
> if self.command_repository.version_id is None:
> AttributeError: RepositoryUtil instance has no attribute 'command_repository'
> {noformat}
> {{repositoryFile}} entry is missing from auto-start commands.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMBARI-24149) Agent fails to auto-start HDFS when using LZO
[
https://issues.apache.org/jira/browse/AMBARI-24149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519085#comment-16519085
]
Andrew Onischuk commented on AMBARI-24149:
--
Committed to branch-2.6
> Agent fails to auto-start HDFS when using LZO
> -
>
> Key: AMBARI-24149
> URL: https://issues.apache.org/jira/browse/AMBARI-24149
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.6.1
>Reporter: Doroszlai, Attila
>Assignee: Andrew Onischuk
>Priority: Major
> Labels: pull-request-available
> Attachments: AMBARI-24149.patch
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Service auto-start for HDFS fails with the following error when using LZO
> libraries:
> {noformat:title=auto_errors-...txt}
> ...
> File
> "/var/lib/ambari-agent/cache/common-services/HDFS/2.1.0.2.0/package/scripts/hdfs.py",
> line 137, in hdfs
> install_lzo_if_needed()
> File
> "/usr/lib/ambari-agent/lib/resource_management/libraries/functions/lzo_utils.py",
> line 87, in install_lzo_if_needed
> Script.repository_util.create_repo_files()
> File
> "/usr/lib/ambari-agent/lib/resource_management/libraries/functions/repository_util.py",
> line 53, in create_repo_files
> if self.command_repository.version_id is None:
> AttributeError: RepositoryUtil instance has no attribute 'command_repository'
> {noformat}
> {{repositoryFile}} entry is missing from auto-start commands.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (AMBARI-24149) Agent fails to auto-start HDFS when using LZO
[
https://issues.apache.org/jira/browse/AMBARI-24149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doroszlai, Attila reassigned AMBARI-24149:
--
Assignee: Andrew Onischuk
> Agent fails to auto-start HDFS when using LZO
> -
>
> Key: AMBARI-24149
> URL: https://issues.apache.org/jira/browse/AMBARI-24149
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.6.1
>Reporter: Doroszlai, Attila
>Assignee: Andrew Onischuk
>Priority: Major
> Labels: pull-request-available
> Attachments: AMBARI-24149.patch
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Service auto-start for HDFS fails with the following error when using LZO
> libraries:
> {noformat:title=auto_errors-...txt}
> ...
> File
> "/var/lib/ambari-agent/cache/common-services/HDFS/2.1.0.2.0/package/scripts/hdfs.py",
> line 137, in hdfs
> install_lzo_if_needed()
> File
> "/usr/lib/ambari-agent/lib/resource_management/libraries/functions/lzo_utils.py",
> line 87, in install_lzo_if_needed
> Script.repository_util.create_repo_files()
> File
> "/usr/lib/ambari-agent/lib/resource_management/libraries/functions/repository_util.py",
> line 53, in create_repo_files
> if self.command_repository.version_id is None:
> AttributeError: RepositoryUtil instance has no attribute 'command_repository'
> {noformat}
> {{repositoryFile}} entry is missing from auto-start commands.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24149) Agent fails to auto-start HDFS when using LZO
[
https://issues.apache.org/jira/browse/AMBARI-24149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doroszlai, Attila updated AMBARI-24149:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Agent fails to auto-start HDFS when using LZO
> -
>
> Key: AMBARI-24149
> URL: https://issues.apache.org/jira/browse/AMBARI-24149
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.6.1
>Reporter: Doroszlai, Attila
>Assignee: Andrew Onischuk
>Priority: Major
> Labels: pull-request-available
> Attachments: AMBARI-24149.patch
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Service auto-start for HDFS fails with the following error when using LZO
> libraries:
> {noformat:title=auto_errors-...txt}
> ...
> File
> "/var/lib/ambari-agent/cache/common-services/HDFS/2.1.0.2.0/package/scripts/hdfs.py",
> line 137, in hdfs
> install_lzo_if_needed()
> File
> "/usr/lib/ambari-agent/lib/resource_management/libraries/functions/lzo_utils.py",
> line 87, in install_lzo_if_needed
> Script.repository_util.create_repo_files()
> File
> "/usr/lib/ambari-agent/lib/resource_management/libraries/functions/repository_util.py",
> line 53, in create_repo_files
> if self.command_repository.version_id is None:
> AttributeError: RepositoryUtil instance has no attribute 'command_repository'
> {noformat}
> {{repositoryFile}} entry is missing from auto-start commands.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMBARI-24157) Backup External Metastore Database Task should communicate properly with the user
[ https://issues.apache.org/jira/browse/AMBARI-24157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated AMBARI-24157: Labels: pull-request-available (was: ) > Backup External Metastore Database Task should communicate properly with the > user > - > > Key: AMBARI-24157 > URL: https://issues.apache.org/jira/browse/AMBARI-24157 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.7.0 >Reporter: Miklos Gergely >Assignee: Miklos Gergely >Priority: Blocker > Labels: pull-request-available > Fix For: 2.7.0 > > > In case of external Hive database the backup step should not fail if the db > is not found, but there should be an additional step telling the user that > they should check the previous step's log if the backup was successful. If it > wasn't, then they should follow the instructions to do the backup manually. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMBARI-24157) Backup External Metastore Database Task should communicate properly with the user
Miklos Gergely created AMBARI-24157: --- Summary: Backup External Metastore Database Task should communicate properly with the user Key: AMBARI-24157 URL: https://issues.apache.org/jira/browse/AMBARI-24157 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.7.0 Reporter: Miklos Gergely Assignee: Miklos Gergely Fix For: 2.7.0 In case of external Hive database the backup step should not fail if the db is not found, but there should be an additional step telling the user that they should check the previous step's log if the backup was successful. If it wasn't, then they should follow the instructions to do the backup manually. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
