[jira] [Commented] (AMBARI-25683) Releasing Ambari 2.7.6

2021-10-06 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-25683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17425355#comment-17425355
 ] 

Dmytro Grinenko commented on AMBARI-25683:
--

[~szabi] the basics are same, however the bits about upgrade are missing. 

It would be good to take and working 2.6 stack scripts, strip all the custom 
logic ang create from it an  example skeleton for the custom stacks

> Releasing Ambari 2.7.6 
> ---
>
> Key: AMBARI-25683
> URL: https://issues.apache.org/jira/browse/AMBARI-25683
> Project: Ambari
>  Issue Type: Task
>Affects Versions: 2.7.6
>Reporter: Szabolcs Béki
>Assignee: Szilard Antal
>Priority: Major
> Fix For: 2.7.6
>
>
> Long time no release. It's time change that. :)
> This task is created to encompass all the activities needed to release 
> [Ambari 
> 2.7.6|https://issues.apache.org/jira/projects/AMBARI/versions/12346843]. 
> [branch-2.7|https://github.com/apache/ambari/tree/branch-2.7]  includes some 
> important vulnerability fixes and also has fixes to make Ambari decoupled 
> from HDP. This became necessary as all versions of HDP repositories are 
> pushed [behind 
> paywall|https://www.cloudera.com/downloads/paywall-expansion.html], making 
> this and all previous Ambari versions unusable for typical users in their 
> current form.
> The proposal is to release Ambari after testing and documentation updates,  
> *as is*. 
> Uses cases for Ambari 2.7.6 : 
>  * Users having local HDP 3.1.x repositories can continue using it with 
> Ambari 2.7.6
>  * Users having their [custom services and stack 
> definition|https://cwiki.apache.org/confluence/display/AMBARI/Defining+a+Custom+Stack+and+Services]
>  * Users using Ambari indirectly inside other distributions like in 
> [BigTop|https://bigtop.apache.org/]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25635) Clear Cluster and METRIC_AGGREGATORS MBeans upon shutdown

2021-04-27 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25635.
--
Resolution: Fixed

> Clear Cluster and METRIC_AGGREGATORS MBeans upon shutdown
> -
>
> Key: AMBARI-25635
> URL: https://issues.apache.org/jira/browse/AMBARI-25635
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.7.4, 2.7.5
>Reporter: Tamas Payer
>Assignee: Tamas Payer
>Priority: Major
>  Labels: HA, helix, metric-collector
> Fix For: 2.7.6
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Following warnings appear in metrics-collector.log upon startup.
> {code:java}
> javax.management.InstanceAlreadyExistsException: ClusterStatus: 
> cluster=ambari-metrics-cluster,instanceName=ctr-e153-1613480641811-87570-01-57.hwx.site_12001
>  at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
>  at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
>  at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
>  at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
>  at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
>  at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
>  at 
> org.apache.helix.monitoring.mbeans.ClusterStatusMonitor.register(ClusterStatusMonitor.java:172)
>  at 
> org.apache.helix.monitoring.mbeans.ClusterStatusMonitor.registerInstances(ClusterStatusMonitor.java:498)
>  at 
> org.apache.helix.monitoring.mbeans.ClusterStatusMonitor.setClusterInstanceStatus(ClusterStatusMonitor.java:220)
>  at 
> org.apache.helix.controller.stages.ReadClusterDataStage.process(ReadClusterDataStage.java:91)
>  at org.apache.helix.controller.pipeline.Pipeline.handle(Pipeline.java:48)
>  at 
> org.apache.helix.controller.GenericHelixController.handleEvent(GenericHelixController.java:295)
>  at 
> org.apache.helix.controller.GenericHelixController$ClusterEventProcessor.run(GenericHelixController.java:595)
> {code}
> and
> {code:java}
> 2021-03-09 23:15:53,450 INFO 
> org.apache.helix.monitoring.mbeans.ClusterStatusMonitor: Register MBean: 
> ClusterStatus: 
> cluster=ambari-metrics-cluster,instanceName=ctr-e153-1613480641811-87570-01-57.hwx.site_12001,resourceName=METRIC_AGGREGATORS
> 2021-03-09 23:15:53,450 INFO 
> org.apache.helix.monitoring.mbeans.ClusterStatusMonitor: Register MBean: 
> ClusterStatus: 
> cluster=ambari-metrics-cluster,instanceName=ctr-e153-1613480641811-87570-01-57.hwx.site_12001,resourceName=METRIC_AGGREGATORS
> 2021-03-09 23:15:53,450 WARN 
> org.apache.helix.monitoring.mbeans.ClusterStatusMonitor: Could not register 
> MBean: ClusterStatus: 
> cluster=ambari-metrics-cluster,instanceName=ctr-e153-1613480641811-87570-01-57.hwx.site_12001,resourceName=METRIC_AGGREGATORS
> javax.management.InstanceAlreadyExistsException: ClusterStatus: 
> cluster=ambari-metrics-cluster,instanceName=ctr-e153-1613480641811-87570-01-57.hwx.site_12001,resourceName=METRIC_AGGREGATORS
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.helix.monitoring.mbeans.ClusterStatusMonitor.register(ClusterStatusMonitor.java:172)
> at 
> org.apache.helix.monitoring.mbeans.ClusterStatusMonitor.registerPerInstanceResources(ClusterStatusMonitor.java:537)
> at 
> org.apache.helix.monitoring.mbeans.ClusterStatusMonitor.setPerInstanceResourceStatus(ClusterStatusMonitor.java:307)
> at 
> org.apache.helix.controller.stages.BestPossibleStateCalcStage.process(BestPossibleStateCalcStage.java:74)
> at 
> org.apache.helix.controller.pipeline.Pipeline.handle(Pipeline.java:48)
> at 
> org.apache.helix.controller.GenericHelixController.handleEvent(GenericHelixController.java:295)
> at 
> org.apache.helix.controller.GenericHelixController$ClusterEventProcessor.run(GenericHelixController.java:595)
> {code}



[jira] [Resolved] (AMBARI-25637) ConcurrentModificationException during stomp subscriptions processing

2021-03-29 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25637.
--
  Assignee: Dmytro Grinenko
Resolution: Fixed

> ConcurrentModificationException during stomp subscriptions processing
> -
>
> Key: AMBARI-25637
> URL: https://issues.apache.org/jira/browse/AMBARI-25637
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
>Reporter: Dmytro Vitiuk
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> AmbariSubscriptionRegistry$DestinationCache's accessCache is not always 
> processed thread-safely:
> {noformat}
> Exception in thread "clientInboundChannel-3" Exception in thread 
> "clientInboundChannel-11128" 
> org.springframework.messaging.MessageDeliveryException: Failed to handle 
> GenericMessage [payload=byte[0], headers={simpMessageType=DISCONNECT, 
> stompCommand=DISCONNECT, 
> nativeHeaders={receipt=[17ff2f6e-d783-416e-bbc5-ce7d16bf784b]}, 
> simpSessionAttributes={org.springframework.messaging.simp.SimpAttributes.COMPLETED=true},
>  simpHeartbeat=[J@3ed4c84a, 
> simpSessionId=d0b10fb8-4f24-9b44-f9b6-71a12baa18c2}] to 
> org.springframework.messaging.support.ExecutorSubscribableChannel$SendTask@301331e0
>  in SimpleBrokerMessageHandler [DefaultSubscriptionRegistry[cache[7378 
> destination(s)], registry[904 sessions]]]; nested exception is 
> java.util.ConcurrentModificationException, failedMessage=GenericMessage 
> [payload=byte[0], headers={simpMessageType=DISCONNECT, 
> stompCommand=DISCONNECT, 
> nativeHeaders={receipt=[17ff2f6e-d783-416e-bbc5-ce7d16bf784b]}, 
> simpSessionAttributes={org.springframework.messaging.simp.SimpAttributes.COMPLETED=true},
>  simpHeartbeat=[J@3ed4c84a, 
> simpSessionId=d0b10fb8-4f24-9b44-f9b6-71a12baa18c2}]
>   at 
> org.springframework.messaging.support.ExecutorSubscribableChannel$SendTask.run(ExecutorSubscribableChannel.java:153)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.util.ConcurrentModificationException
>   at 
> java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:719)
>   at 
> java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:752)
>   at 
> java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:750)
>   at java.util.Map.forEach(Map.java:620)
>   at 
> org.springframework.util.LinkedMultiValueMap.deepCopy(LinkedMultiValueMap.java:83)
>   at 
> org.apache.ambari.server.agent.stomp.AmbariSubscriptionRegistry$DestinationCache.updateAfterRemovedSession(AmbariSubscriptionRegistry.java:327)
>   at 
> org.apache.ambari.server.agent.stomp.AmbariSubscriptionRegistry.unregisterAllSubscriptions(AmbariSubscriptionRegistry.java:177)
>   at 
> org.springframework.messaging.simp.broker.SimpleBrokerMessageHandler.handleDisconnect(SimpleBrokerMessageHandler.java:368)
>   at 
> org.springframework.messaging.simp.broker.SimpleBrokerMessageHandler.handleMessageInternal(SimpleBrokerMessageHandler.java:330)
>   at 
> org.springframework.messaging.simp.broker.AbstractBrokerMessageHandler.handleMessage(AbstractBrokerMessageHandler.java:256)
>   at 
> org.springframework.messaging.support.ExecutorSubscribableChannel$SendTask.run(ExecutorSubscribableChannel.java:144)
>   ... 3 more
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (AMBARI-25639) StackOverflowError appears on MethodArgument*Exception during stomp message handling

2021-03-26 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko reassigned AMBARI-25639:


Assignee: Dmytro Grinenko

> StackOverflowError appears on MethodArgument*Exception during stomp message 
> handling
> 
>
> Key: AMBARI-25639
> URL: https://issues.apache.org/jira/browse/AMBARI-25639
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
>Reporter: Dmytro Vitiuk
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Sometimes StackOverflowError appears in a server logs:
> {noformat}
> 2021-03-22 17:24:14,318 ERROR [clientInboundChannel-6] 
> WebSocketAnnotationMethodMessageHandler:597 - Error while processing handler 
> method exception
> org.springframework.messaging.converter.MessageConversionException: Could not 
> write JSON: Infinite recursion (StackOverflowError) (through reference chain: 
> java.lang.reflect.Parameter["declaringExecutable"]->java.lang.reflect.Method["parameters"]->java.lang.reflect.Parameter[0]->java.lang.reflect.Parameter["declaringExecutable"]->java.lang.reflect.Method["parameters"]->java.lang.reflect.Parameter[0]->java.lang.reflect.Parameter["declaringExecutable"]->java.lang.reflect.Method["parameters"]->java.lang.reflect.Parameter[
> ...
>   at 
> org.springframework.messaging.converter.MappingJackson2MessageConverter.convertToInternal(MappingJackson2MessageConverter.java:284)
>   at 
> org.springframework.messaging.converter.AbstractMessageConverter.toMessage(AbstractMessageConverter.java:201)
>   at 
> org.springframework.messaging.converter.CompositeMessageConverter.toMessage(CompositeMessageConverter.java:96)
>   at 
> org.springframework.messaging.core.AbstractMessageSendingTemplate.doConvert(AbstractMessageSendingTemplate.java:181)
>   at 
> org.springframework.messaging.core.AbstractMessageSendingTemplate.convertAndSend(AbstractMessageSendingTemplate.java:150)
>   at 
> org.springframework.messaging.simp.SimpMessagingTemplate.convertAndSendToUser(SimpMessagingTemplate.java:229)
>   at 
> org.springframework.messaging.simp.SimpMessagingTemplate.convertAndSendToUser(SimpMessagingTemplate.java:211)
>   at 
> org.apache.ambari.server.api.AmbariSendToMethodReturnValueHandler.handleReturnValue(AmbariSendToMethodReturnValueHandler.java:84)
>   at 
> org.springframework.messaging.handler.invocation.HandlerMethodReturnValueHandlerComposite.handleReturnValue(HandlerMethodReturnValueHandlerComposite.java:127)
>   at 
> org.springframework.messaging.handler.invocation.AbstractMethodMessageHandler.processHandlerMethodException(AbstractMethodMessageHandler.java:594)
>   at 
> org.springframework.messaging.handler.invocation.AbstractMethodMessageHandler.handleMatch(AbstractMethodMessageHandler.java:566)
>   at 
> org.springframework.messaging.simp.annotation.support.SimpAnnotationMethodMessageHandler.handleMatch(SimpAnnotationMethodMessageHandler.java:510)
>   at 
> org.springframework.messaging.simp.annotation.support.SimpAnnotationMethodMessageHandler.handleMatch(SimpAnnotationMethodMessageHandler.java:94)
>   at 
> org.springframework.messaging.handler.invocation.AbstractMethodMessageHandler.handleMessageInternal(AbstractMethodMessageHandler.java:505)
>   at 
> org.springframework.messaging.handler.invocation.AbstractMethodMessageHandler.handleMessage(AbstractMethodMessageHandler.java:439)
>   at 
> org.springframework.messaging.support.ExecutorSubscribableChannel$SendTask.run(ExecutorSubscribableChannel.java:144)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Looks like we try to map some method's parameter to json from a stomp 
> response.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25639) StackOverflowError appears on MethodArgument*Exception during stomp message handling

2021-03-26 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25639.
--
Resolution: Fixed

> StackOverflowError appears on MethodArgument*Exception during stomp message 
> handling
> 
>
> Key: AMBARI-25639
> URL: https://issues.apache.org/jira/browse/AMBARI-25639
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
>Reporter: Dmytro Vitiuk
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Sometimes StackOverflowError appears in a server logs:
> {noformat}
> 2021-03-22 17:24:14,318 ERROR [clientInboundChannel-6] 
> WebSocketAnnotationMethodMessageHandler:597 - Error while processing handler 
> method exception
> org.springframework.messaging.converter.MessageConversionException: Could not 
> write JSON: Infinite recursion (StackOverflowError) (through reference chain: 
> java.lang.reflect.Parameter["declaringExecutable"]->java.lang.reflect.Method["parameters"]->java.lang.reflect.Parameter[0]->java.lang.reflect.Parameter["declaringExecutable"]->java.lang.reflect.Method["parameters"]->java.lang.reflect.Parameter[0]->java.lang.reflect.Parameter["declaringExecutable"]->java.lang.reflect.Method["parameters"]->java.lang.reflect.Parameter[
> ...
>   at 
> org.springframework.messaging.converter.MappingJackson2MessageConverter.convertToInternal(MappingJackson2MessageConverter.java:284)
>   at 
> org.springframework.messaging.converter.AbstractMessageConverter.toMessage(AbstractMessageConverter.java:201)
>   at 
> org.springframework.messaging.converter.CompositeMessageConverter.toMessage(CompositeMessageConverter.java:96)
>   at 
> org.springframework.messaging.core.AbstractMessageSendingTemplate.doConvert(AbstractMessageSendingTemplate.java:181)
>   at 
> org.springframework.messaging.core.AbstractMessageSendingTemplate.convertAndSend(AbstractMessageSendingTemplate.java:150)
>   at 
> org.springframework.messaging.simp.SimpMessagingTemplate.convertAndSendToUser(SimpMessagingTemplate.java:229)
>   at 
> org.springframework.messaging.simp.SimpMessagingTemplate.convertAndSendToUser(SimpMessagingTemplate.java:211)
>   at 
> org.apache.ambari.server.api.AmbariSendToMethodReturnValueHandler.handleReturnValue(AmbariSendToMethodReturnValueHandler.java:84)
>   at 
> org.springframework.messaging.handler.invocation.HandlerMethodReturnValueHandlerComposite.handleReturnValue(HandlerMethodReturnValueHandlerComposite.java:127)
>   at 
> org.springframework.messaging.handler.invocation.AbstractMethodMessageHandler.processHandlerMethodException(AbstractMethodMessageHandler.java:594)
>   at 
> org.springframework.messaging.handler.invocation.AbstractMethodMessageHandler.handleMatch(AbstractMethodMessageHandler.java:566)
>   at 
> org.springframework.messaging.simp.annotation.support.SimpAnnotationMethodMessageHandler.handleMatch(SimpAnnotationMethodMessageHandler.java:510)
>   at 
> org.springframework.messaging.simp.annotation.support.SimpAnnotationMethodMessageHandler.handleMatch(SimpAnnotationMethodMessageHandler.java:94)
>   at 
> org.springframework.messaging.handler.invocation.AbstractMethodMessageHandler.handleMessageInternal(AbstractMethodMessageHandler.java:505)
>   at 
> org.springframework.messaging.handler.invocation.AbstractMethodMessageHandler.handleMessage(AbstractMethodMessageHandler.java:439)
>   at 
> org.springframework.messaging.support.ExecutorSubscribableChannel$SendTask.run(ExecutorSubscribableChannel.java:144)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Looks like we try to map some method's parameter to json from a stomp 
> response.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25636) FindBugs: Comparison of String parameter using == or !=

2021-03-25 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25636.
--
Resolution: Fixed

> FindBugs: Comparison of String parameter using == or != 
> 
>
> Key: AMBARI-25636
> URL: https://issues.apache.org/jira/browse/AMBARI-25636
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.3, 2.7.4, 2.7.5
>Reporter: Tamas Payer
>Assignee: Tamas Payer
>Priority: Minor
>  Labels: cleanup, findbugs, server
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Fix FindBugs issue: Comparison of String parameter using == or != in 
> org.apache.ambari.server.state.host.HostImpl.setStatus(String)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25633) Get rid of ignored tests cases in TestHeartbeatHandler and related to the original change tests

2021-03-16 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25633:
-
Assignee: Dmytro Grinenko
  Status: Patch Available  (was: Open)

> Get rid of ignored tests cases in TestHeartbeatHandler and related to the 
> original change tests
> ---
>
> Key: AMBARI-25633
> URL: https://issues.apache.org/jira/browse/AMBARI-25633
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
>Reporter: Dmytro Vitiuk
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> TestHeartbeatHandler should be re-written regarding to implementation of 
> server-agent interaction with websockets.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25633) Get rid of ignored tests cases in TestHeartbeatHandler and related to the original change tests

2021-03-16 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25633:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Get rid of ignored tests cases in TestHeartbeatHandler and related to the 
> original change tests
> ---
>
> Key: AMBARI-25633
> URL: https://issues.apache.org/jira/browse/AMBARI-25633
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
>Reporter: Dmytro Vitiuk
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> TestHeartbeatHandler should be re-written regarding to implementation of 
> server-agent interaction with websockets.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (AMBARI-25634) Code cleanup: Remove AgentResource class as it is not needed anymore

2021-03-15 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko reassigned AMBARI-25634:


Assignee: Dmytro Grinenko

> Code cleanup: Remove AgentResource class as it is not needed anymore
> 
>
> Key: AMBARI-25634
> URL: https://issues.apache.org/jira/browse/AMBARI-25634
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
>Reporter: Dmytro Vitiuk
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> After moving to WebSockets, the HTTP REST handler not needed anymore.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25634) Code cleanup: Remove AgentResource class as it is not needed anymore

2021-03-15 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25634.
--
Resolution: Fixed

> Code cleanup: Remove AgentResource class as it is not needed anymore
> 
>
> Key: AMBARI-25634
> URL: https://issues.apache.org/jira/browse/AMBARI-25634
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
>Reporter: Dmytro Vitiuk
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After moving to WebSockets, the HTTP REST handler not needed anymore.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25630) Kerberization of the big cluster using Blueprints takes too much time

2021-03-15 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25630:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Kerberization of the big cluster using Blueprints takes too much time
> -
>
> Key: AMBARI-25630
> URL: https://issues.apache.org/jira/browse/AMBARI-25630
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server
>Affects Versions: 2.7.0
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Critical
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Several problems observed: 
> - Keytabs and Principals distribution is too slow
> - To much repeating requests to database
> - To extensive logging, which slows down the logic



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25630) Kerberization of the big cluster using Blueprints takes too much time

2021-03-10 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25630:
-
Status: Patch Available  (was: Open)

> Kerberization of the big cluster using Blueprints takes too much time
> -
>
> Key: AMBARI-25630
> URL: https://issues.apache.org/jira/browse/AMBARI-25630
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-server
>Affects Versions: 2.7.0
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Critical
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Several problems observed: 
> - Keytabs and Principals distribution is too slow
> - To much repeating requests to database
> - To extensive logging, which slows down the logic



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (AMBARI-25630) Kerberization of the big cluster using Blueprints takes too much time

2021-03-10 Thread Dmytro Grinenko (Jira)
Dmytro Grinenko created AMBARI-25630:


 Summary: Kerberization of the big cluster using Blueprints takes 
too much time
 Key: AMBARI-25630
 URL: https://issues.apache.org/jira/browse/AMBARI-25630
 Project: Ambari
  Issue Type: Improvement
  Components: ambari-server
Affects Versions: 2.7.0
Reporter: Dmytro Grinenko
Assignee: Dmytro Grinenko
 Fix For: 2.7.6


Several problems observed: 
- Keytabs and Principals distribution is too slow
- To much repeating requests to database
- To extensive logging, which slows down the logic




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25627) ORA-01795 error when querying hostcomponentdesiredstate table on large cluster

2021-03-10 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25627:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> ORA-01795 error when querying hostcomponentdesiredstate table on large cluster
> --
>
> Key: AMBARI-25627
> URL: https://issues.apache.org/jira/browse/AMBARI-25627
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Affects Versions: 2.7.4, 2.7.5, 2.7.6
>Reporter: Tamas Payer
>Assignee: Tamas Payer
>Priority: Critical
>  Labels: ambari-server, oracle
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Ambari server is not able to login because the server is querying Oracle DB 
> which has more than 1000 entries.
> {noformat}
> bind => [1173 parameters bound]
>  Query: 
> ReadAllQuery(name="HostComponentDesiredStateEntity.findByHostsAndCluster" 
> referenceClass=HostComponentDesiredStateEntity sql="SELECT id, admin_state, 
> blueprint_provisio
>  ning_state, cluster_id, component_name, desired_state, host_id, 
> maintenance_state, restart_required, service_name FROM 
> hostcomponentdesiredstate WHERE ((host_id IN ?) AND (clu
>  ster_id = ?))")
>  at 
> org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:340)
>  at 
>  ... 27 more
>  Caused by: java.sql.SQLSyntaxErrorException: ORA-01795: maximum number of 
> expressions in a list is 1000{noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25622) During Upgrade, Hive upgrade restart should verify if de-registering old Hive z-nodes in Zookeeper is still required

2021-02-23 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25622:
-
Description: 
In case if old Hive z-nodes were already de-registered  and user wanted to 
issue additional restarts with "upgrade restart" flag (for example during 
upgrade pause) - the command could fail as old z-nodes would be already 
de-registered. 

{code}
Execution of 'hive --config /usr/hdp/current/hive-server2/conf/conf.server 
--service hiveserver2 --deregister x.x..x.x.x.xxx-x' returned 255. 
log4j:WARN No such property [maxFileSize] in 
org.apache.log4j.DailyRollingFileAppender.
Error deregistering HiveServer2 instances for version: x.x..x.x.x.xxx-x 
from ZooKeeper.org.apache.zookeeper.KeeperException$NoNodeException: 
KeeperErrorCode = NoNode for /hiveserver2-sdm
Traceback (most recent call last):
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server.py",
 line 91, in stop
hive_server_upgrade.deregister()
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_upgrade.py",
 line 70, in deregister
Execute(command, user=params.hive_user, path=hive_execute_path, tries=1 )
  File "/usr/lib/ambari-agent/lib/resource_management/core/base.py", line 166, 
in __init__
self.env.run()
  File "/usr/lib/ambari-agent/lib/resource_management/core/environment.py", 
line 160, in run
self.run_action(resource, action)
  File "/usr/lib/ambari-agent/lib/resource_management/core/environment.py", 
line 124, in run_action
provider_action()
  File 
"/usr/lib/ambari-agent/lib/resource_management/core/providers/system.py", line 
262, in action_run
tries=self.resource.tries, try_sleep=self.resource.try_sleep)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 72, 
in inner
result = function(command, **kwargs)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 102, 
in checked_call
tries=tries, try_sleep=try_sleep, 
timeout_kill_strategy=timeout_kill_strategy)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 150, 
in _call_wrapper
result = _call(command, **kwargs_copy)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 303, 
in _call
raise ExecutionFailed(err_msg, code, out, err)
ExecutionFailed: Execution of 'hive --config 
/usr/hdp/current/hive-server2/conf/conf.server --service hiveserver2 
--deregister x.x..x.x.x.xxx-x' returned 255. log4j:WARN No such property 
[maxFileSize] in org.apache.log4j.DailyRollingFileAppender.
Error deregistering HiveServer2 instances for version: x.x..x.x.x.xxx-x 
from ZooKeeper.org.apache.zookeeper.KeeperException$NoNodeException: 
KeeperErrorCode = NoNode for /hiveserver2-sdm
{code}

The upgrade restart functionality for Hive should be enchanted to support this 
behaviour

  was:
In case if old Hive z-nodes were already de-registered  and user wanted to 
issue additional restarts with "upgrade restart" flag (for example during 
upgrade pause) - the command could fail as old z-nodes would be already 
de-registered. 
{code}
Execution of 'hive --config /usr/hdp/current/hive-server2/conf/conf.server 
--service hiveserver2 --deregister x.x..x.x.x.xxx-x' returned 255. 
log4j:WARN No such property [maxFileSize] in 
org.apache.log4j.DailyRollingFileAppender.
Error deregistering HiveServer2 instances for version: x.x..x.x.x.xxx-x 
from ZooKeeper.org.apache.zookeeper.KeeperException$NoNodeException: 
KeeperErrorCode = NoNode for /hiveserver2-sdm
Traceback (most recent call last):
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server.py",
 line 91, in stop
hive_server_upgrade.deregister()
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_upgrade.py",
 line 70, in deregister
Execute(command, user=params.hive_user, path=hive_execute_path, tries=1 )
  File "/usr/lib/ambari-agent/lib/resource_management/core/base.py", line 166, 
in __init__
self.env.run()
  File "/usr/lib/ambari-agent/lib/resource_management/core/environment.py", 
line 160, in run
self.run_action(resource, action)
  File "/usr/lib/ambari-agent/lib/resource_management/core/environment.py", 
line 124, in run_action
provider_action()
  File 
"/usr/lib/ambari-agent/lib/resource_management/core/providers/system.py", line 
262, in action_run
tries=self.resource.tries, try_sleep=self.resource.try_sleep)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 72, 
in inner
result = function(command, **kwargs)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 102, 
in checked_call
tries=tries, try_sleep=try_sleep, 
timeout_kill_strategy=timeout_kill_strategy)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 1

[jira] [Updated] (AMBARI-25622) During Upgrade, Hive upgrade restart should verify if de-registering old Hive z-nodes in Zookeeper is still required

2021-02-23 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25622:
-
Description: 
In case if old Hive z-nodes were already de-registered  and user wanted to 
issue additional restarts with "upgrade restart" flag (for example during 
upgrade pause) - the command could fail as old z-nodes would be already 
de-registered. 
{code}
Execution of 'hive --config /usr/hdp/current/hive-server2/conf/conf.server 
--service hiveserver2 --deregister x.x..x.x.x.xxx-x' returned 255. 
log4j:WARN No such property [maxFileSize] in 
org.apache.log4j.DailyRollingFileAppender.
Error deregistering HiveServer2 instances for version: x.x..x.x.x.xxx-x 
from ZooKeeper.org.apache.zookeeper.KeeperException$NoNodeException: 
KeeperErrorCode = NoNode for /hiveserver2-sdm
Traceback (most recent call last):
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server.py",
 line 91, in stop
hive_server_upgrade.deregister()
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_upgrade.py",
 line 70, in deregister
Execute(command, user=params.hive_user, path=hive_execute_path, tries=1 )
  File "/usr/lib/ambari-agent/lib/resource_management/core/base.py", line 166, 
in __init__
self.env.run()
  File "/usr/lib/ambari-agent/lib/resource_management/core/environment.py", 
line 160, in run
self.run_action(resource, action)
  File "/usr/lib/ambari-agent/lib/resource_management/core/environment.py", 
line 124, in run_action
provider_action()
  File 
"/usr/lib/ambari-agent/lib/resource_management/core/providers/system.py", line 
262, in action_run
tries=self.resource.tries, try_sleep=self.resource.try_sleep)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 72, 
in inner
result = function(command, **kwargs)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 102, 
in checked_call
tries=tries, try_sleep=try_sleep, 
timeout_kill_strategy=timeout_kill_strategy)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 150, 
in _call_wrapper
result = _call(command, **kwargs_copy)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 303, 
in _call
raise ExecutionFailed(err_msg, code, out, err)
ExecutionFailed: Execution of 'hive --config 
/usr/hdp/current/hive-server2/conf/conf.server --service hiveserver2 
--deregister x.x..x.x.x.xxx-x' returned 255. log4j:WARN No such property 
[maxFileSize] in org.apache.log4j.DailyRollingFileAppender.
Error deregistering HiveServer2 instances for version: x.x..x.x.x.xxx-x 
from ZooKeeper.org.apache.zookeeper.KeeperException$NoNodeException: 
KeeperErrorCode = NoNode for /hiveserver2-sdm
{code}

The upgrade restart functionality for Hive should be enchanted to support this 
behaviour

  was:
In case if old Hive z-nodes were already de-registered  and user issue 
additional restarts with "upgrade restart" flag (for example during upgrade 
pause) - the command will fail as old z-nodes would be already de-registered. 
{code}
Execution of 'hive --config /usr/hdp/current/hive-server2/conf/conf.server 
--service hiveserver2 --deregister x.x..x.x.x.xxx-x' returned 255. 
log4j:WARN No such property [maxFileSize] in 
org.apache.log4j.DailyRollingFileAppender.
Error deregistering HiveServer2 instances for version: x.x..x.x.x.xxx-x 
from ZooKeeper.org.apache.zookeeper.KeeperException$NoNodeException: 
KeeperErrorCode = NoNode for /hiveserver2-sdm
Traceback (most recent call last):
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server.py",
 line 91, in stop
hive_server_upgrade.deregister()
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_upgrade.py",
 line 70, in deregister
Execute(command, user=params.hive_user, path=hive_execute_path, tries=1 )
  File "/usr/lib/ambari-agent/lib/resource_management/core/base.py", line 166, 
in __init__
self.env.run()
  File "/usr/lib/ambari-agent/lib/resource_management/core/environment.py", 
line 160, in run
self.run_action(resource, action)
  File "/usr/lib/ambari-agent/lib/resource_management/core/environment.py", 
line 124, in run_action
provider_action()
  File 
"/usr/lib/ambari-agent/lib/resource_management/core/providers/system.py", line 
262, in action_run
tries=self.resource.tries, try_sleep=self.resource.try_sleep)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 72, 
in inner
result = function(command, **kwargs)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 102, 
in checked_call
tries=tries, try_sleep=try_sleep, 
timeout_kill_strategy=timeout_kill_strategy)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 150, 
in _call

[jira] [Created] (AMBARI-25622) During Upgrade, Hive upgrade restart should verify if de-registering old Hive z-nodes in Zookeeper is still required

2021-02-23 Thread Dmytro Grinenko (Jira)
Dmytro Grinenko created AMBARI-25622:


 Summary: During Upgrade, Hive upgrade restart should verify if 
de-registering old Hive z-nodes in Zookeeper is still required
 Key: AMBARI-25622
 URL: https://issues.apache.org/jira/browse/AMBARI-25622
 Project: Ambari
  Issue Type: Improvement
  Components: ambari-agent
Affects Versions: 2.6.0
Reporter: Dmytro Grinenko
Assignee: Dmytro Grinenko
 Fix For: 2.7.6


In case if old Hive z-nodes were already de-registered  and user issue 
additional restarts with "upgrade restart" flag (for example during upgrade 
pause) - the command will fail as old z-nodes would be already de-registered. 
{code}
Execution of 'hive --config /usr/hdp/current/hive-server2/conf/conf.server 
--service hiveserver2 --deregister x.x..x.x.x.xxx-x' returned 255. 
log4j:WARN No such property [maxFileSize] in 
org.apache.log4j.DailyRollingFileAppender.
Error deregistering HiveServer2 instances for version: x.x..x.x.x.xxx-x 
from ZooKeeper.org.apache.zookeeper.KeeperException$NoNodeException: 
KeeperErrorCode = NoNode for /hiveserver2-sdm
Traceback (most recent call last):
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server.py",
 line 91, in stop
hive_server_upgrade.deregister()
  File 
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/hive_server_upgrade.py",
 line 70, in deregister
Execute(command, user=params.hive_user, path=hive_execute_path, tries=1 )
  File "/usr/lib/ambari-agent/lib/resource_management/core/base.py", line 166, 
in __init__
self.env.run()
  File "/usr/lib/ambari-agent/lib/resource_management/core/environment.py", 
line 160, in run
self.run_action(resource, action)
  File "/usr/lib/ambari-agent/lib/resource_management/core/environment.py", 
line 124, in run_action
provider_action()
  File 
"/usr/lib/ambari-agent/lib/resource_management/core/providers/system.py", line 
262, in action_run
tries=self.resource.tries, try_sleep=self.resource.try_sleep)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 72, 
in inner
result = function(command, **kwargs)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 102, 
in checked_call
tries=tries, try_sleep=try_sleep, 
timeout_kill_strategy=timeout_kill_strategy)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 150, 
in _call_wrapper
result = _call(command, **kwargs_copy)
  File "/usr/lib/ambari-agent/lib/resource_management/core/shell.py", line 303, 
in _call
raise ExecutionFailed(err_msg, code, out, err)
ExecutionFailed: Execution of 'hive --config 
/usr/hdp/current/hive-server2/conf/conf.server --service hiveserver2 
--deregister x.x..x.x.x.xxx-x' returned 255. log4j:WARN No such property 
[maxFileSize] in org.apache.log4j.DailyRollingFileAppender.
Error deregistering HiveServer2 instances for version: x.x..x.x.x.xxx-x 
from ZooKeeper.org.apache.zookeeper.KeeperException$NoNodeException: 
KeeperErrorCode = NoNode for /hiveserver2-sdm
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25612) Ambari stops alert notices dispatching on unhandled exception inside

2021-01-26 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25612.
--
Resolution: Fixed

> Ambari stops alert notices dispatching on unhandled exception inside
> 
>
> Key: AMBARI-25612
> URL: https://issues.apache.org/jira/browse/AMBARI-25612
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
>Reporter: Dmytro Vitiuk
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> On any not handled exception inside 
> AlertNoticeDispatchService.runOneIteration() ambari stops dispatching new 
> alert notices. As possible case - an exception during retrieving the pending 
> notices from ambari DB.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (AMBARI-25610) No warning message at changing repo name to an invalid one

2021-01-15 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko reassigned AMBARI-25610:


Assignee: Dmytro Grinenko

> No warning message at changing repo name to an invalid one
> --
>
> Key: AMBARI-25610
> URL: https://issues.apache.org/jira/browse/AMBARI-25610
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-admin
>Affects Versions: 2.7.5
>Reporter: Dmytro Pidhaiets
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> No warning message at changing repo name to an invalid one in "Cluster 
> management/Versions" edit/create after trying to save. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25610) No warning message at changing repo name to an invalid one

2021-01-15 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25610.
--
Resolution: Fixed

> No warning message at changing repo name to an invalid one
> --
>
> Key: AMBARI-25610
> URL: https://issues.apache.org/jira/browse/AMBARI-25610
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-admin
>Affects Versions: 2.7.5
>Reporter: Dmytro Pidhaiets
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> No warning message at changing repo name to an invalid one in "Cluster 
> management/Versions" edit/create after trying to save. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25609) sysUpTime field is populated with invalid value during SNMP trap creation

2021-01-13 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25609.
--
Resolution: Fixed

> sysUpTime field is populated with invalid value during SNMP trap creation
> -
>
> Key: AMBARI-25609
> URL: https://issues.apache.org/jira/browse/AMBARI-25609
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
>Reporter: Dmytro Vitiuk
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Ambari tries to set milliseconds to the "sysUpTime" field:
> [https://github.com/apache/ambari/blob/8e35277c24cc0ffd897c1dc727b2cc528cb8148b/ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/AmbariSNMPDispatcher.java#L120]
> but this field accepts hundreds of milliseconds:
> {noformat}
> The time (in hundredths of a second) since the network
> management portion of the system was last re-initialized.
> {noformat}
> ([https://tools.ietf.org/html/rfc1907#section-2.1])
> So after about 50-days in up-time an ambari server is not able to populate 
> "sysUpTime" with a correct value (the max value the field is able to accept 
> is "4294967295" - it is about 50 days in milliseconds).
>  Exception in ambari-server.log:
> {noformat}
> java.lang.IllegalArgumentException: Argument must be an unsigned 32bit value
>   at org.snmp4j.smi.UnsignedInteger32.setValue(UnsignedInteger32.java:144)
>   at org.snmp4j.smi.UnsignedInteger32.(UnsignedInteger32.java:53)
>   at org.snmp4j.smi.TimeTicks.(TimeTicks.java:58)
>   at 
> org.apache.ambari.server.notifications.dispatchers.AmbariSNMPDispatcher.prepareTrap(AmbariSNMPDispatcher.java:120)
>   at 
> org.apache.ambari.server.notifications.dispatchers.SNMPDispatcher.sendTraps(SNMPDispatcher.java:244)
>   at 
> org.apache.ambari.server.notifications.dispatchers.SNMPDispatcher.dispatch(SNMPDispatcher.java:157)
>   at 
> org.apache.ambari.server.notifications.DispatchRunnable.run(DispatchRunnable.java:58)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25608) Timezone data is outdated

2021-01-13 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25608.
--
Resolution: Fixed

> Timezone data is outdated
> -
>
> Key: AMBARI-25608
> URL: https://issues.apache.org/jira/browse/AMBARI-25608
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.7.5
>Reporter: Dmytro Pidhaiets
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Moment timezone data is outdated



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25606) Sometimes request aborting doesn't abort IN_PROGRESS task

2020-12-22 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25606:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Sometimes request aborting doesn't abort IN_PROGRESS task
> -
>
> Key: AMBARI-25606
> URL: https://issues.apache.org/jira/browse/AMBARI-25606
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
>Reporter: Dmytro Vitiuk
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> There is a raise condition in request aborting process.
> Imagine, we have a request with couple of stages/tasks and one task is in 
> IN_PROGRESS state. Then let's try to abort the request.
> Crucial steps of request aborting are:
>  # Get all not completed tasks for the request.
>  # Get QUEUED and IN_PROGRESS tasks from #1 and send cancel commands to the 
> agents (we've sent cancel command for our task).
>  # Get tasks in HOLDING_STATES (HOLDING_FAILED etc.) from #1 and try to abort 
> them.
>  # Get all tasks form stages which are not in COMPLETED state for the request.
>  # Get tasks from #4 which are in PENDING, QUEUED, IN_PROGRESS states and 
> abort them.
> But if the server receive response from the agent for cancel command (sent in 
> #2), then task will be transitioned from IN_PROGRESS to HOLDING_FAILED state. 
> That's ok if it happen before step #2 (it will be aborted because has 
> HOLDING_FAILED state) or after step #5 (it had IN_PROGRESS state and was 
> aborted; update from the agent won't change state to HOLDING_FAILED, because 
> we handle this case).
> But if we receive response from the agent between steps #3 and #5, then task 
> will not be aborted and we will get a task with HOLDING_FAILED state after 
> abort operation completion.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25606) Sometimes request aborting doesn't abort IN_PROGRESS task

2020-12-22 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25606:
-
Status: Patch Available  (was: Open)

> Sometimes request aborting doesn't abort IN_PROGRESS task
> -
>
> Key: AMBARI-25606
> URL: https://issues.apache.org/jira/browse/AMBARI-25606
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
>Reporter: Dmytro Vitiuk
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a raise condition in request aborting process.
> Imagine, we have a request with couple of stages/tasks and one task is in 
> IN_PROGRESS state. Then let's try to abort the request.
> Crucial steps of request aborting are:
>  # Get all not completed tasks for the request.
>  # Get QUEUED and IN_PROGRESS tasks from #1 and send cancel commands to the 
> agents (we've sent cancel command for our task).
>  # Get tasks in HOLDING_STATES (HOLDING_FAILED etc.) from #1 and try to abort 
> them.
>  # Get all tasks form stages which are not in COMPLETED state for the request.
>  # Get tasks from #4 which are in PENDING, QUEUED, IN_PROGRESS states and 
> abort them.
> But if the server receive response from the agent for cancel command (sent in 
> #2), then task will be transitioned from IN_PROGRESS to HOLDING_FAILED state. 
> That's ok if it happen before step #2 (it will be aborted because has 
> HOLDING_FAILED state) or after step #5 (it had IN_PROGRESS state and was 
> aborted; update from the agent won't change state to HOLDING_FAILED, because 
> we handle this case).
> But if we receive response from the agent between steps #3 and #5, then task 
> will not be aborted and we will get a task with HOLDING_FAILED state after 
> abort operation completion.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (AMBARI-25606) Sometimes request aborting doesn't abort IN_PROGRESS task

2020-12-22 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko reassigned AMBARI-25606:


Assignee: Dmytro Grinenko

> Sometimes request aborting doesn't abort IN_PROGRESS task
> -
>
> Key: AMBARI-25606
> URL: https://issues.apache.org/jira/browse/AMBARI-25606
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
>Reporter: Dmytro Vitiuk
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There is a raise condition in request aborting process.
> Imagine, we have a request with couple of stages/tasks and one task is in 
> IN_PROGRESS state. Then let's try to abort the request.
> Crucial steps of request aborting are:
>  # Get all not completed tasks for the request.
>  # Get QUEUED and IN_PROGRESS tasks from #1 and send cancel commands to the 
> agents (we've sent cancel command for our task).
>  # Get tasks in HOLDING_STATES (HOLDING_FAILED etc.) from #1 and try to abort 
> them.
>  # Get all tasks form stages which are not in COMPLETED state for the request.
>  # Get tasks from #4 which are in PENDING, QUEUED, IN_PROGRESS states and 
> abort them.
> But if the server receive response from the agent for cancel command (sent in 
> #2), then task will be transitioned from IN_PROGRESS to HOLDING_FAILED state. 
> That's ok if it happen before step #2 (it will be aborted because has 
> HOLDING_FAILED state) or after step #5 (it had IN_PROGRESS state and was 
> aborted; update from the agent won't change state to HOLDING_FAILED, because 
> we handle this case).
> But if we receive response from the agent between steps #3 and #5, then task 
> will not be aborted and we will get a task with HOLDING_FAILED state after 
> abort operation completion.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25601) Ambari with AMS HA unable to change metrics collector for metrics providing on collector fail

2020-12-16 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25601.
--
  Assignee: Dmytro Grinenko
Resolution: Fixed

> Ambari with AMS HA unable to change metrics collector for metrics providing 
> on collector fail
> -
>
> Key: AMBARI-25601
> URL: https://issues.apache.org/jira/browse/AMBARI-25601
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
>Reporter: Dmytro Vitiuk
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> It is expected that ambari server should select another available metrics 
> collector for metrics retrieval on current collector fail. But actually we 
> have the next numerous exceptions. Of course in this case metrics are 
> unavailable via ambari API.
> {code}
> 2020-12-10 08:41:44,402 ERROR [pool-3-thread-1] ambari-event-bus:232 - 
> Exception thrown by subscriber method 
> onMetricsCollectorHostDownEvent(org.apache.ambari.server.events.MetricsCollectorHostDownEvent)
>  on subscriber 
> org.apache.ambari.server.controller.metrics.MetricsCollectorHAManager@470dea54
>  when dispatching event: 
> MetricsCollectorHostDownEvent{eventType=METRICS_COLLECTOR_HOST_DOWN}
> java.lang.NullPointerException
> at 
> org.apache.ambari.server.controller.metrics.CollectorHostDownRefreshCounter.testRefreshCounter(CollectorHostDownRefreshCounter.java:33)
> at 
> org.apache.ambari.server.controller.metrics.MetricsCollectorHAClusterState.onCollectorHostDown(MetricsCollectorHAClusterState.java:117)
> at 
> org.apache.ambari.server.controller.metrics.MetricsCollectorHAManager.onMetricsCollectorHostDownEvent(MetricsCollectorHAManager.java:126)
> at sun.reflect.GeneratedMethodAccessor569.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> com.google.common.eventbus.Subscriber.invokeSubscriberMethod(Subscriber.java:87)
> at 
> com.google.common.eventbus.Subscriber$SynchronizedSubscriber.invokeSubscriberMethod(Subscriber.java:144)
> at com.google.common.eventbus.Subscriber$1.run(Subscriber.java:72)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMBARI-25599) Consider to eliminate HDP public binary references

2020-12-07 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-25599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245236#comment-17245236
 ] 

Dmytro Grinenko commented on AMBARI-25599:
--

Not sure if it will work, however here are "substitutes": 

- hadoop: https://hadoop.apache.org/releases.html
- hbase: https://hbase.apache.org/downloads.html
- phoenix: https://phoenix.apache.org/download.html

> Consider to eliminate HDP public binary references
> --
>
> Key: AMBARI-25599
> URL: https://issues.apache.org/jira/browse/AMBARI-25599
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server
>Reporter: Éberhardt Péter
>Priority: Major
> Fix For: 2.7.6
>
>
> Public HDP binaries will no longer available: 
> [https://my.cloudera.com/knowledge/Cloudera-Customer-Advisory-Paywall-Update-External?id=306085]
> Please analyse and eliminate(replace) the necessary references from the 
> codebase where rpms and tarballs of HDP are accessible.
> Additionally non managed HDP tarballs should be replaced with open source 
> ones. For example: 
> [https://github.com/apache/ambari/blob/branch-2.7/ambari-metrics/pom.xml#L43]
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25598) Fix a parameter error in the toString() of the ServiceComponentRequest file.

2020-12-01 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25598:
-
Status: Patch Available  (was: Open)

> Fix a parameter error in the toString() of the ServiceComponentRequest file.
> 
>
> Key: AMBARI-25598
> URL: https://issues.apache.org/jira/browse/AMBARI-25598
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: THOMAS TAO
>Priority: Minor
>  Labels: pull-request-available
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> In the tostring function of the ServiceComponentRequest file, the fourth 
> parameter of String.format() should be componentName instead of clusterName.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25598) Fix a parameter error in the toString() of the ServiceComponentRequest file.

2020-12-01 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25598:
-
Fix Version/s: trunk

> Fix a parameter error in the toString() of the ServiceComponentRequest file.
> 
>
> Key: AMBARI-25598
> URL: https://issues.apache.org/jira/browse/AMBARI-25598
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: THOMAS TAO
>Priority: Minor
>  Labels: pull-request-available
> Fix For: trunk
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> In the tostring function of the ServiceComponentRequest file, the fourth 
> parameter of String.format() should be componentName instead of clusterName.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25598) Fix a parameter error in the toString() of the ServiceComponentRequest file.

2020-12-01 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25598:
-
Affects Version/s: trunk

> Fix a parameter error in the toString() of the ServiceComponentRequest file.
> 
>
> Key: AMBARI-25598
> URL: https://issues.apache.org/jira/browse/AMBARI-25598
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: THOMAS TAO
>Priority: Minor
>  Labels: pull-request-available
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> In the tostring function of the ServiceComponentRequest file, the fourth 
> parameter of String.format() should be componentName instead of clusterName.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (AMBARI-25591) org.postgresql.util.PSQLException: FATAL: password authentication failed for user "mapred"

2020-11-25 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-25591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17238719#comment-17238719
 ] 

Dmytro Grinenko edited comment on AMBARI-25591 at 11/25/20, 12:28 PM:
--

[~dhire...@gmail.com] correct, it confirms what I sad above - check the github 
link and default value for RCA, in case if property is not set


was (Author: dgrinenko):
[~dhire...@gmail.com] correct, it confirms what I sad above

> org.postgresql.util.PSQLException: FATAL: password authentication failed for 
> user "mapred"
> --
>
> Key: AMBARI-25591
> URL: https://issues.apache.org/jira/browse/AMBARI-25591
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.1
>Reporter: Dhirendra Khanka
>Assignee: Dmytro Grinenko
>Priority: Minor
>  Labels: ambari-server
> Attachments: ambari-server.log
>
>
> Ambari server is continuously logging password authentication failed for user 
> mapred error and ward messages. However there is no user mapred in ambari. 
> The ambari database used is embedded postgresql.  Will running the 
> ambari-server setup again fix the issue?
>  
> {code:java}
> 2020-11-24 06:37:46,933 ERROR [ambari-client-thread-1425637] Driver:263 - 
> Connection error:
> org.postgresql.util.PSQLException: FATAL: password authentication failed for 
> user "mapred"{code}
>  
> Ambari database check gives below Warning in log
> {code:java}
> 2020-11-18 13:51:01,416 WARN - You have config(s): 
> falcon-startup.properties-TOPOLOGY_RESOLVED,spark-defaults-version1524543611951,spark-metrics-properties-version1485951378211,falcon-atlas-application.properties-version1524574152922,spark-env-version1485951378211,falcon-startup.properties-INITIAL,spark-defaults-version1501747039754,falcon-log4j-INITIAL,hcat-env-version1570571662097,mahout-env-TOPOLOGY_RESOLVED,flume-env-INITIAL,hive-exec-log4j-version1570571662921,slider-log4j-TOPOLOGY_RESOLVED,slider-client-INITIAL,falcon-client.properties-INITIAL,falcon-startup.properties-version1524543610919,falcon-atlas-application.properties-version1524543611402,falcon-runtime.properties-TOPOLOGY_RESOLVED,mahout-log4j-TOPOLOGY_RESOLVED,spark-defaults-version1524574152551,falcon-env-INITIAL,ranger-site-version1570571657763,falcon-runtime.properties-INITIAL,spark-defaults-version1485951378211,livy-conf-version1485951378211,webhcat-site-version1570571662592,falcon-atlas-application.properties-version1492596818127,mahout-log4j-INITIAL,falcon-startup.properties-version1496929735878,falcon-log4j-TOPOLOGY_RESOLVED,spark-env-version1493710636755,spark-thrift-sparkconf-version1492596818303,livy-log4j-properties-version1485951378211,livy-conf-version1524543611603,falcon-env-version1524574151887,falcon-atlas-application.properties-INITIAL,flume-conf-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1524574152356,mahout-env-INITIAL,spark-defaults-version1492596818576,flume-conf-INITIAL,livy-env-version1493710636755,falcon-startup.properties-version1524574151504,webhcat-env-version1570571663253,flume-env-TOPOLOGY_RESOLVED,falcon-env-TOPOLOGY_RESOLVED,slider-client-TOPOLOGY_RESOLVED,livy-env-version1485951378211,usersync-properties-version1570571659178,hive-log4j-version1570571663758,webhcat-log4j-version1570571661148,spark-thrift-fairscheduler-version1485951378211,falcon-atlas-application.properties-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1524543611628,slider-log4j-INITIAL,spark-hive-site-override-version1485951378211,spark-log4j-properties-version1485951378211,slider-env-TOPOLOGY_RESOLVED,livy-spark-blacklist-version1485951378211,spark-javaopts-properties-version1485951378211,livy-conf-version1524574153115,livy-conf-version1492596818283,falcon-startup.properties-version1492596817779,slider-env-INITIAL,falcon-client.properties-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1485951378211
>  that is(are) not mapped (in serviceconfigmapping table) to any service!{code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMBARI-25591) org.postgresql.util.PSQLException: FATAL: password authentication failed for user "mapred"

2020-11-25 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-25591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17238719#comment-17238719
 ] 

Dmytro Grinenko commented on AMBARI-25591:
--

[~dhire...@gmail.com] correct, it confirms what I sad above

> org.postgresql.util.PSQLException: FATAL: password authentication failed for 
> user "mapred"
> --
>
> Key: AMBARI-25591
> URL: https://issues.apache.org/jira/browse/AMBARI-25591
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.1
>Reporter: Dhirendra Khanka
>Assignee: Dmytro Grinenko
>Priority: Minor
>  Labels: ambari-server
> Attachments: ambari-server.log
>
>
> Ambari server is continuously logging password authentication failed for user 
> mapred error and ward messages. However there is no user mapred in ambari. 
> The ambari database used is embedded postgresql.  Will running the 
> ambari-server setup again fix the issue?
>  
> {code:java}
> 2020-11-24 06:37:46,933 ERROR [ambari-client-thread-1425637] Driver:263 - 
> Connection error:
> org.postgresql.util.PSQLException: FATAL: password authentication failed for 
> user "mapred"{code}
>  
> Ambari database check gives below Warning in log
> {code:java}
> 2020-11-18 13:51:01,416 WARN - You have config(s): 
> falcon-startup.properties-TOPOLOGY_RESOLVED,spark-defaults-version1524543611951,spark-metrics-properties-version1485951378211,falcon-atlas-application.properties-version1524574152922,spark-env-version1485951378211,falcon-startup.properties-INITIAL,spark-defaults-version1501747039754,falcon-log4j-INITIAL,hcat-env-version1570571662097,mahout-env-TOPOLOGY_RESOLVED,flume-env-INITIAL,hive-exec-log4j-version1570571662921,slider-log4j-TOPOLOGY_RESOLVED,slider-client-INITIAL,falcon-client.properties-INITIAL,falcon-startup.properties-version1524543610919,falcon-atlas-application.properties-version1524543611402,falcon-runtime.properties-TOPOLOGY_RESOLVED,mahout-log4j-TOPOLOGY_RESOLVED,spark-defaults-version1524574152551,falcon-env-INITIAL,ranger-site-version1570571657763,falcon-runtime.properties-INITIAL,spark-defaults-version1485951378211,livy-conf-version1485951378211,webhcat-site-version1570571662592,falcon-atlas-application.properties-version1492596818127,mahout-log4j-INITIAL,falcon-startup.properties-version1496929735878,falcon-log4j-TOPOLOGY_RESOLVED,spark-env-version1493710636755,spark-thrift-sparkconf-version1492596818303,livy-log4j-properties-version1485951378211,livy-conf-version1524543611603,falcon-env-version1524574151887,falcon-atlas-application.properties-INITIAL,flume-conf-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1524574152356,mahout-env-INITIAL,spark-defaults-version1492596818576,flume-conf-INITIAL,livy-env-version1493710636755,falcon-startup.properties-version1524574151504,webhcat-env-version1570571663253,flume-env-TOPOLOGY_RESOLVED,falcon-env-TOPOLOGY_RESOLVED,slider-client-TOPOLOGY_RESOLVED,livy-env-version1485951378211,usersync-properties-version1570571659178,hive-log4j-version1570571663758,webhcat-log4j-version1570571661148,spark-thrift-fairscheduler-version1485951378211,falcon-atlas-application.properties-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1524543611628,slider-log4j-INITIAL,spark-hive-site-override-version1485951378211,spark-log4j-properties-version1485951378211,slider-env-TOPOLOGY_RESOLVED,livy-spark-blacklist-version1485951378211,spark-javaopts-properties-version1485951378211,livy-conf-version1524574153115,livy-conf-version1492596818283,falcon-startup.properties-version1492596817779,slider-env-INITIAL,falcon-client.properties-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1485951378211
>  that is(are) not mapped (in serviceconfigmapping table) to any service!{code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (AMBARI-25591) org.postgresql.util.PSQLException: FATAL: password authentication failed for user "mapred"

2020-11-24 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko reassigned AMBARI-25591:


Assignee: Dmytro Grinenko

> org.postgresql.util.PSQLException: FATAL: password authentication failed for 
> user "mapred"
> --
>
> Key: AMBARI-25591
> URL: https://issues.apache.org/jira/browse/AMBARI-25591
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.1
>Reporter: Dhirendra Khanka
>Assignee: Dmytro Grinenko
>Priority: Minor
>  Labels: ambari-server
> Attachments: ambari-server.log
>
>
> Ambari server is continuously logging password authentication failed for user 
> mapred error and ward messages. However there is no user mapred in ambari. 
> The ambari database used is embedded postgresql.  Will running the 
> ambari-server setup again fix the issue?
>  
> {code:java}
> 2020-11-24 06:37:46,933 ERROR [ambari-client-thread-1425637] Driver:263 - 
> Connection error:
> org.postgresql.util.PSQLException: FATAL: password authentication failed for 
> user "mapred"{code}
>  
> Ambari database check gives below Warning in log
> {code:java}
> 2020-11-18 13:51:01,416 WARN - You have config(s): 
> falcon-startup.properties-TOPOLOGY_RESOLVED,spark-defaults-version1524543611951,spark-metrics-properties-version1485951378211,falcon-atlas-application.properties-version1524574152922,spark-env-version1485951378211,falcon-startup.properties-INITIAL,spark-defaults-version1501747039754,falcon-log4j-INITIAL,hcat-env-version1570571662097,mahout-env-TOPOLOGY_RESOLVED,flume-env-INITIAL,hive-exec-log4j-version1570571662921,slider-log4j-TOPOLOGY_RESOLVED,slider-client-INITIAL,falcon-client.properties-INITIAL,falcon-startup.properties-version1524543610919,falcon-atlas-application.properties-version1524543611402,falcon-runtime.properties-TOPOLOGY_RESOLVED,mahout-log4j-TOPOLOGY_RESOLVED,spark-defaults-version1524574152551,falcon-env-INITIAL,ranger-site-version1570571657763,falcon-runtime.properties-INITIAL,spark-defaults-version1485951378211,livy-conf-version1485951378211,webhcat-site-version1570571662592,falcon-atlas-application.properties-version1492596818127,mahout-log4j-INITIAL,falcon-startup.properties-version1496929735878,falcon-log4j-TOPOLOGY_RESOLVED,spark-env-version1493710636755,spark-thrift-sparkconf-version1492596818303,livy-log4j-properties-version1485951378211,livy-conf-version1524543611603,falcon-env-version1524574151887,falcon-atlas-application.properties-INITIAL,flume-conf-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1524574152356,mahout-env-INITIAL,spark-defaults-version1492596818576,flume-conf-INITIAL,livy-env-version1493710636755,falcon-startup.properties-version1524574151504,webhcat-env-version1570571663253,flume-env-TOPOLOGY_RESOLVED,falcon-env-TOPOLOGY_RESOLVED,slider-client-TOPOLOGY_RESOLVED,livy-env-version1485951378211,usersync-properties-version1570571659178,hive-log4j-version1570571663758,webhcat-log4j-version1570571661148,spark-thrift-fairscheduler-version1485951378211,falcon-atlas-application.properties-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1524543611628,slider-log4j-INITIAL,spark-hive-site-override-version1485951378211,spark-log4j-properties-version1485951378211,slider-env-TOPOLOGY_RESOLVED,livy-spark-blacklist-version1485951378211,spark-javaopts-properties-version1485951378211,livy-conf-version1524574153115,livy-conf-version1492596818283,falcon-startup.properties-version1492596817779,slider-env-INITIAL,falcon-client.properties-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1485951378211
>  that is(are) not mapped (in serviceconfigmapping table) to any service!{code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMBARI-25591) org.postgresql.util.PSQLException: FATAL: password authentication failed for user "mapred"

2020-11-24 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-25591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17238504#comment-17238504
 ] 

Dmytro Grinenko commented on AMBARI-25591:
--

[~dhire...@gmail.com] while RCA is not used anymore, it still marked as 
"[deprecated|https://github.com/apache/ambari/blob/branch-2.7/ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java#L1354]";
 and should be set properly. The default value is "mapred" through. 

In current state settings for default connection and RCA should match and with 
embedded mode, setup script will configure both properties properly.  



> org.postgresql.util.PSQLException: FATAL: password authentication failed for 
> user "mapred"
> --
>
> Key: AMBARI-25591
> URL: https://issues.apache.org/jira/browse/AMBARI-25591
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.1
>Reporter: Dhirendra Khanka
>Priority: Minor
>  Labels: ambari-server
> Attachments: ambari-server.log
>
>
> Ambari server is continuously logging password authentication failed for user 
> mapred error and ward messages. However there is no user mapred in ambari. 
> The ambari database used is embedded postgresql.  Will running the 
> ambari-server setup again fix the issue?
>  
> {code:java}
> 2020-11-24 06:37:46,933 ERROR [ambari-client-thread-1425637] Driver:263 - 
> Connection error:
> org.postgresql.util.PSQLException: FATAL: password authentication failed for 
> user "mapred"{code}
>  
> Ambari database check gives below Warning in log
> {code:java}
> 2020-11-18 13:51:01,416 WARN - You have config(s): 
> falcon-startup.properties-TOPOLOGY_RESOLVED,spark-defaults-version1524543611951,spark-metrics-properties-version1485951378211,falcon-atlas-application.properties-version1524574152922,spark-env-version1485951378211,falcon-startup.properties-INITIAL,spark-defaults-version1501747039754,falcon-log4j-INITIAL,hcat-env-version1570571662097,mahout-env-TOPOLOGY_RESOLVED,flume-env-INITIAL,hive-exec-log4j-version1570571662921,slider-log4j-TOPOLOGY_RESOLVED,slider-client-INITIAL,falcon-client.properties-INITIAL,falcon-startup.properties-version1524543610919,falcon-atlas-application.properties-version1524543611402,falcon-runtime.properties-TOPOLOGY_RESOLVED,mahout-log4j-TOPOLOGY_RESOLVED,spark-defaults-version1524574152551,falcon-env-INITIAL,ranger-site-version1570571657763,falcon-runtime.properties-INITIAL,spark-defaults-version1485951378211,livy-conf-version1485951378211,webhcat-site-version1570571662592,falcon-atlas-application.properties-version1492596818127,mahout-log4j-INITIAL,falcon-startup.properties-version1496929735878,falcon-log4j-TOPOLOGY_RESOLVED,spark-env-version1493710636755,spark-thrift-sparkconf-version1492596818303,livy-log4j-properties-version1485951378211,livy-conf-version1524543611603,falcon-env-version1524574151887,falcon-atlas-application.properties-INITIAL,flume-conf-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1524574152356,mahout-env-INITIAL,spark-defaults-version1492596818576,flume-conf-INITIAL,livy-env-version1493710636755,falcon-startup.properties-version1524574151504,webhcat-env-version1570571663253,flume-env-TOPOLOGY_RESOLVED,falcon-env-TOPOLOGY_RESOLVED,slider-client-TOPOLOGY_RESOLVED,livy-env-version1485951378211,usersync-properties-version1570571659178,hive-log4j-version1570571663758,webhcat-log4j-version1570571661148,spark-thrift-fairscheduler-version1485951378211,falcon-atlas-application.properties-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1524543611628,slider-log4j-INITIAL,spark-hive-site-override-version1485951378211,spark-log4j-properties-version1485951378211,slider-env-TOPOLOGY_RESOLVED,livy-spark-blacklist-version1485951378211,spark-javaopts-properties-version1485951378211,livy-conf-version1524574153115,livy-conf-version1492596818283,falcon-startup.properties-version1492596817779,slider-env-INITIAL,falcon-client.properties-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1485951378211
>  that is(are) not mapped (in serviceconfigmapping table) to any service!{code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25591) org.postgresql.util.PSQLException: FATAL: password authentication failed for user "mapred"

2020-11-24 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25591.
--
Resolution: Invalid

> org.postgresql.util.PSQLException: FATAL: password authentication failed for 
> user "mapred"
> --
>
> Key: AMBARI-25591
> URL: https://issues.apache.org/jira/browse/AMBARI-25591
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.1
>Reporter: Dhirendra Khanka
>Priority: Minor
>  Labels: ambari-server
> Attachments: ambari-server.log
>
>
> Ambari server is continuously logging password authentication failed for user 
> mapred error and ward messages. However there is no user mapred in ambari. 
> The ambari database used is embedded postgresql.  Will running the 
> ambari-server setup again fix the issue?
>  
> {code:java}
> 2020-11-24 06:37:46,933 ERROR [ambari-client-thread-1425637] Driver:263 - 
> Connection error:
> org.postgresql.util.PSQLException: FATAL: password authentication failed for 
> user "mapred"{code}
>  
> Ambari database check gives below Warning in log
> {code:java}
> 2020-11-18 13:51:01,416 WARN - You have config(s): 
> falcon-startup.properties-TOPOLOGY_RESOLVED,spark-defaults-version1524543611951,spark-metrics-properties-version1485951378211,falcon-atlas-application.properties-version1524574152922,spark-env-version1485951378211,falcon-startup.properties-INITIAL,spark-defaults-version1501747039754,falcon-log4j-INITIAL,hcat-env-version1570571662097,mahout-env-TOPOLOGY_RESOLVED,flume-env-INITIAL,hive-exec-log4j-version1570571662921,slider-log4j-TOPOLOGY_RESOLVED,slider-client-INITIAL,falcon-client.properties-INITIAL,falcon-startup.properties-version1524543610919,falcon-atlas-application.properties-version1524543611402,falcon-runtime.properties-TOPOLOGY_RESOLVED,mahout-log4j-TOPOLOGY_RESOLVED,spark-defaults-version1524574152551,falcon-env-INITIAL,ranger-site-version1570571657763,falcon-runtime.properties-INITIAL,spark-defaults-version1485951378211,livy-conf-version1485951378211,webhcat-site-version1570571662592,falcon-atlas-application.properties-version1492596818127,mahout-log4j-INITIAL,falcon-startup.properties-version1496929735878,falcon-log4j-TOPOLOGY_RESOLVED,spark-env-version1493710636755,spark-thrift-sparkconf-version1492596818303,livy-log4j-properties-version1485951378211,livy-conf-version1524543611603,falcon-env-version1524574151887,falcon-atlas-application.properties-INITIAL,flume-conf-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1524574152356,mahout-env-INITIAL,spark-defaults-version1492596818576,flume-conf-INITIAL,livy-env-version1493710636755,falcon-startup.properties-version1524574151504,webhcat-env-version1570571663253,flume-env-TOPOLOGY_RESOLVED,falcon-env-TOPOLOGY_RESOLVED,slider-client-TOPOLOGY_RESOLVED,livy-env-version1485951378211,usersync-properties-version1570571659178,hive-log4j-version1570571663758,webhcat-log4j-version1570571661148,spark-thrift-fairscheduler-version1485951378211,falcon-atlas-application.properties-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1524543611628,slider-log4j-INITIAL,spark-hive-site-override-version1485951378211,spark-log4j-properties-version1485951378211,slider-env-TOPOLOGY_RESOLVED,livy-spark-blacklist-version1485951378211,spark-javaopts-properties-version1485951378211,livy-conf-version1524574153115,livy-conf-version1492596818283,falcon-startup.properties-version1492596817779,slider-env-INITIAL,falcon-client.properties-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1485951378211
>  that is(are) not mapped (in serviceconfigmapping table) to any service!{code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMBARI-25591) org.postgresql.util.PSQLException: FATAL: password authentication failed for user "mapred"

2020-11-24 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-25591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17238242#comment-17238242
 ] 

Dmytro Grinenko commented on AMBARI-25591:
--

not a lot information available, basically nothing to tell without full stack 
trace.


As for the recommendation, verify configured user and password in the 
ambari.properties; The warning log might be a result of previous error.


> org.postgresql.util.PSQLException: FATAL: password authentication failed for 
> user "mapred"
> --
>
> Key: AMBARI-25591
> URL: https://issues.apache.org/jira/browse/AMBARI-25591
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.1
>Reporter: Dhirendra Khanka
>Priority: Minor
>  Labels: ambari-server
>
> Ambari server is continuously logging password authentication failed for user 
> mapred error and ward messages. However there is no user mapred in ambari. 
> The ambari database used is embedded postgresql.  Will running the 
> ambari-server setup again fix the issue?
>  
> {code:java}
> 2020-11-24 06:37:46,933 ERROR [ambari-client-thread-1425637] Driver:263 - 
> Connection error:
> org.postgresql.util.PSQLException: FATAL: password authentication failed for 
> user "mapred"{code}
>  
> Ambari database check gives below Warning in log
> {code:java}
> 2020-11-18 13:51:01,416 WARN - You have config(s): 
> falcon-startup.properties-TOPOLOGY_RESOLVED,spark-defaults-version1524543611951,spark-metrics-properties-version1485951378211,falcon-atlas-application.properties-version1524574152922,spark-env-version1485951378211,falcon-startup.properties-INITIAL,spark-defaults-version1501747039754,falcon-log4j-INITIAL,hcat-env-version1570571662097,mahout-env-TOPOLOGY_RESOLVED,flume-env-INITIAL,hive-exec-log4j-version1570571662921,slider-log4j-TOPOLOGY_RESOLVED,slider-client-INITIAL,falcon-client.properties-INITIAL,falcon-startup.properties-version1524543610919,falcon-atlas-application.properties-version1524543611402,falcon-runtime.properties-TOPOLOGY_RESOLVED,mahout-log4j-TOPOLOGY_RESOLVED,spark-defaults-version1524574152551,falcon-env-INITIAL,ranger-site-version1570571657763,falcon-runtime.properties-INITIAL,spark-defaults-version1485951378211,livy-conf-version1485951378211,webhcat-site-version1570571662592,falcon-atlas-application.properties-version1492596818127,mahout-log4j-INITIAL,falcon-startup.properties-version1496929735878,falcon-log4j-TOPOLOGY_RESOLVED,spark-env-version1493710636755,spark-thrift-sparkconf-version1492596818303,livy-log4j-properties-version1485951378211,livy-conf-version1524543611603,falcon-env-version1524574151887,falcon-atlas-application.properties-INITIAL,flume-conf-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1524574152356,mahout-env-INITIAL,spark-defaults-version1492596818576,flume-conf-INITIAL,livy-env-version1493710636755,falcon-startup.properties-version1524574151504,webhcat-env-version1570571663253,flume-env-TOPOLOGY_RESOLVED,falcon-env-TOPOLOGY_RESOLVED,slider-client-TOPOLOGY_RESOLVED,livy-env-version1485951378211,usersync-properties-version1570571659178,hive-log4j-version1570571663758,webhcat-log4j-version1570571661148,spark-thrift-fairscheduler-version1485951378211,falcon-atlas-application.properties-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1524543611628,slider-log4j-INITIAL,spark-hive-site-override-version1485951378211,spark-log4j-properties-version1485951378211,slider-env-TOPOLOGY_RESOLVED,livy-spark-blacklist-version1485951378211,spark-javaopts-properties-version1485951378211,livy-conf-version1524574153115,livy-conf-version1492596818283,falcon-startup.properties-version1492596817779,slider-env-INITIAL,falcon-client.properties-TOPOLOGY_RESOLVED,spark-thrift-sparkconf-version1485951378211
>  that is(are) not mapped (in serviceconfigmapping table) to any service!{code}
>  
> [^ambari-server.log]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25587) Metrics cannot be stored and the exception message is null when metric value is NaN

2020-11-24 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25587:
-
Status: Patch Available  (was: Open)

> Metrics cannot be stored and the exception message is null  when metric value 
> is NaN
> 
>
> Key: AMBARI-25587
> URL: https://issues.apache.org/jira/browse/AMBARI-25587
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
> Environment: Ambari:2.7.4
>Reporter: akiyamaneko
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The exception information frequently appeared in ambari-metrics-collector.log 
>  as follows:
> {code:java}
> 2020-11-12 12:28:11,200 WARN 
> org.apache.ambari.metrics.core.timeline.PhoenixHBaseAccessor: Failed on 
> insert records to store : null
> 2020-11-12 12:28:11,200 WARN 
> org.apache.ambari.metrics.core.timeline.PhoenixHBaseAccessor: Metric that 
> cannot be stored : 
> [default.General.hs2_avg_active_session_time,hiveserver2]{1605155168235=NaN, 
> 1605155198236=NaN, 1605155228235=NaN, 1605155258235=NaN}
> {code}
> The exception message of metrics written to HBase is directly displayed as 
> null.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25587) Metrics cannot be stored and the exception message is null when metric value is NaN

2020-11-24 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25587:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Metrics cannot be stored and the exception message is null  when metric value 
> is NaN
> 
>
> Key: AMBARI-25587
> URL: https://issues.apache.org/jira/browse/AMBARI-25587
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
> Environment: Ambari:2.7.4
>Reporter: akiyamaneko
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The exception information frequently appeared in ambari-metrics-collector.log 
>  as follows:
> {code:java}
> 2020-11-12 12:28:11,200 WARN 
> org.apache.ambari.metrics.core.timeline.PhoenixHBaseAccessor: Failed on 
> insert records to store : null
> 2020-11-12 12:28:11,200 WARN 
> org.apache.ambari.metrics.core.timeline.PhoenixHBaseAccessor: Metric that 
> cannot be stored : 
> [default.General.hs2_avg_active_session_time,hiveserver2]{1605155168235=NaN, 
> 1605155198236=NaN, 1605155228235=NaN, 1605155258235=NaN}
> {code}
> The exception message of metrics written to HBase is directly displayed as 
> null.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25586) The page will not refresh automatically after the permission was modified in the Files View page

2020-11-24 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25586:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> The page will not refresh automatically after the permission was  modified in 
> the Files View page
> -
>
> Key: AMBARI-25586
> URL: https://issues.apache.org/jira/browse/AMBARI-25586
> Project: Ambari
>  Issue Type: Improvement
>  Components: contrib
>Affects Versions: 2.7.5
>Reporter: akiyamaneko
>Priority: Minor
> Fix For: 2.7.6
>
> Attachments: permission_cannot_auto_refresh.mp4.gif
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> In the Files View page in Ambari, select a directory or file to modify its 
> permission. After the operation was finished, the permission didn't  
> automatically refresh, which often makes users confused and mistakenly 
> believed that the operation was not successful.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25586) The page will not refresh automatically after the permission was modified in the Files View page

2020-11-24 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25586:
-
Status: Patch Available  (was: Open)

> The page will not refresh automatically after the permission was  modified in 
> the Files View page
> -
>
> Key: AMBARI-25586
> URL: https://issues.apache.org/jira/browse/AMBARI-25586
> Project: Ambari
>  Issue Type: Improvement
>  Components: contrib
>Affects Versions: 2.7.5
>Reporter: akiyamaneko
>Priority: Minor
> Fix For: 2.7.6
>
> Attachments: permission_cannot_auto_refresh.mp4.gif
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> In the Files View page in Ambari, select a directory or file to modify its 
> permission. After the operation was finished, the permission didn't  
> automatically refresh, which often makes users confused and mistakenly 
> believed that the operation was not successful.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25586) The page will not refresh automatically after the permission was modified in the Files View page

2020-11-24 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25586:
-
Fix Version/s: 2.7.6

> The page will not refresh automatically after the permission was  modified in 
> the Files View page
> -
>
> Key: AMBARI-25586
> URL: https://issues.apache.org/jira/browse/AMBARI-25586
> Project: Ambari
>  Issue Type: Improvement
>  Components: contrib
>Affects Versions: 2.7.5
>Reporter: akiyamaneko
>Priority: Minor
> Fix For: 2.7.6
>
> Attachments: permission_cannot_auto_refresh.mp4.gif
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> In the Files View page in Ambari, select a directory or file to modify its 
> permission. After the operation was finished, the permission didn't  
> automatically refresh, which often makes users confused and mistakenly 
> believed that the operation was not successful.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25582) Change the way AMS Grafana datasource discovers the Kafka topics

2020-11-18 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25582:
-
Assignee: Dmytro Grinenko
  Status: Patch Available  (was: Open)

> Change the way AMS Grafana datasource discovers the Kafka topics 
> -
>
> Key: AMBARI-25582
> URL: https://issues.apache.org/jira/browse/AMBARI-25582
> Project: Ambari
>  Issue Type: Task
>Reporter: Tamas Payer
>Assignee: Dmytro Grinenko
>Priority: Major
>  Labels: ambari-metrics, grafana
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently the available Kafka topics are discovered by extracting them from 
> the kafka.log.Log.*
>  metrics in the AMS Datasource to show them on the Kafka-Topics dashboard. 
> This means that if whitelisting is used the kafka.log.Log.* metrics must be 
> enabled and must not be excluded by 'external.kafka.metrics.exclude.prefix' 
> Kafka property either.
> However, in some cases the large amount of kafka.log.Log.* metrics can be a 
> burden to AMS, so excluding them would be welcomed.
> The possibility to discover the Kafka topics should be assessed! 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25582) Change the way AMS Grafana datasource discovers the Kafka topics

2020-11-18 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25582:
-
Fix Version/s: 2.7.6
   Resolution: Fixed
   Status: Resolved  (was: Patch Available)

> Change the way AMS Grafana datasource discovers the Kafka topics 
> -
>
> Key: AMBARI-25582
> URL: https://issues.apache.org/jira/browse/AMBARI-25582
> Project: Ambari
>  Issue Type: Task
>Reporter: Tamas Payer
>Assignee: Dmytro Grinenko
>Priority: Major
>  Labels: ambari-metrics, grafana
> Fix For: 2.7.6
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently the available Kafka topics are discovered by extracting them from 
> the kafka.log.Log.*
>  metrics in the AMS Datasource to show them on the Kafka-Topics dashboard. 
> This means that if whitelisting is used the kafka.log.Log.* metrics must be 
> enabled and must not be excluded by 'external.kafka.metrics.exclude.prefix' 
> Kafka property either.
> However, in some cases the large amount of kafka.log.Log.* metrics can be a 
> burden to AMS, so excluding them would be welcomed.
> The possibility to discover the Kafka topics should be assessed! 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-24683) Cannot run HDFS service check without HDFS_CLIENT

2020-11-15 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-24683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-24683.
--
Resolution: Won't Fix

> Cannot run HDFS service check without HDFS_CLIENT
> -
>
> Key: AMBARI-24683
> URL: https://issues.apache.org/jira/browse/AMBARI-24683
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.2
>Reporter: Attila Doroszlai
>Assignee: Dmytro Grinenko
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> HDFS service check cannot be run if no host in the cluster has HDFS_CLIENT.  
> The operation is not even created due to the following exception:
> {noformat}
> org.apache.ambari.server.controller.spi.SystemException: An internal system 
> exception occurred: No hosts found for service: HDFS, component: HDFS_CLIENT 
> in cluster: TEST
> at 
> org.apache.ambari.server.controller.internal.AbstractResourceProvider.createResources(AbstractResourceProvider.java:287)
> at 
> org.apache.ambari.server.controller.internal.RequestResourceProvider.createResources(RequestResourceProvider.java:193)
> at 
> org.apache.ambari.server.controller.internal.ClusterControllerImpl.createResources(ClusterControllerImpl.java:298)
> ...
> Caused by: org.apache.ambari.server.AmbariException: No hosts found for 
> service: HDFS, component: HDFS_CLIENT in cluster: TEST
> at 
> org.apache.ambari.server.controller.AmbariCustomCommandExecutionHelper.findHostAndAddServiceCheckAction(AmbariCustomCommandExecutionHelper.java:540)
> at 
> org.apache.ambari.server.controller.AmbariCustomCommandExecutionHelper.addExecutionCommandsToStage(AmbariCustomCommandExecutionHelper.java:1109)
> at 
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createAction(AmbariManagementControllerImpl.java:4252)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25543) hdfs heatmap "DataNode Process Disk I/O Utilization" showed incorrect high

2020-11-15 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25543:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

merged

>  hdfs heatmap "DataNode Process Disk I/O Utilization" showed incorrect high
> ---
>
> Key: AMBARI-25543
> URL: https://issues.apache.org/jira/browse/AMBARI-25543
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.7.4
> Environment: HDP release version Version 2.7.4.0
>Reporter: yx91490
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
> Attachments: Disk_IO_Utilization.png
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> hdfs heatmap "DataNode Process Disk I/O Utilization" showed incorrect high, 
> which is 36,000,000%, see attached picture



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25573) Ambari Metrics save as JSON/CSV use metricName instead of default name.

2020-11-10 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25573:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Fixed in #3257

> Ambari Metrics save as JSON/CSV use metricName instead of  default name.
> 
>
> Key: AMBARI-25573
> URL: https://issues.apache.org/jira/browse/AMBARI-25573
> Project: Ambari
>  Issue Type: Improvement
>Affects Versions: 2.7.5
>Reporter: akiyamaneko
>Assignee: Dmytro Grinenko
>Priority: Major
>  Labels: pull-request-available, widget
> Fix For: 2.7.6
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> The name of the metrics data exported in Ambari-web is always data.json/csv, 
> and the exported file must be renamed to distinguish which metric the data 
> belongs to.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25543) hdfs heatmap "DataNode Process Disk I/O Utilization" showed incorrect high

2020-11-10 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25543:
-
Fix Version/s: 2.7.6

>  hdfs heatmap "DataNode Process Disk I/O Utilization" showed incorrect high
> ---
>
> Key: AMBARI-25543
> URL: https://issues.apache.org/jira/browse/AMBARI-25543
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.7.4
> Environment: HDP release version Version 2.7.4.0
>Reporter: yx91490
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
> Attachments: Disk_IO_Utilization.png
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> hdfs heatmap "DataNode Process Disk I/O Utilization" showed incorrect high, 
> which is 36,000,000%, see attached picture



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25573) Ambari Metrics save as JSON/CSV use metricName instead of default name.

2020-11-10 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25573:
-
Assignee: Dmytro Grinenko
  Status: Patch Available  (was: Reopened)

> Ambari Metrics save as JSON/CSV use metricName instead of  default name.
> 
>
> Key: AMBARI-25573
> URL: https://issues.apache.org/jira/browse/AMBARI-25573
> Project: Ambari
>  Issue Type: Improvement
>Affects Versions: 2.7.5
>Reporter: akiyamaneko
>Assignee: Dmytro Grinenko
>Priority: Major
>  Labels: pull-request-available, widget
> Fix For: 2.7.6
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> The name of the metrics data exported in Ambari-web is always data.json/csv, 
> and the exported file must be renamed to distinguish which metric the data 
> belongs to.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25543) hdfs heatmap "DataNode Process Disk I/O Utilization" showed incorrect high

2020-11-10 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25543:
-
Assignee: Dmytro Grinenko
  Status: Patch Available  (was: Open)

>  hdfs heatmap "DataNode Process Disk I/O Utilization" showed incorrect high
> ---
>
> Key: AMBARI-25543
> URL: https://issues.apache.org/jira/browse/AMBARI-25543
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.7.4
> Environment: HDP release version Version 2.7.4.0
>Reporter: yx91490
>Assignee: Dmytro Grinenko
>Priority: Major
> Attachments: Disk_IO_Utilization.png
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> hdfs heatmap "DataNode Process Disk I/O Utilization" showed incorrect high, 
> which is 36,000,000%, see attached picture



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25581) Prototype pollution issue in JQuery

2020-11-10 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25581:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Prototype pollution issue in JQuery
> ---
>
> Key: AMBARI-25581
> URL: https://issues.apache.org/jira/browse/AMBARI-25581
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.7.5
>Reporter: Éberhardt Péter
>Assignee: Éberhardt Péter
>Priority: Major
>  Labels: security, vulnerability
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Ambari 2.7.5 is using JQuery 1.9.1 which is vulnerable by 
> [https://snyk.io/vuln/SNYK-JS-JQUERY-174006]
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25581) Prototype pollution issue in JQuery

2020-11-10 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25581:
-
Status: Patch Available  (was: Open)

> Prototype pollution issue in JQuery
> ---
>
> Key: AMBARI-25581
> URL: https://issues.apache.org/jira/browse/AMBARI-25581
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.7.5
>Reporter: Éberhardt Péter
>Assignee: Éberhardt Péter
>Priority: Major
>  Labels: security, vulnerability
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Ambari 2.7.5 is using JQuery 1.9.1 which is vulnerable by 
> [https://snyk.io/vuln/SNYK-JS-JQUERY-174006]
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25576) Primary key duplication error during flushing alerts from alerts cache

2020-11-05 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25576:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Primary key duplication error during flushing alerts from alerts cache
> --
>
> Key: AMBARI-25576
> URL: https://issues.apache.org/jira/browse/AMBARI-25576
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
>Reporter: Dmytro Vitiuk
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Sometimes there are commit errors for clusters with a lot of hosts and 
> enabled alert caching:
> {code:java}
> 2020-10-09 19:53:14,444 ERROR [alert-event-bus-4] 
> AmbariJpaLocalTxnInterceptor:180 - [DETAILED ERROR] Rollback reason: 
> Local Exception Stack: 
> Exception [EclipseLink-4002] (Eclipse Persistence Services - 
> 2.6.2.v20151217-774c696): org.eclipse.persistence.exceptions.DatabaseException
> Internal Exception: java.sql.BatchUpdateException: Batch entry 1 INSERT INTO 
> alert_history (alert_id, alert_instance, alert_label, alert_state, 
> alert_text, alert_timestamp, cluster_id, component_name, host_name, 
> service_name, alert_definition_id) VALUES (15363461, NULL, 'DataNode Web UI', 
> 'OK', 'HTTP 200 response in 0.000s', 1602286496756, 2, 'DATANODE', 'host1', 
> 'HDFS', 53) was aborted: ERROR: duplicate key value violates unique 
> constraint "pk_alert_history"
>   Detail: Key (alert_id)=(15363461) already exists.  Call getNextException to 
> see other errors in the batch.
> Error Code: 0
> Call: INSERT INTO alert_history (alert_id, alert_instance, alert_label, 
> alert_state, alert_text, alert_timestamp, cluster_id, component_name, 
> host_name, service_name, alert_definition_id) VALUES (?, ?, ?, ?, ?, ?, ?, ?, 
> ?, ?, ?)
>   bind => [11 parameters bound]
> {code}
> This is not often issue, but anyway it has extensive logging. Also this issue 
> can cause other rare problems, so it should be fixed.
>  The reason of the issue is we have a shareable cache which can be updated 
> with just merged value before this value will be really committed into DB. In 
> this case other thread (from CachedAlertFlushService or AlertEventPublisher) 
> can try to also merge already merged entity. 
>  For example, we've created a new AlertHistoryEntity and set it to existing 
> AlertCurrentEntity. A first thread started transaction, merged current entity 
> to context, saved merged value to the cache and paused execution. After that 
> a second thread tries to merge all content of cache and also merges just 
> updated current entity. So we have two transaction and both think they should 
> update current entity and create the new history entity. As result one of 
> them is failing on duplicate error.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25576) Primary key duplication error during flushing alerts from alerts cache

2020-11-05 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25576:
-
Assignee: Dmytro Grinenko
  Status: Patch Available  (was: Open)

> Primary key duplication error during flushing alerts from alerts cache
> --
>
> Key: AMBARI-25576
> URL: https://issues.apache.org/jira/browse/AMBARI-25576
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
>Reporter: Dmytro Vitiuk
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Sometimes there are commit errors for clusters with a lot of hosts and 
> enabled alert caching:
> {code:java}
> 2020-10-09 19:53:14,444 ERROR [alert-event-bus-4] 
> AmbariJpaLocalTxnInterceptor:180 - [DETAILED ERROR] Rollback reason: 
> Local Exception Stack: 
> Exception [EclipseLink-4002] (Eclipse Persistence Services - 
> 2.6.2.v20151217-774c696): org.eclipse.persistence.exceptions.DatabaseException
> Internal Exception: java.sql.BatchUpdateException: Batch entry 1 INSERT INTO 
> alert_history (alert_id, alert_instance, alert_label, alert_state, 
> alert_text, alert_timestamp, cluster_id, component_name, host_name, 
> service_name, alert_definition_id) VALUES (15363461, NULL, 'DataNode Web UI', 
> 'OK', 'HTTP 200 response in 0.000s', 1602286496756, 2, 'DATANODE', 'host1', 
> 'HDFS', 53) was aborted: ERROR: duplicate key value violates unique 
> constraint "pk_alert_history"
>   Detail: Key (alert_id)=(15363461) already exists.  Call getNextException to 
> see other errors in the batch.
> Error Code: 0
> Call: INSERT INTO alert_history (alert_id, alert_instance, alert_label, 
> alert_state, alert_text, alert_timestamp, cluster_id, component_name, 
> host_name, service_name, alert_definition_id) VALUES (?, ?, ?, ?, ?, ?, ?, ?, 
> ?, ?, ?)
>   bind => [11 parameters bound]
> {code}
> This is not often issue, but anyway it has extensive logging. Also this issue 
> can cause other rare problems, so it should be fixed.
>  The reason of the issue is we have a shareable cache which can be updated 
> with just merged value before this value will be really committed into DB. In 
> this case other thread (from CachedAlertFlushService or AlertEventPublisher) 
> can try to also merge already merged entity. 
>  For example, we've created a new AlertHistoryEntity and set it to existing 
> AlertCurrentEntity. A first thread started transaction, merged current entity 
> to context, saved merged value to the cache and paused execution. After that 
> a second thread tries to merge all content of cache and also merges just 
> updated current entity. So we have two transaction and both think they should 
> update current entity and create the new history entity. As result one of 
> them is failing on duplicate error.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-21043) Backport Ambari-17694 - Kafka listeners property does not show SASL_PLAINTEXT protocol when Kerberos is enabled

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-21043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-21043.
--
Resolution: Won't Fix

Not actual

> Backport Ambari-17694 - Kafka listeners property does not show SASL_PLAINTEXT 
> protocol when Kerberos is enabled
> ---
>
> Key: AMBARI-21043
> URL: https://issues.apache.org/jira/browse/AMBARI-21043
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.5.1
>Reporter: Robert Levas
>Assignee: Harsha
>Priority: Blocker
> Fix For: 3.0.0
>
> Attachments: AMBARI-21043_branch-2.5_01.patch, 
> AMBARI-21043_branch-2.5_02.patch, AMBARI-21043_trunk_01.patch
>
>
> Backport Ambari-17694 to Ambari 2.5.1 because the patch was never committed 
> to branch-2.5 and thus did not make it into Ambari 2.5.0.  
> Most of the changes from Ambari 2.4.x applied without much additional work, 
> however an upgrade path from Ambari 2.5.0 to Ambari 2.5.1 has been created 
> since users of Ambari 2.5.1 may have missed out on the needed changes. This 
> additional work was essentially copying 
> {{org.apache.ambari.server.upgrade.UpgradeCatalog240#updateKAFKAConfigs}} to 
> {{org.apache.ambari.server.upgrade.UpgradeCatalog251#updateKAFKAConfigs} and 
> adding to the unit tests in 
> {{org.apache.ambari.server.upgrade.UpgradeCatalog251Test}}.
> See AMBARI-17694 for more information about the changes. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-21887) Unable to compile amabari-admin and ambari-web

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-21887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-21887.
--
Resolution: Invalid

outdated issue

> Unable to compile amabari-admin and ambari-web
> --
>
> Key: AMBARI-21887
> URL: https://issues.apache.org/jira/browse/AMBARI-21887
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-admin, ambari-web
>Affects Versions: 2.5.1
> Environment: arch : s390x
> OS : ub 16.04
> maven : 3.3.9
> JDK : openjdk8
>Reporter: ketan kunde
>Priority: Blocker
>
> while building ambari-web i get the below logs on doing a mvn clean install 
> -fn
> [INFO] Running 'yarn install ignore-engines pure-lockfile' in 
> /home/apache-ambari-2.5.1-src/ambari-web
> [ERROR] /home/apache-ambari-2.5.1-src/ambari-web/node/node: 1: 
> /home/apache-ambari-2.5.1-src/ambari-web/node/node: Syntax error: "(" 
> unexpected
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 03:17 min
> [INFO] Finished at: 2017-09-06T09:15:56+00:00
> [INFO] Final Memory: 11M/27M
> **
> The below logs are while executing ambari-admin
> Installed node locally.
> [INFO] NPM 2.15.0 is already installed.
> [INFO]
> [INFO] --- frontend-maven-plugin:1.3:npm (npm install) @ ambari-admin ---
> [INFO] Running 'npm install' in 
> /home/apache-ambari-2.5.1-src/ambari-admin/src/main/resources/ui/admin-web
> [ERROR] 
> /home/apache-ambari-2.5.1-src/ambari-admin/src/main/resources/ui/admin-web/node/node:
>  1: 
> /home/apache-ambari-2.5.1-src/ambari-admin/src/main/resources/ui/admin-web/node/node:
>  Syntax error: "(" unexpected
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 01:55 min
> [INFO] Finished at: 2017-09-06T09:21:12+00:00
> [INFO] Final Memory: 12M/30M
> Ned help to this fixed



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-13852) Can't access the stack admin interface [Error 500]

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-13852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-13852.
--
Resolution: Information Provided

> Can't access the stack admin interface [Error 500]
> --
>
> Key: AMBARI-13852
> URL: https://issues.apache.org/jira/browse/AMBARI-13852
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Loïc C. Chanel
>Priority: Blocker
>  Labels: ambari-server, stacktrace
>
> As I click on Stack & Version and then on the Manage Version button in the 
> Versions tab, I get an HTTP 500 Error, with the following stack : 
> HTTP ERROR 500
> Problem accessing /views/ADMIN_VIEW/2.1.2/INSTANCE/. Reason:
> Server Error
> Caused by:
> java.lang.IllegalStateException: No WebApplicationContext found: no 
> ContextLoaderListener registered?
>   at 
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:159)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:429)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.apache.ambari.server.controller.AmbariHandlerList.processHandlers(AmbariHandlerList.java:209)
>   at 
> org.apache.ambari.server.controller.AmbariHandlerList.processHandlers(AmbariHandlerList.java:197)
>   at 
> org.apache.ambari.server.controller.AmbariHandlerList.handle(AmbariHandlerList.java:132)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:370)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>   at 
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>   at 
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:744)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMBARI-13852) Can't access the stack admin interface [Error 500]

2020-11-02 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-13852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17224854#comment-17224854
 ] 

Dmytro Grinenko commented on AMBARI-13852:
--

it seems that admin view with version 2.1.2 is installed, it seems that so 
files on the disk are corrupted.

> Can't access the stack admin interface [Error 500]
> --
>
> Key: AMBARI-13852
> URL: https://issues.apache.org/jira/browse/AMBARI-13852
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Loïc C. Chanel
>Priority: Blocker
>  Labels: ambari-server, stacktrace
>
> As I click on Stack & Version and then on the Manage Version button in the 
> Versions tab, I get an HTTP 500 Error, with the following stack : 
> HTTP ERROR 500
> Problem accessing /views/ADMIN_VIEW/2.1.2/INSTANCE/. Reason:
> Server Error
> Caused by:
> java.lang.IllegalStateException: No WebApplicationContext found: no 
> ContextLoaderListener registered?
>   at 
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:159)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:429)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.apache.ambari.server.controller.AmbariHandlerList.processHandlers(AmbariHandlerList.java:209)
>   at 
> org.apache.ambari.server.controller.AmbariHandlerList.processHandlers(AmbariHandlerList.java:197)
>   at 
> org.apache.ambari.server.controller.AmbariHandlerList.handle(AmbariHandlerList.java:132)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:370)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)
>   at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)
>   at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)
>   at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>   at 
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
>   at 
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
>   at 
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>   at java.lang.Thread.run(Thread.java:744)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-22140) Patch upgrade failure for oozie service

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-22140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-22140.
--
Resolution: Fixed

Fixed in 2.7.4

> Patch upgrade failure for oozie service 
> 
>
> Key: AMBARI-22140
> URL: https://issues.apache.org/jira/browse/AMBARI-22140
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-upgrade
>Affects Versions: 2.6.0
> Environment: ambari-server --version 2.6.0.0-178
>Reporter: Supreeth Sharma
>Priority: Blocker
>  Labels: patch-upgrade
> Fix For: 3.0.0
>
>
> Patch upgrade is failing while performing the upgrade for oozie service.
> Upgrade is failing with below error :
> {code}
> Traceback (most recent call last):
>   File 
> "/var/lib/ambari-agent/cache/common-services/OOZIE/4.0.0.2.0/package/scripts/oozie_server.py",
>  line 150, in 
> OozieServer().execute()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 350, in execute
> method(env)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
>  line 119, in locking_configure
> original_configure(obj, *args, **kw)
>   File 
> "/var/lib/ambari-agent/cache/common-services/OOZIE/4.0.0.2.0/package/scripts/oozie_server.py",
>  line 70, in configure
> oozie(is_server=True, upgrade_type=upgrade_type)
>   File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py", 
> line 89, in thunk
> return fn(*args, **kwargs)
>   File 
> "/var/lib/ambari-agent/cache/common-services/OOZIE/4.0.0.2.0/package/scripts/oozie.py",
>  line 193, in oozie
> oozie_server_specific(upgrade_type)
>   File 
> "/var/lib/ambari-agent/cache/common-services/OOZIE/4.0.0.2.0/package/scripts/oozie.py",
>  line 313, in oozie_server_specific
> not_if  = no_op_test,
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", 
> line 166, in __init__
> self.env.run()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 160, in run
> self.run_action(resource, action)
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", 
> line 124, in run_action
> provider_action()
>   File 
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
>  line 262, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 72, in inner
> result = function(command, **kwargs)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 102, in checked_call
> tries=tries, try_sleep=try_sleep, 
> timeout_kill_strategy=timeout_kill_strategy)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 150, in _call_wrapper
> result = _call(command, **kwargs_copy)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", 
> line 303, in _call
> raise ExecutionFailed(err_msg, code, out, err)
> resource_management.core.exceptions.ExecutionFailed: Execution of 
> 'ambari-sudo.sh cp /usr/hdp/2.6.3.0-158/hadoop/lib/hadoop-lzo*.jar 
> /usr/hdp/current/oozie-server' returned 1. cp: cannot stat 
> `/usr/hdp/2.6.3.0-158/hadoop/lib/hadoop-lzo*.jar': No such file or directory
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-24772) Support cross-stack inheritance

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-24772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-24772.
--
Resolution: Invalid

> Support cross-stack inheritance
> ---
>
> Key: AMBARI-24772
> URL: https://issues.apache.org/jira/browse/AMBARI-24772
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server, stacks
>Affects Versions: 2.8.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Blocker
> Fix For: 2.8.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (AMBARI-24697) [Intermittent] Client installation failures when parallel_execution enabled

2020-11-02 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-24697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17224850#comment-17224850
 ] 

Dmytro Grinenko edited comment on AMBARI-24697 at 11/2/20, 6:02 PM:


It is basically due to slow internet and slow download speeds. The downloads 
task has it's own execution time limit.

It could be adjusted by adding/editing agent.package.install.task.timeout 
property to ambari.properties


was (Author: dgrinenko):
It is basically due to slow internet and slow download speeds. The downloads 
task has it's own execution time limit.

It could be adjusted by adding/editing property to server.properties: 
agent.package.install.task.timeout

> [Intermittent] Client installation failures when parallel_execution enabled
> ---
>
> Key: AMBARI-24697
> URL: https://issues.apache.org/jira/browse/AMBARI-24697
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.2
>Reporter: Srikanth Janardhan
>Priority: Blocker
> Fix For: 2.8.0
>
>
> Several client installation failing in a baked image setup due to timeout 
> with Ambari-2.7.3.0-6 
> {code:title=Infra Solr Client Install failed}
> stderr: 
> Python script has been killed due to timeout after waiting 2400 secs
>  stdout:
> 2018-09-26 04:30:05,749 - Stack Feature Version Info: Cluster Stack=3.0, 
> Command Stack=None, Command Version=None -> 3.0
> 2018-09-26 04:30:05,769 - Using hadoop conf dir: 
> /usr/hdp/current/hadoop-client/conf
> 2018-09-26 04:30:05,773 - Group['cstm-users'] {}
> 2018-09-26 04:30:05,776 - Group['cstm-kms'] {}
> 2018-09-26 04:30:05,777 - Group['cstm-ranger'] {}
> 2018-09-26 04:30:05,777 - Group['cstm-zeppelin'] {}
> 2018-09-26 04:30:05,778 - Group['hdfs'] {}
> 2018-09-26 04:30:05,778 - Group['cstm-livy'] {}
> 2018-09-26 04:30:05,779 - Group['hadoop'] {}
> 2018-09-26 04:30:05,779 - Group['cstm-knox'] {}
> 2018-09-26 04:30:05,779 - Group['cstm-spark'] {}
> 2018-09-26 04:30:05,782 - User['yarn-ats'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,786 - User['superset'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,790 - User['cstm-hive'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,794 - User['cstm-sqoop'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,797 - User['cstm-yarn'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,801 - User['cstm-tez'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['cstm-users', 'hadoop'], 'uid': 
> None}
> 2018-09-26 04:30:05,805 - User['cstm-storm'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,809 - User['cstm-kafka'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,840 - Adding user User['cstm-kafka']
> 2018-09-26 04:30:05,945 - User['cstm-logsearch'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,946 - Adding user User['cstm-logsearch']
> 2018-09-26 04:30:06,283 - User['cstm-infra-solr'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:06,284 - Adding user User['cstm-infra-solr']
> 2018-09-26 04:30:06,491 - User['cstm-mr'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:06,492 - Adding user User['cstm-mr']
> 2018-09-26 04:30:06,732 - User['cstm-zeppelin'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['cstm-zeppelin', 'hadoop'], 'uid': 
> None}
> 2018-09-26 04:30:06,733 - Adding user User['cstm-zeppelin']
> 2018-09-26 04:30:07,044 - User['cstm-oozie'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['cstm-users', 'hadoop'], 'uid': 
> None}
> 2018-09-26 04:30:07,045 - Adding user User['cstm-oozie']
> 2018-09-26 04:30:07,404 - User['cstm-kms'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['cstm-kms', 'hadoop'], 'uid': None}
> 2018-09-26 04:30:07,405 - Adding user User['cstm-kms']
> 2018-09-26 04:30:07,660 - User['cstm-ranger'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['cstm-ranger', 'hadoop'], 'uid': 
> None}
> 2018-09-26 04:30:07,665 - User['cstm-ams'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:07,666 - Adding user User['cstm-ams']
> 2018-09-26 04:30:07,920 - User['cstm-atlas'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True,

[jira] [Resolved] (AMBARI-24773) Support cross-stack inheritance

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-24773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-24773.
--
Resolution: Invalid

> Support cross-stack inheritance
> ---
>
> Key: AMBARI-24773
> URL: https://issues.apache.org/jira/browse/AMBARI-24773
> Project: Ambari
>  Issue Type: Task
>  Components: ambari-server, stacks
>Affects Versions: 2.8.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Blocker
> Fix For: 2.8.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-24697) [Intermittent] Client installation failures when parallel_execution enabled

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-24697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-24697.
--
Resolution: Information Provided

> [Intermittent] Client installation failures when parallel_execution enabled
> ---
>
> Key: AMBARI-24697
> URL: https://issues.apache.org/jira/browse/AMBARI-24697
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.2
>Reporter: Srikanth Janardhan
>Priority: Blocker
> Fix For: 2.8.0
>
>
> Several client installation failing in a baked image setup due to timeout 
> with Ambari-2.7.3.0-6 
> {code:title=Infra Solr Client Install failed}
> stderr: 
> Python script has been killed due to timeout after waiting 2400 secs
>  stdout:
> 2018-09-26 04:30:05,749 - Stack Feature Version Info: Cluster Stack=3.0, 
> Command Stack=None, Command Version=None -> 3.0
> 2018-09-26 04:30:05,769 - Using hadoop conf dir: 
> /usr/hdp/current/hadoop-client/conf
> 2018-09-26 04:30:05,773 - Group['cstm-users'] {}
> 2018-09-26 04:30:05,776 - Group['cstm-kms'] {}
> 2018-09-26 04:30:05,777 - Group['cstm-ranger'] {}
> 2018-09-26 04:30:05,777 - Group['cstm-zeppelin'] {}
> 2018-09-26 04:30:05,778 - Group['hdfs'] {}
> 2018-09-26 04:30:05,778 - Group['cstm-livy'] {}
> 2018-09-26 04:30:05,779 - Group['hadoop'] {}
> 2018-09-26 04:30:05,779 - Group['cstm-knox'] {}
> 2018-09-26 04:30:05,779 - Group['cstm-spark'] {}
> 2018-09-26 04:30:05,782 - User['yarn-ats'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,786 - User['superset'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,790 - User['cstm-hive'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,794 - User['cstm-sqoop'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,797 - User['cstm-yarn'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,801 - User['cstm-tez'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['cstm-users', 'hadoop'], 'uid': 
> None}
> 2018-09-26 04:30:05,805 - User['cstm-storm'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,809 - User['cstm-kafka'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,840 - Adding user User['cstm-kafka']
> 2018-09-26 04:30:05,945 - User['cstm-logsearch'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,946 - Adding user User['cstm-logsearch']
> 2018-09-26 04:30:06,283 - User['cstm-infra-solr'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:06,284 - Adding user User['cstm-infra-solr']
> 2018-09-26 04:30:06,491 - User['cstm-mr'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:06,492 - Adding user User['cstm-mr']
> 2018-09-26 04:30:06,732 - User['cstm-zeppelin'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['cstm-zeppelin', 'hadoop'], 'uid': 
> None}
> 2018-09-26 04:30:06,733 - Adding user User['cstm-zeppelin']
> 2018-09-26 04:30:07,044 - User['cstm-oozie'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['cstm-users', 'hadoop'], 'uid': 
> None}
> 2018-09-26 04:30:07,045 - Adding user User['cstm-oozie']
> 2018-09-26 04:30:07,404 - User['cstm-kms'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['cstm-kms', 'hadoop'], 'uid': None}
> 2018-09-26 04:30:07,405 - Adding user User['cstm-kms']
> 2018-09-26 04:30:07,660 - User['cstm-ranger'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['cstm-ranger', 'hadoop'], 'uid': 
> None}
> 2018-09-26 04:30:07,665 - User['cstm-ams'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:07,666 - Adding user User['cstm-ams']
> 2018-09-26 04:30:07,920 - User['cstm-atlas'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:07,920 - Adding user User['cstm-atlas']
> 2018-09-26 04:30:08,060 - User['cstm-knox'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop', 'cstm-knox'], 'uid': None}
> 2018-09-26 04:30:08,062 - Modifying user cstm-knox
> 2018-09-26 04:30:08,263 - User['cstm-hbase'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:08,273 - User['cstm-hdfs'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hdfs', '

[jira] [Commented] (AMBARI-24697) [Intermittent] Client installation failures when parallel_execution enabled

2020-11-02 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-24697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17224850#comment-17224850
 ] 

Dmytro Grinenko commented on AMBARI-24697:
--

It is basically due to slow internet and slow download speeds. The downloads 
task has it's own execution time limit.

It could be adjusted by adding/editing property to server.properties: 
agent.package.install.task.timeout

> [Intermittent] Client installation failures when parallel_execution enabled
> ---
>
> Key: AMBARI-24697
> URL: https://issues.apache.org/jira/browse/AMBARI-24697
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.2
>Reporter: Srikanth Janardhan
>Priority: Blocker
> Fix For: 2.8.0
>
>
> Several client installation failing in a baked image setup due to timeout 
> with Ambari-2.7.3.0-6 
> {code:title=Infra Solr Client Install failed}
> stderr: 
> Python script has been killed due to timeout after waiting 2400 secs
>  stdout:
> 2018-09-26 04:30:05,749 - Stack Feature Version Info: Cluster Stack=3.0, 
> Command Stack=None, Command Version=None -> 3.0
> 2018-09-26 04:30:05,769 - Using hadoop conf dir: 
> /usr/hdp/current/hadoop-client/conf
> 2018-09-26 04:30:05,773 - Group['cstm-users'] {}
> 2018-09-26 04:30:05,776 - Group['cstm-kms'] {}
> 2018-09-26 04:30:05,777 - Group['cstm-ranger'] {}
> 2018-09-26 04:30:05,777 - Group['cstm-zeppelin'] {}
> 2018-09-26 04:30:05,778 - Group['hdfs'] {}
> 2018-09-26 04:30:05,778 - Group['cstm-livy'] {}
> 2018-09-26 04:30:05,779 - Group['hadoop'] {}
> 2018-09-26 04:30:05,779 - Group['cstm-knox'] {}
> 2018-09-26 04:30:05,779 - Group['cstm-spark'] {}
> 2018-09-26 04:30:05,782 - User['yarn-ats'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,786 - User['superset'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,790 - User['cstm-hive'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,794 - User['cstm-sqoop'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,797 - User['cstm-yarn'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,801 - User['cstm-tez'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['cstm-users', 'hadoop'], 'uid': 
> None}
> 2018-09-26 04:30:05,805 - User['cstm-storm'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,809 - User['cstm-kafka'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,840 - Adding user User['cstm-kafka']
> 2018-09-26 04:30:05,945 - User['cstm-logsearch'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:05,946 - Adding user User['cstm-logsearch']
> 2018-09-26 04:30:06,283 - User['cstm-infra-solr'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:06,284 - Adding user User['cstm-infra-solr']
> 2018-09-26 04:30:06,491 - User['cstm-mr'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:06,492 - Adding user User['cstm-mr']
> 2018-09-26 04:30:06,732 - User['cstm-zeppelin'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['cstm-zeppelin', 'hadoop'], 'uid': 
> None}
> 2018-09-26 04:30:06,733 - Adding user User['cstm-zeppelin']
> 2018-09-26 04:30:07,044 - User['cstm-oozie'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['cstm-users', 'hadoop'], 'uid': 
> None}
> 2018-09-26 04:30:07,045 - Adding user User['cstm-oozie']
> 2018-09-26 04:30:07,404 - User['cstm-kms'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['cstm-kms', 'hadoop'], 'uid': None}
> 2018-09-26 04:30:07,405 - Adding user User['cstm-kms']
> 2018-09-26 04:30:07,660 - User['cstm-ranger'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['cstm-ranger', 'hadoop'], 'uid': 
> None}
> 2018-09-26 04:30:07,665 - User['cstm-ams'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:07,666 - Adding user User['cstm-ams']
> 2018-09-26 04:30:07,920 - User['cstm-atlas'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop'], 'uid': None}
> 2018-09-26 04:30:07,920 - Adding user User['cstm-atlas']
> 2018-09-26 04:30:08,060 - User['cstm-knox'] {'gid': 'hadoop', 
> 'fetch_nonlocal_groups': True, 'groups': ['hadoop', 'cstm-knox'], 'uid': None}
> 2018-09-26 04:30:08,062 - Modifying user cstm-knox
> 2018-0

[jira] [Resolved] (AMBARI-25177) docker build failed for Ambari 2.7.3

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25177.
--
Resolution: Information Provided

> docker build failed for Ambari 2.7.3
> 
>
> Key: AMBARI-25177
> URL: https://issues.apache.org/jira/browse/AMBARI-25177
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.7.3
> Environment: docker version: 1.12.6
> Ambari: 2.7.3
> build ambari with docker
>Reporter: Jared
>Priority: Blocker
>  Labels: docker, maven
> Fix For: 2.7.3
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> It seemed that some problems existed in Dockerfile. Currently maven version 
> is 3.0.5. Python is 2.6.
> Need to upgrade following components version.
> maven 3.5.0
> python 2.7.5
> centos 7.0
> npm 3.10.10
>  
> When executing command "{{docker build -t ambari/build 
> ./dev-support/docker/docker}}",  following problems occurred.
> {color:#205081}_[DEBUG] Configuring mojo 
> org.codehaus.mojo:exec-maven-plugin:1.2.1:exec from plugin realm 
> ClassRealm[plugin>org.codehaus.mojo:exec-maven-plugin:1.2.1, parent: 
> sun.misc.Launcher$AppClassLoader@7852e922]_{color}
>  {color:#205081}_[DEBUG] Configuring mojo 
> 'org.codehaus.mojo:exec-maven-plugin:1.2.1:exec' with basic configurator 
> -->_{color}
>  {color:#205081}_[DEBUG]   (f) basedir = /tmp/ambari/ambari-web_{color}
>  {color:#205081}_[DEBUG]   (f) classpathScope = runtime_{color}
>  {color:#205081}_[DEBUG]   (f) commandlineArgs = -rf public 
> node_modules_{color}
>  {color:#205081}_[DEBUG]   (f) executable = rm_{color}
>  {color:#205081}_[DEBUG]   (f) longClasspath = false_{color}
>  {color:#205081}_[DEBUG]   (f) project = MavenProject: 
> org.apache.ambari:ambari-web:3.0.0.0-SNAPSHOT @ 
> /tmp/ambari/ambari-web/pom.xml_{color}
>  {color:#205081}_[DEBUG]   (f) session = 
> org.apache.maven.execution.MavenSession@61884cb1_{color}
>  {color:#205081}_[DEBUG]   (f) skip = false_{color}
>  {color:#205081}_[DEBUG]   (s) successCodes = [0, 1, 2]_{color}
>  {color:#205081}_[DEBUG]   (f) workingDirectory = 
> /tmp/ambari/ambari-web_{color}
>  {color:#205081}_[DEBUG] – end configuration --_{color}
>  {color:#205081}_[DEBUG] Executing command line: rm -rf public 
> node_modules_{color}
>  {color:#205081}_[INFO]_ {color}
>  {color:#205081}_[INFO] — exec-maven-plugin:1.2.1:exec (clean-mkdir) @ 
> ambari-web ---_{color}
>  {color:#205081}_[DEBUG] Configuring mojo 
> org.codehaus.mojo:exec-maven-plugin:1.2.1:exec from plugin realm 
> ClassRealm[plugin>org.codehaus.mojo:exec-maven-plugin:1.2.1, parent: 
> sun.misc.Launcher$AppClassLoader@7852e922]_{color}
>  {color:#205081}_[DEBUG] Configuring mojo 
> 'org.codehaus.mojo:exec-maven-plugin:1.2.1:exec' with basic configurator 
> -->_{color}
>  {color:#205081}_[DEBUG]   (f) basedir = /tmp/ambari/ambari-web_{color}
>  {color:#205081}_[DEBUG]   (f) classpathScope = runtime_{color}
>  {color:#205081}_[DEBUG]   (f) commandlineArgs =  public_{color}
>  {color:#205081}_[DEBUG]   (f) executable = mkdir_{color}
>  {color:#205081}_[DEBUG]   (f) longClasspath = false_{color}
>  {color:#205081}_[DEBUG]   (f) project = MavenProject: 
> org.apache.ambari:ambari-web:3.0.0.0-SNAPSHOT @ 
> /tmp/ambari/ambari-web/pom.xml_{color}
>  {color:#205081}_[DEBUG]   (f) session = 
> org.apache.maven.execution.MavenSession@61884cb1_{color}
>  {color:#205081}_[DEBUG]   (f) skip = false_{color}
>  {color:#205081}_[DEBUG]   (f) workingDirectory = 
> /tmp/ambari/ambari-web_{color}
>  {color:#205081}_[DEBUG] – end configuration --_{color}
>  {color:#205081}_[DEBUG] Executing command line: mkdir public_{color}
>  {color:#205081}_[INFO] 
> _{color}
>  {color:#205081}_[INFO] Reactor Summary:_{color}
>  {color:#205081}_[INFO]_ {color}
>  {color:#205081}_[INFO] Ambari Web  
> FAILURE [26:16.596s]_{color}
>  {color:#205081}_[INFO] Apache Ambari Project POM . 
> SKIPPED_{color}
>  {color:#205081}_[INFO] Ambari Views .. 
> SKIPPED_{color}
>  {color:#205081}_[INFO] Ambari Admin View . 
> SKIPPED_{color}
>  {color:#205081}_[INFO] ambari-utility  
> SKIPPED_{color}
>  {color:#205081}_[INFO] Ambari Server SPI . 
> SKIPPED_{color}
>  {color:#205081}_[INFO] Ambari Service Advisor  
> SKIPPED_{color}
>  {color:#205081}_[INFO] Ambari Server . 
> SKIPPED_{color}
>  {color:#205081}_[INFO] Ambari Functional Tests ... 
> SKIPPED_{color}
>  {color:#205081}_[INFO] Ambari Agent 

[jira] [Commented] (AMBARI-25177) docker build failed for Ambari 2.7.3

2020-11-02 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-25177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17224848#comment-17224848
 ] 

Dmytro Grinenko commented on AMBARI-25177:
--

" org.codehaus.mojo:flatten-maven-plugin:1.0.1 requires Maven version 3.2.5 " 
while 3.5.0 is used. Please use more recent Ambari versions

> docker build failed for Ambari 2.7.3
> 
>
> Key: AMBARI-25177
> URL: https://issues.apache.org/jira/browse/AMBARI-25177
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.7.3
> Environment: docker version: 1.12.6
> Ambari: 2.7.3
> build ambari with docker
>Reporter: Jared
>Priority: Blocker
>  Labels: docker, maven
> Fix For: 2.7.3
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> It seemed that some problems existed in Dockerfile. Currently maven version 
> is 3.0.5. Python is 2.6.
> Need to upgrade following components version.
> maven 3.5.0
> python 2.7.5
> centos 7.0
> npm 3.10.10
>  
> When executing command "{{docker build -t ambari/build 
> ./dev-support/docker/docker}}",  following problems occurred.
> {color:#205081}_[DEBUG] Configuring mojo 
> org.codehaus.mojo:exec-maven-plugin:1.2.1:exec from plugin realm 
> ClassRealm[plugin>org.codehaus.mojo:exec-maven-plugin:1.2.1, parent: 
> sun.misc.Launcher$AppClassLoader@7852e922]_{color}
>  {color:#205081}_[DEBUG] Configuring mojo 
> 'org.codehaus.mojo:exec-maven-plugin:1.2.1:exec' with basic configurator 
> -->_{color}
>  {color:#205081}_[DEBUG]   (f) basedir = /tmp/ambari/ambari-web_{color}
>  {color:#205081}_[DEBUG]   (f) classpathScope = runtime_{color}
>  {color:#205081}_[DEBUG]   (f) commandlineArgs = -rf public 
> node_modules_{color}
>  {color:#205081}_[DEBUG]   (f) executable = rm_{color}
>  {color:#205081}_[DEBUG]   (f) longClasspath = false_{color}
>  {color:#205081}_[DEBUG]   (f) project = MavenProject: 
> org.apache.ambari:ambari-web:3.0.0.0-SNAPSHOT @ 
> /tmp/ambari/ambari-web/pom.xml_{color}
>  {color:#205081}_[DEBUG]   (f) session = 
> org.apache.maven.execution.MavenSession@61884cb1_{color}
>  {color:#205081}_[DEBUG]   (f) skip = false_{color}
>  {color:#205081}_[DEBUG]   (s) successCodes = [0, 1, 2]_{color}
>  {color:#205081}_[DEBUG]   (f) workingDirectory = 
> /tmp/ambari/ambari-web_{color}
>  {color:#205081}_[DEBUG] – end configuration --_{color}
>  {color:#205081}_[DEBUG] Executing command line: rm -rf public 
> node_modules_{color}
>  {color:#205081}_[INFO]_ {color}
>  {color:#205081}_[INFO] — exec-maven-plugin:1.2.1:exec (clean-mkdir) @ 
> ambari-web ---_{color}
>  {color:#205081}_[DEBUG] Configuring mojo 
> org.codehaus.mojo:exec-maven-plugin:1.2.1:exec from plugin realm 
> ClassRealm[plugin>org.codehaus.mojo:exec-maven-plugin:1.2.1, parent: 
> sun.misc.Launcher$AppClassLoader@7852e922]_{color}
>  {color:#205081}_[DEBUG] Configuring mojo 
> 'org.codehaus.mojo:exec-maven-plugin:1.2.1:exec' with basic configurator 
> -->_{color}
>  {color:#205081}_[DEBUG]   (f) basedir = /tmp/ambari/ambari-web_{color}
>  {color:#205081}_[DEBUG]   (f) classpathScope = runtime_{color}
>  {color:#205081}_[DEBUG]   (f) commandlineArgs =  public_{color}
>  {color:#205081}_[DEBUG]   (f) executable = mkdir_{color}
>  {color:#205081}_[DEBUG]   (f) longClasspath = false_{color}
>  {color:#205081}_[DEBUG]   (f) project = MavenProject: 
> org.apache.ambari:ambari-web:3.0.0.0-SNAPSHOT @ 
> /tmp/ambari/ambari-web/pom.xml_{color}
>  {color:#205081}_[DEBUG]   (f) session = 
> org.apache.maven.execution.MavenSession@61884cb1_{color}
>  {color:#205081}_[DEBUG]   (f) skip = false_{color}
>  {color:#205081}_[DEBUG]   (f) workingDirectory = 
> /tmp/ambari/ambari-web_{color}
>  {color:#205081}_[DEBUG] – end configuration --_{color}
>  {color:#205081}_[DEBUG] Executing command line: mkdir public_{color}
>  {color:#205081}_[INFO] 
> _{color}
>  {color:#205081}_[INFO] Reactor Summary:_{color}
>  {color:#205081}_[INFO]_ {color}
>  {color:#205081}_[INFO] Ambari Web  
> FAILURE [26:16.596s]_{color}
>  {color:#205081}_[INFO] Apache Ambari Project POM . 
> SKIPPED_{color}
>  {color:#205081}_[INFO] Ambari Views .. 
> SKIPPED_{color}
>  {color:#205081}_[INFO] Ambari Admin View . 
> SKIPPED_{color}
>  {color:#205081}_[INFO] ambari-utility  
> SKIPPED_{color}
>  {color:#205081}_[INFO] Ambari Server SPI . 
> SKIPPED_{color}
>  {color:#205081}_[INFO] Ambari Service Advisor  
> SKIPPED_{color}
>  {color:#205081}_[INFO] Ambari Server . 
> SKIPPED_{color}
>  {co

[jira] [Commented] (AMBARI-25427) AMBARI V2.7.4.0 ERROR AT MAIN COMPILATION WORK AROUND IN METRICS MODULE NOT RESOLVE THE PROBLEM

2020-11-02 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-25427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17224845#comment-17224845
 ] 

Dmytro Grinenko commented on AMBARI-25427:
--

Please use 2.7.5 instead, or build only required modules as following: 

mvn -am package rpm:rpm -DskipTests -pl ambari-server,ambari-agent

> AMBARI V2.7.4.0 ERROR AT MAIN COMPILATION WORK AROUND IN METRICS MODULE NOT 
> RESOLVE THE PROBLEM
> ---
>
> Key: AMBARI-25427
> URL: https://issues.apache.org/jira/browse/AMBARI-25427
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics, ambari-server, metrics
>Affects Versions: 2.7.4
> Environment: CentOS 7
> Maven 3.6
> Java JDK 8 
> all packages for compillation installed.  
>Reporter: Cleyson Barros
>Priority: Blocker
>  Labels: build
> Attachments: AMBARI main error v2.7.4 NOT compiled
>
>
> Hello folks, 
> I found some problems to compile version 2.7.4, some errors happen at the 
> compilation of the METRICS module, but it affects the complete build.  Making 
> it not FUNCTIONAL. 
> I'll add a file with the result of the compilation, clean tests, and the work 
> around in the Metrics Module not result at the end in a solution to build the 
> project. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25427) AMBARI V2.7.4.0 ERROR AT MAIN COMPILATION WORK AROUND IN METRICS MODULE NOT RESOLVE THE PROBLEM

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25427.
--
Resolution: Information Provided

> AMBARI V2.7.4.0 ERROR AT MAIN COMPILATION WORK AROUND IN METRICS MODULE NOT 
> RESOLVE THE PROBLEM
> ---
>
> Key: AMBARI-25427
> URL: https://issues.apache.org/jira/browse/AMBARI-25427
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics, ambari-server, metrics
>Affects Versions: 2.7.4
> Environment: CentOS 7
> Maven 3.6
> Java JDK 8 
> all packages for compillation installed.  
>Reporter: Cleyson Barros
>Priority: Blocker
>  Labels: build
> Attachments: AMBARI main error v2.7.4 NOT compiled
>
>
> Hello folks, 
> I found some problems to compile version 2.7.4, some errors happen at the 
> compilation of the METRICS module, but it affects the complete build.  Making 
> it not FUNCTIONAL. 
> I'll add a file with the result of the compilation, clean tests, and the work 
> around in the Metrics Module not result at the end in a solution to build the 
> project. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25440) Server sets blueprint_provisioning_state for component to finished before start command execution

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25440.
--
Resolution: Fixed

> Server sets blueprint_provisioning_state for component to finished before 
> start command execution
> -
>
> Key: AMBARI-25440
> URL: https://issues.apache.org/jira/browse/AMBARI-25440
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Reporter: Papirkovskyy Myroslav
>Assignee: Papirkovskyy Myroslav
>Priority: Blocker
>  Labels: pull-request-available
> Fix For: 2.7.5
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Server sends host level parameters update with 
> blueprint_provisioning_state="FINISHED" right after start execution command 
> generation. This may led to performing of autostart command on the agent side 
> before execution of start command.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-23217) Spark and Spark2 SSL credentials in Ambari UI are in plain text rather than being hidden

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-23217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-23217.
--
Resolution: Invalid

Ambari meta didn't describe the mentioned properties due to process of turning 
SSL for the services on is purely manual and not depends on Ambari.


> Spark and Spark2 SSL credentials in Ambari UI are in plain text rather than 
> being hidden
> 
>
> Key: AMBARI-23217
> URL: https://issues.apache.org/jira/browse/AMBARI-23217
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-sever
>Affects Versions: 2.6.2
>Reporter: Supreeth Sharma
>Priority: Blocker
>
> Below properties which are part of Spark and Spark2 are in plaintext rather 
> than being hidden in Ambari
> livy.key-password
> livy.keystore.password
> livy.ssl.trustStorePassword
> spark.ssl.keyPassword
> spark.ssl.keyStorePassword
> spark.ssl.trustStorePassword
> spark.ssl.keyPassword
> spark.ssl.keyStorePassword
> spark.ssl.trustStorePassword



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-23489) NameNode is unable to start post AU with NoClassDefFound Error For ListDelimiterHandler

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-23489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-23489.
--
Resolution: Invalid

> NameNode is unable to start post AU with NoClassDefFound Error For 
> ListDelimiterHandler
> ---
>
> Key: AMBARI-23489
> URL: https://issues.apache.org/jira/browse/AMBARI-23489
> Project: Ambari
>  Issue Type: Bug
>Reporter: Jasmeen Kaur
>Priority: Blocker
>
> Post Ambari Upgrade to 2.7.0.0 from 2.6.1.0 , name node is not able to start.
> {code:java}
> STARTUP_MSG:   classpath = 
> /usr/hdp/2.6.4.0-91/hadoop/conf:/usr/hdp/2.6.4.0-91/hadoop/lib/jettison-1.1.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/api-asn1-api-1.0.0-M20.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jackson-mapper-asl-1.9.13.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/paranamer-2.3.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/zookeeper-3.4.6.2.6.4.0-91.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/commons-configuration-1.6.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jersey-server-1.9.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/aws-java-sdk-s3-1.10.6.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/java-xmlbuilder-0.4.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/htrace-core-3.1.0-incubating.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/aws-java-sdk-kms-1.10.6.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/slf4j-api-1.7.10.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jackson-annotations-2.2.3.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/api-util-1.0.0-M20.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/commons-cli-1.2.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/httpclient-4.5.2.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/hadoop-lzo-0.6.0.2.6.4.0-91-javadoc.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/apacheds-i18n-2.0.0-M15.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/azure-keyvault-core-0.8.0.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/guava-11.0.2.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jersey-json-1.9.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/ranger-plugin-classloader-0.7.0.2.6.4.0-91.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/commons-lang-2.6.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jsch-0.1.54.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jcip-annotations-1.0.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/curator-recipes-2.7.1.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jaxb-impl-2.2.3-1.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jackson-core-asl-1.9.13.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jersey-core-1.9.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jackson-databind-2.2.3.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/nimbus-jose-jwt-3.9.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/hamcrest-core-1.3.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/snappy-java-1.0.4.1.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/commons-math3-3.1.1.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/commons-logging-1.1.3.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/apacheds-kerberos-codec-2.0.0-M15.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/log4j-1.2.17.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/junit-4.11.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/commons-lang3-3.4.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jsp-api-2.1.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/commons-compress-1.4.1.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/stax-api-1.0-2.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/servlet-api-2.5.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/commons-digester-1.8.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/json-smart-1.1.1.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jetty-util-6.1.26.hwx.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/ojdbc6.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/curator-framework-2.7.1.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/activation-1.1.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/hadoop-lzo-0.6.0.2.6.4.0-91.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/netty-3.6.2.Final.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/avro-1.7.4.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/azure-storage-5.4.0.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/slf4j-log4j12-1.7.10.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/commons-collections-3.2.2.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jetty-sslengine-6.1.26.hwx.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/commons-net-3.1.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/commons-codec-1.4.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/httpcore-4.4.4.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/xz-1.0.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/aws-java-sdk-core-1.10.6.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/asm-3.2.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jackson-xc-1.9.13.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/commons-beanutils-core-1.8.0.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/ranger-hdfs-plugin-shim-0.7.0.2.6.4.0-91.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jsr305-3.0.0.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/ranger-yarn-plugin-shim-0.7.0.2.6.4.0-91.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/commons-io-2.4.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/mockito-all-1.8.5.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jackson-jaxrs-1.9.13.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jackson-core-2.2.3.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/xmlenc-0.52.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/joda-time-2.9.4.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/jaxb-api-2.2.2.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/gson-2.2.4.jar:/usr/hdp/2.6.4.0-91/hadoop/lib/commons-beanutils-1.7.0.

[jira] [Resolved] (AMBARI-25522) KeyError when Adding Custom Ambari Service

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25522.
--
Resolution: Information Provided

> KeyError when Adding Custom Ambari Service
> --
>
> Key: AMBARI-25522
> URL: https://issues.apache.org/jira/browse/AMBARI-25522
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-web
>Affects Versions: 2.7.5
>Reporter: Steven Matison
>Priority: Blocker
>
> When attempting to add any custom service to ambari  (user group management 
> on) the following error occurs:
> {noformat}
> KeyError: u'serviceuser'{noformat}
> or example:
> {noformat}
> KeyError: u'flink'{noformat}
> A current bulky work around is a python to disable user group management:
> {code:java}
> python /var/lib/ambari-server/resources/scripts/configs.py -u admin -p admin 
> -n DDP -l hdp.dfheinz.com -t 8080 -a set -c cluster-env -k  
> ignore_groupsusers_create -v true{code}
>  I have tried to find a source of the users in ambari metastore, as well as 
> proper/correct source code in the custom service fileset to add/create the 
> user:group requirements.  I have not been successful.
> I am currently working on a seamless install of HDP with 3 different Third 
> party services and this is a blocker to this solution.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMBARI-25522) KeyError when Adding Custom Ambari Service

2020-11-02 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-25522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17224833#comment-17224833
 ] 

Dmytro Grinenko commented on AMBARI-25522:
--

The way how users and groups are defined for the service: 

https://github.com/apache/ambari/blob/branch-2.7/ambari-server/src/main/resources/common-services/ZEPPELIN/0.7.0/configuration/zeppelin-env.xml#L31-L64


property-type: USER, GROUP






> KeyError when Adding Custom Ambari Service
> --
>
> Key: AMBARI-25522
> URL: https://issues.apache.org/jira/browse/AMBARI-25522
> Project: Ambari
>  Issue Type: Improvement
>  Components: ambari-web
>Affects Versions: 2.7.5
>Reporter: Steven Matison
>Priority: Blocker
>
> When attempting to add any custom service to ambari  (user group management 
> on) the following error occurs:
> {noformat}
> KeyError: u'serviceuser'{noformat}
> or example:
> {noformat}
> KeyError: u'flink'{noformat}
> A current bulky work around is a python to disable user group management:
> {code:java}
> python /var/lib/ambari-server/resources/scripts/configs.py -u admin -p admin 
> -n DDP -l hdp.dfheinz.com -t 8080 -a set -c cluster-env -k  
> ignore_groupsusers_create -v true{code}
>  I have tried to find a source of the users in ambari metastore, as well as 
> proper/correct source code in the custom service fileset to add/create the 
> user:group requirements.  I have not been successful.
> I am currently working on a seamless install of HDP with 3 different Third 
> party services and this is a blocker to this solution.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMBARI-25531) Failed to execute goal au.com.alderaan:eclipselink-staticweave-maven-plugin

2020-11-02 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-25531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17224826#comment-17224826
 ] 

Dmytro Grinenko commented on AMBARI-25531:
--

Not reproduced in same environment

> Failed to execute goal au.com.alderaan:eclipselink-staticweave-maven-plugin
> ---
>
> Key: AMBARI-25531
> URL: https://issues.apache.org/jira/browse/AMBARI-25531
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
> Environment: RHEL 7
>Reporter: Berkay Öztürk
>Priority: Blocker
>
> Attempting to build Ambari with this command
> {code:java}
> mvn -B clean install rpm:rpm -DnewVersion=2.7.5.0.0 
> -DbuildNumber=5895e4ed6b30a2da8a90fee2403b6cab91d19972 -DskipTests 
> -Dpython.ver="python >= 2.6" -Drat.ignoreErrors=true
> {code}
> Throws NullPointerException:
> {code:java}
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Ambari Main 2.7.5.0.0 .. SUCCESS [ 19.701 
> s]
> [INFO] Apache Ambari Project POM 2.7.5.0.0  SUCCESS [  0.249 
> s]
> [INFO] Ambari Web 2.7.5.0.0 ... SUCCESS [01:00 
> min]
> [INFO] Ambari Views 2.7.5.0.0 . SUCCESS [  1.574 
> s]
> [INFO] Ambari Admin View 2.7.5.0.0  SUCCESS [ 18.467 
> s]
> [INFO] ambari-utility 1.0.0.0-SNAPSHOT  SUCCESS [  6.424 
> s]
> [INFO] ambari-metrics 2.7.5.0.0 ... SUCCESS [  2.133 
> s]
> [INFO] Ambari Metrics Common 2.7.5.0.0  SUCCESS [  7.817 
> s]
> [INFO] Ambari Metrics Hadoop Sink 2.7.5.0.0 ... SUCCESS [  6.077 
> s]
> [INFO] Ambari Metrics Flume Sink 2.7.5.0.0  SUCCESS [  2.924 
> s]
> [INFO] Ambari Metrics Kafka Sink 2.7.5.0.0  SUCCESS [  3.095 
> s]
> [INFO] Ambari Metrics Storm Sink 2.7.5.0.0  SUCCESS [  2.274 
> s]
> [INFO] Ambari Metrics Storm Sink (Legacy) 2.7.5.0.0 ... SUCCESS [  2.146 
> s]
> [INFO] Ambari Metrics Collector 2.7.5.0.0 . SUCCESS [03:44 
> min]
> [INFO] Ambari Metrics Monitor 2.7.5.0.0 ... SUCCESS [  1.452 
> s]
> [INFO] Ambari Metrics Grafana 2.7.5.0.0 ... SUCCESS [  2.906 
> s]
> [INFO] Ambari Metrics Host Aggregator 2.7.5.0.0 ... SUCCESS [  8.754 
> s]
> [INFO] Ambari Metrics Assembly 2.7.5.0.0 .. SUCCESS [01:49 
> min]
> [INFO] Ambari Service Advisor 1.0.0.0-SNAPSHOT  SUCCESS [  1.164 
> s]
> [INFO] Ambari Server 2.7.5.0.0  FAILURE [ 28.664 
> s]
> [INFO] Ambari Functional Tests 2.7.5.0.0 .. SKIPPED
> [INFO] Ambari Agent 2.7.5.0.0 . SKIPPED
> [INFO] ambari-logsearch 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Logsearch Appender 2.7.5.0.0  SKIPPED
> [INFO] Ambari Logsearch Config Api 2.7.5.0.0 .. SKIPPED
> [INFO] Ambari Logsearch Config JSON 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Logsearch Config Solr 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Logsearch Config Zookeeper 2.7.5.0.0  SKIPPED
> [INFO] Ambari Logsearch Config Local 2.7.5.0.0  SKIPPED
> [INFO] Ambari Logsearch Log Feeder Plugin Api 2.7.5.0.0 ... SKIPPED
> [INFO] Ambari Logsearch Log Feeder Container Registry 2.7.5.0.0 SKIPPED
> [INFO] Ambari Logsearch Log Feeder 2.7.5.0.0 .. SKIPPED
> [INFO] Ambari Logsearch Web 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Logsearch Server 2.7.5.0.0 .. SKIPPED
> [INFO] Ambari Logsearch Assembly 2.7.5.0.0  SKIPPED
> [INFO] Ambari Logsearch Integration Test 2.7.5.0.0  SKIPPED
> [INFO] ambari-infra 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Infra Solr Client 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Infra Solr Plugin 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Infra Manager 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Infra Assembly 2.7.5.0.0  SKIPPED
> [INFO] Ambari Infra Manager Integration Tests 2.7.5.0.0 ... SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  08:32 min
> [INFO] Finished at: 2020-07-13T15:42:09+03:00
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> au.com.alderaan:eclipselink-staticweave-maven-plugin:1.0.4:weave (default) on 
> project ambari-server: Execution default of goal 
> au.com.alderaan:eclip

[jira] [Resolved] (AMBARI-25531) Failed to execute goal au.com.alderaan:eclipselink-staticweave-maven-plugin

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25531.
--
Resolution: Cannot Reproduce

> Failed to execute goal au.com.alderaan:eclipselink-staticweave-maven-plugin
> ---
>
> Key: AMBARI-25531
> URL: https://issues.apache.org/jira/browse/AMBARI-25531
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.5
> Environment: RHEL 7
>Reporter: Berkay Öztürk
>Priority: Blocker
>
> Attempting to build Ambari with this command
> {code:java}
> mvn -B clean install rpm:rpm -DnewVersion=2.7.5.0.0 
> -DbuildNumber=5895e4ed6b30a2da8a90fee2403b6cab91d19972 -DskipTests 
> -Dpython.ver="python >= 2.6" -Drat.ignoreErrors=true
> {code}
> Throws NullPointerException:
> {code:java}
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Ambari Main 2.7.5.0.0 .. SUCCESS [ 19.701 
> s]
> [INFO] Apache Ambari Project POM 2.7.5.0.0  SUCCESS [  0.249 
> s]
> [INFO] Ambari Web 2.7.5.0.0 ... SUCCESS [01:00 
> min]
> [INFO] Ambari Views 2.7.5.0.0 . SUCCESS [  1.574 
> s]
> [INFO] Ambari Admin View 2.7.5.0.0  SUCCESS [ 18.467 
> s]
> [INFO] ambari-utility 1.0.0.0-SNAPSHOT  SUCCESS [  6.424 
> s]
> [INFO] ambari-metrics 2.7.5.0.0 ... SUCCESS [  2.133 
> s]
> [INFO] Ambari Metrics Common 2.7.5.0.0  SUCCESS [  7.817 
> s]
> [INFO] Ambari Metrics Hadoop Sink 2.7.5.0.0 ... SUCCESS [  6.077 
> s]
> [INFO] Ambari Metrics Flume Sink 2.7.5.0.0  SUCCESS [  2.924 
> s]
> [INFO] Ambari Metrics Kafka Sink 2.7.5.0.0  SUCCESS [  3.095 
> s]
> [INFO] Ambari Metrics Storm Sink 2.7.5.0.0  SUCCESS [  2.274 
> s]
> [INFO] Ambari Metrics Storm Sink (Legacy) 2.7.5.0.0 ... SUCCESS [  2.146 
> s]
> [INFO] Ambari Metrics Collector 2.7.5.0.0 . SUCCESS [03:44 
> min]
> [INFO] Ambari Metrics Monitor 2.7.5.0.0 ... SUCCESS [  1.452 
> s]
> [INFO] Ambari Metrics Grafana 2.7.5.0.0 ... SUCCESS [  2.906 
> s]
> [INFO] Ambari Metrics Host Aggregator 2.7.5.0.0 ... SUCCESS [  8.754 
> s]
> [INFO] Ambari Metrics Assembly 2.7.5.0.0 .. SUCCESS [01:49 
> min]
> [INFO] Ambari Service Advisor 1.0.0.0-SNAPSHOT  SUCCESS [  1.164 
> s]
> [INFO] Ambari Server 2.7.5.0.0  FAILURE [ 28.664 
> s]
> [INFO] Ambari Functional Tests 2.7.5.0.0 .. SKIPPED
> [INFO] Ambari Agent 2.7.5.0.0 . SKIPPED
> [INFO] ambari-logsearch 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Logsearch Appender 2.7.5.0.0  SKIPPED
> [INFO] Ambari Logsearch Config Api 2.7.5.0.0 .. SKIPPED
> [INFO] Ambari Logsearch Config JSON 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Logsearch Config Solr 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Logsearch Config Zookeeper 2.7.5.0.0  SKIPPED
> [INFO] Ambari Logsearch Config Local 2.7.5.0.0  SKIPPED
> [INFO] Ambari Logsearch Log Feeder Plugin Api 2.7.5.0.0 ... SKIPPED
> [INFO] Ambari Logsearch Log Feeder Container Registry 2.7.5.0.0 SKIPPED
> [INFO] Ambari Logsearch Log Feeder 2.7.5.0.0 .. SKIPPED
> [INFO] Ambari Logsearch Web 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Logsearch Server 2.7.5.0.0 .. SKIPPED
> [INFO] Ambari Logsearch Assembly 2.7.5.0.0  SKIPPED
> [INFO] Ambari Logsearch Integration Test 2.7.5.0.0  SKIPPED
> [INFO] ambari-infra 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Infra Solr Client 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Infra Solr Plugin 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Infra Manager 2.7.5.0.0 . SKIPPED
> [INFO] Ambari Infra Assembly 2.7.5.0.0  SKIPPED
> [INFO] Ambari Infra Manager Integration Tests 2.7.5.0.0 ... SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  08:32 min
> [INFO] Finished at: 2020-07-13T15:42:09+03:00
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> au.com.alderaan:eclipselink-staticweave-maven-plugin:1.0.4:weave (default) on 
> project ambari-server: Execution default of goal 
> au.com.alderaan:eclipselink-staticweave-maven-plugin:1.0.4:weave failed. 
> Nul

[jira] [Resolved] (AMBARI-25541) Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (Gulp build) on project ambari-admin

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25541.
--
Resolution: Duplicate

Dup of  AMBARI-25542

> Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2.1:exec (Gulp 
> build) on project ambari-admin
> --
>
> Key: AMBARI-25541
> URL: https://issues.apache.org/jira/browse/AMBARI-25541
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-admin
>Affects Versions: 2.7.5
> Environment: Ubuntu
>Reporter: Miftahul Huda
>Priority: Blocker
>  Labels: build
> Attachments: Screenshot from 2020-08-06 18-56-04.png
>
>
> Attempting to build Ambari with this command:
> {{mvn -B clean install jdeb:jdeb -DnewVersion=}}{{2.7}}{{.}}{{3.0}}{{.}}{{0}} 
> {{-DbuildNumber=4295bb16c439cbc8fb0e7362f19768dde1477868 -DskipTests 
> -Dpython.ver=}}{{"python >= 2.6"}}
> Throws Command execution failed:
> !Screenshot from 2020-08-06 18-56-04.png!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25542) Could not resolve dependencies for project org.apache.ambari:ambari-metrics-storm-sink-legacy:jar:2.7.5.0.0: Failure to find org.apache.storm:storm-core:jar:0.10.0.2.3.

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25542:
-
Affects Version/s: (was: 2.7.5)
   2.7.3

> Could not resolve dependencies for project 
> org.apache.ambari:ambari-metrics-storm-sink-legacy:jar:2.7.5.0.0: Failure to 
> find org.apache.storm:storm-core:jar:0.10.0.2.3.0.0-2557 in 
> https://repo.maven.apache.org/maven2 was cached in the local repository
> ---
>
> Key: AMBARI-25542
> URL: https://issues.apache.org/jira/browse/AMBARI-25542
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.7.3
> Environment: Ubuntu
>Reporter: Miftahul Huda
>Assignee: Dmytro Grinenko
>Priority: Blocker
> Attachments: Screenshot from 2020-08-07 09-23-30.png
>
>
> Attempting to build Ambari with this command:
> {{mvn -B clean install jdeb:jdeb -DnewVersion=}}{{2.7}}{{.}}{{3.0}}{{.}}{{0}} 
> {{-DbuildNumber=4295bb16c439cbc8fb0e7362f19768dde1477868 -DskipTests 
> -Dpython.ver=}}{{"python >= 2.6"}}
> Throws Command execution failed:
> !Screenshot from 2020-08-07 09-23-30.png!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25542) Could not resolve dependencies for project org.apache.ambari:ambari-metrics-storm-sink-legacy:jar:2.7.5.0.0: Failure to find org.apache.storm:storm-core:jar:0.10.0.2.3

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25542.
--
Resolution: Won't Fix

Version 2.7.3 is outdated

> Could not resolve dependencies for project 
> org.apache.ambari:ambari-metrics-storm-sink-legacy:jar:2.7.5.0.0: Failure to 
> find org.apache.storm:storm-core:jar:0.10.0.2.3.0.0-2557 in 
> https://repo.maven.apache.org/maven2 was cached in the local repository
> ---
>
> Key: AMBARI-25542
> URL: https://issues.apache.org/jira/browse/AMBARI-25542
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.7.5
> Environment: Ubuntu
>Reporter: Miftahul Huda
>Assignee: Dmytro Grinenko
>Priority: Blocker
> Attachments: Screenshot from 2020-08-07 09-23-30.png
>
>
> Attempting to build Ambari with this command:
> {{mvn -B clean install jdeb:jdeb -DnewVersion=}}{{2.7}}{{.}}{{3.0}}{{.}}{{0}} 
> {{-DbuildNumber=4295bb16c439cbc8fb0e7362f19768dde1477868 -DskipTests 
> -Dpython.ver=}}{{"python >= 2.6"}}
> Throws Command execution failed:
> !Screenshot from 2020-08-07 09-23-30.png!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25479) Set Keytab: Kerberos Client operation takes lot of time and timing out

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25479:
-
Priority: Minor  (was: Blocker)

> Set Keytab: Kerberos Client operation takes lot of time and timing out
> --
>
> Key: AMBARI-25479
> URL: https://issues.apache.org/jira/browse/AMBARI-25479
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.0
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> During HDP upgrade re-generate keytabs operations the steps is timing out. 
> "Set Keytab: Kerberos Client" is taking more than hour and in the process 
> ambari agents are loosing the heart beat and step is getting failed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25479) Set Keytab: Kerberos Client operation takes lot of time and timing out

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25479:
-
Fix Version/s: (was: 2.7.6)

> Set Keytab: Kerberos Client operation takes lot of time and timing out
> --
>
> Key: AMBARI-25479
> URL: https://issues.apache.org/jira/browse/AMBARI-25479
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.0
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Blocker
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> During HDP upgrade re-generate keytabs operations the steps is timing out. 
> "Set Keytab: Kerberos Client" is taking more than hour and in the process 
> ambari agents are loosing the heart beat and step is getting failed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25479) Set Keytab: Kerberos Client operation takes lot of time and timing out

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25479:
-
Labels:   (was: pull-request-available)

> Set Keytab: Kerberos Client operation takes lot of time and timing out
> --
>
> Key: AMBARI-25479
> URL: https://issues.apache.org/jira/browse/AMBARI-25479
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.0
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Blocker
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> During HDP upgrade re-generate keytabs operations the steps is timing out. 
> "Set Keytab: Kerberos Client" is taking more than hour and in the process 
> ambari agents are loosing the heart beat and step is getting failed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25479) Set Keytab: Kerberos Client operation takes lot of time and timing out

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25479:
-
Status: Open  (was: Patch Available)

> Set Keytab: Kerberos Client operation takes lot of time and timing out
> --
>
> Key: AMBARI-25479
> URL: https://issues.apache.org/jira/browse/AMBARI-25479
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: 2.7.0
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Blocker
>  Labels: pull-request-available
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> During HDP upgrade re-generate keytabs operations the steps is timing out. 
> "Set Keytab: Kerberos Client" is taking more than hour and in the process 
> ambari agents are loosing the heart beat and step is getting failed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (AMBARI-25573) Ambari Metrics save as JSON/CSV use metricName instead of default name.

2020-11-02 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-25573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17224575#comment-17224575
 ] 

Dmytro Grinenko edited comment on AMBARI-25573 at 11/2/20, 10:41 AM:
-

The commit causing issues with tests, reverting...  please fix the issue

 

PhantomJS 2.1.1 (Linux 0.0.0) Ambari Web Unit tests 
test/mixins/common/widgets/export_metrics_mixin_test App.ExportMetricsMixin 
#exportGraphDataSuccessCallback export to CSV "before each" hook for 
"downloadTextFile was called needed number of times" FAILEDPhantomJS 2.1.1 
(Linux 0.0.0) Ambari Web Unit tests 
test/mixins/common/widgets/export_metrics_mixin_test App.ExportMetricsMixin 
#exportGraphDataSuccessCallback export to CSV "before each" hook for 
"downloadTextFile was called needed number of times" FAILED undefined is not an 
object (evaluating 'this.get('targetView').title.replace') 
getCustomFileName@app/mixins/common/widgets/export_metrics_mixin.js:9:2097 
exportGraphDataSuccessCallback@app/mixins/common/widgets/export_metrics_mixin.js:9:3097
 test/mixins/common/widgets/export_metrics_mixin_test.js:209:45 
callFn@node_modules/mocha/mocha.js:4471:25 
run@node_modules/mocha/mocha.js:4464:13 
next@node_modules/mocha/mocha.js:4810:13 node_modules/mocha/mocha.js:4832:9 
timeslice@node_modules/mocha/mocha.js:75:27PhantomJS 2.1.1 (Linux 0.0.0): 
Executed 13188 of 22478 (1 FAILED) (skipped 33) (0 secs / 4.611 secs)PhantomJS 
2.1.1 (Linux 0.0.0) Ambari Web Unit tests 
test/mixins/common/widgets/export_metrics_mixin_test App.ExportMetricsMixin 
#exportGraphDataSuccessCallback export to JSON "before each" hook for 
"downloadTextFile was called needed number of times" FAILED undefined is not an 
object (evaluating 'this.get('targetView').title.replace') 
getCustomFileName@app/mixins/common/widgets/export_metrics_mixin.js:9:2097 
exportGraphDataSuccessCallback@app/mixins/common/widgets/export_metrics_mixin.js:9:3097
 test/mixins/common/widgets/export_metrics_mixin_test.js:209:45 
callFn@node_modules/mocha/mocha.js:4471:25 
run@node_modules/mocha/mocha.js:4464:13 
next@node_modules/mocha/mocha.js:4810:13 node_modules/mocha/mocha.js:4832:9 
timeslice@node_modules/mocha/mocha.js:75:27


was (Author: dgrinenko):
The commit causing issues with tests, reverting...

 

PhantomJS 2.1.1 (Linux 0.0.0) Ambari Web Unit tests 
test/mixins/common/widgets/export_metrics_mixin_test App.ExportMetricsMixin 
#exportGraphDataSuccessCallback export to CSV "before each" hook for 
"downloadTextFile was called needed number of times" FAILEDPhantomJS 2.1.1 
(Linux 0.0.0) Ambari Web Unit tests 
test/mixins/common/widgets/export_metrics_mixin_test App.ExportMetricsMixin 
#exportGraphDataSuccessCallback export to CSV "before each" hook for 
"downloadTextFile was called needed number of times" FAILED undefined is not an 
object (evaluating 'this.get('targetView').title.replace') 
getCustomFileName@app/mixins/common/widgets/export_metrics_mixin.js:9:2097 
exportGraphDataSuccessCallback@app/mixins/common/widgets/export_metrics_mixin.js:9:3097
 test/mixins/common/widgets/export_metrics_mixin_test.js:209:45 
callFn@node_modules/mocha/mocha.js:4471:25 
run@node_modules/mocha/mocha.js:4464:13 
next@node_modules/mocha/mocha.js:4810:13 node_modules/mocha/mocha.js:4832:9 
timeslice@node_modules/mocha/mocha.js:75:27PhantomJS 2.1.1 (Linux 0.0.0): 
Executed 13188 of 22478 (1 FAILED) (skipped 33) (0 secs / 4.611 secs)PhantomJS 
2.1.1 (Linux 0.0.0) Ambari Web Unit tests 
test/mixins/common/widgets/export_metrics_mixin_test App.ExportMetricsMixin 
#exportGraphDataSuccessCallback export to JSON "before each" hook for 
"downloadTextFile was called needed number of times" FAILED undefined is not an 
object (evaluating 'this.get('targetView').title.replace') 
getCustomFileName@app/mixins/common/widgets/export_metrics_mixin.js:9:2097 
exportGraphDataSuccessCallback@app/mixins/common/widgets/export_metrics_mixin.js:9:3097
 test/mixins/common/widgets/export_metrics_mixin_test.js:209:45 
callFn@node_modules/mocha/mocha.js:4471:25 
run@node_modules/mocha/mocha.js:4464:13 
next@node_modules/mocha/mocha.js:4810:13 node_modules/mocha/mocha.js:4832:9 
timeslice@node_modules/mocha/mocha.js:75:27

> Ambari Metrics save as JSON/CSV use metricName instead of  default name.
> 
>
> Key: AMBARI-25573
> URL: https://issues.apache.org/jira/browse/AMBARI-25573
> Project: Ambari
>  Issue Type: Improvement
>Affects Versions: 2.7.5
>Reporter: akiyamaneko
>Priority: Major
>  Labels: pull-request-available, widget
> Fix For: 2.7.6
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> The name of the metrics data exported in Ambari-web is always data.json/csv, 
> and the exported file must be renamed to disting

[jira] [Commented] (AMBARI-25573) Ambari Metrics save as JSON/CSV use metricName instead of default name.

2020-11-02 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-25573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17224575#comment-17224575
 ] 

Dmytro Grinenko commented on AMBARI-25573:
--

The commit causing issues with tests, reverting...

 

PhantomJS 2.1.1 (Linux 0.0.0) Ambari Web Unit tests 
test/mixins/common/widgets/export_metrics_mixin_test App.ExportMetricsMixin 
#exportGraphDataSuccessCallback export to CSV "before each" hook for 
"downloadTextFile was called needed number of times" FAILEDPhantomJS 2.1.1 
(Linux 0.0.0) Ambari Web Unit tests 
test/mixins/common/widgets/export_metrics_mixin_test App.ExportMetricsMixin 
#exportGraphDataSuccessCallback export to CSV "before each" hook for 
"downloadTextFile was called needed number of times" FAILED undefined is not an 
object (evaluating 'this.get('targetView').title.replace') 
getCustomFileName@app/mixins/common/widgets/export_metrics_mixin.js:9:2097 
exportGraphDataSuccessCallback@app/mixins/common/widgets/export_metrics_mixin.js:9:3097
 test/mixins/common/widgets/export_metrics_mixin_test.js:209:45 
callFn@node_modules/mocha/mocha.js:4471:25 
run@node_modules/mocha/mocha.js:4464:13 
next@node_modules/mocha/mocha.js:4810:13 node_modules/mocha/mocha.js:4832:9 
timeslice@node_modules/mocha/mocha.js:75:27PhantomJS 2.1.1 (Linux 0.0.0): 
Executed 13188 of 22478 (1 FAILED) (skipped 33) (0 secs / 4.611 secs)PhantomJS 
2.1.1 (Linux 0.0.0) Ambari Web Unit tests 
test/mixins/common/widgets/export_metrics_mixin_test App.ExportMetricsMixin 
#exportGraphDataSuccessCallback export to JSON "before each" hook for 
"downloadTextFile was called needed number of times" FAILED undefined is not an 
object (evaluating 'this.get('targetView').title.replace') 
getCustomFileName@app/mixins/common/widgets/export_metrics_mixin.js:9:2097 
exportGraphDataSuccessCallback@app/mixins/common/widgets/export_metrics_mixin.js:9:3097
 test/mixins/common/widgets/export_metrics_mixin_test.js:209:45 
callFn@node_modules/mocha/mocha.js:4471:25 
run@node_modules/mocha/mocha.js:4464:13 
next@node_modules/mocha/mocha.js:4810:13 node_modules/mocha/mocha.js:4832:9 
timeslice@node_modules/mocha/mocha.js:75:27

> Ambari Metrics save as JSON/CSV use metricName instead of  default name.
> 
>
> Key: AMBARI-25573
> URL: https://issues.apache.org/jira/browse/AMBARI-25573
> Project: Ambari
>  Issue Type: Improvement
>Affects Versions: 2.7.5
>Reporter: akiyamaneko
>Priority: Major
>  Labels: pull-request-available, widget
> Fix For: 2.7.6
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> The name of the metrics data exported in Ambari-web is always data.json/csv, 
> and the exported file must be renamed to distinguish which metric the data 
> belongs to.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Reopened] (AMBARI-25573) Ambari Metrics save as JSON/CSV use metricName instead of default name.

2020-11-02 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko reopened AMBARI-25573:
--

> Ambari Metrics save as JSON/CSV use metricName instead of  default name.
> 
>
> Key: AMBARI-25573
> URL: https://issues.apache.org/jira/browse/AMBARI-25573
> Project: Ambari
>  Issue Type: Improvement
>Affects Versions: 2.7.5
>Reporter: akiyamaneko
>Priority: Major
>  Labels: pull-request-available, widget
> Fix For: 2.7.6
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> The name of the metrics data exported in Ambari-web is always data.json/csv, 
> and the exported file must be renamed to distinguish which metric the data 
> belongs to.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (AMBARI-25577) Understanding encryption capability

2020-10-29 Thread Dmytro Grinenko (Jira)


[ 
https://issues.apache.org/jira/browse/AMBARI-25577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17222782#comment-17222782
 ] 

Dmytro Grinenko commented on AMBARI-25577:
--

Please use the proper mail group mentioned here 
[https://ambari.apache.org/mail-lists.html] for questions. The Jira is not 
designed for this purpose, thanks

> Understanding encryption capability
> ---
>
> Key: AMBARI-25577
> URL: https://issues.apache.org/jira/browse/AMBARI-25577
> Project: Ambari
>  Issue Type: Documentation
>Reporter: Gregory William
>Priority: Minor
>
> Can someone please clarify whether Ambari is designed to use encryption, and 
> if it is, for what purposes?  Non-programmer here.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25577) Understanding encryption capability

2020-10-29 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25577.
--
Resolution: Information Provided

> Understanding encryption capability
> ---
>
> Key: AMBARI-25577
> URL: https://issues.apache.org/jira/browse/AMBARI-25577
> Project: Ambari
>  Issue Type: Documentation
>Reporter: Gregory William
>Priority: Minor
>
> Can someone please clarify whether Ambari is designed to use encryption, and 
> if it is, for what purposes?  Non-programmer here.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25398) Textareas in configuration page can be resized beyond its container border limit

2020-10-05 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25398:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed, check passed on [new 
CI|https://ci-hadoop.apache.org/job/Ambari/job/Ambari-PreCommit-GitHub-PR/job/PR-3105/10/display/redirect]

> Textareas in configuration page can be resized beyond its container border 
> limit
> 
>
> Key: AMBARI-25398
> URL: https://issues.apache.org/jira/browse/AMBARI-25398
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, ambari-web
>Affects Versions: 2.5.2, 2.7.2, 2.7.4
>Reporter: Yao Zhang
>Assignee: Dmytro Grinenko
>Priority: Trivial
>  Labels: pull-request-available
> Attachments: Annotation 2019-10-22 102253.png, Annotation 2019-10-22 
> 102349.png
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> The resizable textareas located in service configuration page (even in 
> installization wizard) can be resized to a improper size, with pictures shown 
> in the attachments. !Annotation 2019-10-22 102253.png!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25398) Textareas in configuration page can be resized beyond its container border limit

2020-10-05 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25398:
-
Status: Patch Available  (was: In Progress)

> Textareas in configuration page can be resized beyond its container border 
> limit
> 
>
> Key: AMBARI-25398
> URL: https://issues.apache.org/jira/browse/AMBARI-25398
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, ambari-web
>Affects Versions: 2.5.2, 2.7.2, 2.7.4
>Reporter: Yao Zhang
>Assignee: Dmytro Grinenko
>Priority: Trivial
>  Labels: pull-request-available
> Attachments: Annotation 2019-10-22 102253.png, Annotation 2019-10-22 
> 102349.png
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> The resizable textareas located in service configuration page (even in 
> installization wizard) can be resized to a improper size, with pictures shown 
> in the attachments. !Annotation 2019-10-22 102253.png!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (AMBARI-25398) Textareas in configuration page can be resized beyond its container border limit

2020-10-05 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko reassigned AMBARI-25398:


Assignee: Dmytro Grinenko

> Textareas in configuration page can be resized beyond its container border 
> limit
> 
>
> Key: AMBARI-25398
> URL: https://issues.apache.org/jira/browse/AMBARI-25398
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server, ambari-web
>Affects Versions: 2.5.2, 2.7.2, 2.7.4
>Reporter: Yao Zhang
>Assignee: Dmytro Grinenko
>Priority: Trivial
>  Labels: pull-request-available
> Attachments: Annotation 2019-10-22 102253.png, Annotation 2019-10-22 
> 102349.png
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> The resizable textareas located in service configuration page (even in 
> installization wizard) can be resized to a improper size, with pictures shown 
> in the attachments. !Annotation 2019-10-22 102253.png!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25561) Python Test for zeppelin failing

2020-10-05 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25561:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Python Test for zeppelin failing 
> -
>
> Key: AMBARI-25561
> URL: https://issues.apache.org/jira/browse/AMBARI-25561
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-server
>Affects Versions: trunk
>Reporter: Dmytro Grinenko
>Assignee: Szilard Antal
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {code:java}
> FAIL: test_start_secured (test_zeppelin_070.TestZeppelin070)
> --
> Traceback (most recent call last):
>   File "/opt/ambari/ambari-common/src/test/python/mock/mock.py", line 1199, 
> in patched
> return func(*args, **keywargs)
>   File 
> "/opt/ambari/ambari-server/src/test/python/stacks/2.6/ZEPPELIN/test_zeppelin_070.py",
>  line 240, in test_start_secured
> dfs_type='',
>   File 
> "/opt/ambari/ambari-server/src/test/python/stacks/utils/RMFTestCase.py", line 
> 345, in assertResourceCalled
> self.assertEquals(kwargs, resource.arguments)
> AssertionError: {'security_enabled': False, 'hadoop_conf_dir': 
> '/usr/hdp/2.5.0.0-1235/hadoop/con [truncated]... != {'security_enabled': 
> False, 'hadoop_bin_dir': '/usr/hdp/current/hadoop-client/bi [truncated]...
>   {'action': ['create_on_execute'],
>'default_fs': u'hdfs://c6401.ambari.apache.org:8020',
>'dfs_type': '',
> -  'hadoop_bin_dir': '/usr/hdp/2.5.0.0-1235/hadoop/bin',
> ?  +  'hadoop_bin_dir': 
> '/usr/hdp/current/hadoop-client/bin',
> ?  ^^^   +++-  'hadoop_conf_dir': 
> '/usr/hdp/2.5.0.0-1235/hadoop/conf',
> ?   +  'hadoop_conf_dir': 
> '/usr/hdp/current/hadoop-client/conf',
> ?   ^^^   +++   
> 'hdfs_resource_ignore_file': 
> '/var/lib/ambari-agent/data/.hdfs_resource_ignore',
>'hdfs_site': {u'a': u'b'},
> -  'keytab': UnknownConfigurationMock(),
> ?+  'keytab': UnknownConfiguration(),
>'kinit_path_local': '/usr/bin/kinit',
> -  'owner': 'zeppelin',
> +  'owner': u'zeppelin',
> ?   +-  'principal_name': UnknownConfigurationMock(),
> ?+  'principal_name': 
> UnknownConfiguration(),
>'recursive_chmod': True,
>'recursive_chown': True,
>'security_enabled': False,
>'type': 'directory',
> -  'user': 'hdfs'}
> +  'user': u'hdfs'}
> ?  +
>  {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25562) Nightly test is failing due to Ambari Metrics Host Aggregator

2020-10-05 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25562:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Nightly test is failing due to Ambari Metrics Host Aggregator
> -
>
> Key: AMBARI-25562
> URL: https://issues.apache.org/jira/browse/AMBARI-25562
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.7.6
>Reporter: Dmytro Grinenko
>Assignee: Szilard Antal
>Priority: Critical
> Fix For: 2.7.6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> {code:java}
> Results :Tests in error: 
>   
> AggregatorWebServiceTest.:45->JerseyTest.:217->JerseyTest.getContainer:335
>  » ArrayIndexOutOfBounds
>   
> AggregatorWebServiceTest.:45->JerseyTest.:217->JerseyTest.getContainer:335
>  » ArrayIndexOutOfBounds
>   
> AggregatorWebServiceTest.:45->JerseyTest.:217->JerseyTest.getContainer:335
>  » ArrayIndexOutOfBoundsTests run: 18, Failures: 0, Errors: 3, Skipped: 
> 0[INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] ambari-utility 1.0.0.0-SNAPSHOT  SUCCESS [ 10.591 
> s]
> [INFO] ambari-metrics 2.7.5.0.0 ... SUCCESS [  0.525 
> s]
> [INFO] Ambari Metrics Common 2.7.5.0.0  SUCCESS [ 57.949 
> s]
> [INFO] Ambari Metrics Hadoop Sink 2.7.5.0.0 ... SUCCESS [ 18.953 
> s]
> [INFO] Ambari Metrics Flume Sink 2.7.5.0.0  SUCCESS [ 14.128 
> s]
> [INFO] Ambari Metrics Kafka Sink 2.7.5.0.0  SUCCESS [ 11.566 
> s]
> [INFO] Ambari Metrics Storm Sink 2.7.5.0.0  SUCCESS [  7.246 
> s]
> [INFO] Ambari Metrics Storm Sink (Legacy) 2.7.5.0.0 ... SUCCESS [  6.247 
> s]
> [INFO] Ambari Metrics Collector 2.7.5.0.0 . SUCCESS [05:12 
> min]
> [INFO] Ambari Metrics Monitor 2.7.5.0.0 ... SUCCESS [  2.775 
> s]
> [INFO] Ambari Metrics Grafana 2.7.5.0.0 ... SUCCESS [  4.479 
> s]
> [INFO] Ambari Metrics Host Aggregator 2.7.5.0.0 ... FAILURE [  5.123 
> s]
> [INFO] Ambari Metrics Assembly 2.7.5.0.0 .. SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  07:32 min
> [INFO] Finished at: 2020-09-28T23:07:17Z
> [INFO] 
>  
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25523) Ambari UI keeps loading at step3 while adding the new namespace for HDFS for the second time

2020-09-30 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25523:
-
Summary: Ambari UI keeps loading at step3 while adding the new namespace 
for HDFS for the second time  (was: AMBARI UI KEEPS LOADING AT STEP3 WHILE 
ADDING THE NEW NAMESPACE FOR HDFS For the Second Time)

> Ambari UI keeps loading at step3 while adding the new namespace for HDFS for 
> the second time
> 
>
> Key: AMBARI-25523
> URL: https://issues.apache.org/jira/browse/AMBARI-25523
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.7.5
>Reporter: Akhil Naik
>Assignee: Szabolcs Beki
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Problem Statement : I am Trying to add namespace to HDFS via Ambari, my HDFS 
> already have two namespaces : namespace1,namespace2 . when i am trying to add 
> the third one say : namespace3, it fails with below script error at Step3:
> {code:java}
> app.js:5310 Uncaught TypeError: Cannot read property 'split' of undefined
> at Class.prepareDependencies (app.js:5310)
> at Class.tweakServiceConfigs (app.js:5337)
> at Class.onLoad (app.js:5293)
> at invokeAction (vendor.js:15179)
> at iterateSet (vendor.js:15161)
> at Object.sendEvent (vendor.js:15278)
> at notifyObservers (vendor.js:13870)
> at Object.Ember.notifyObservers (vendor.js:13985)
> at Object.propertyDidChange (vendor.js:14618)
> at set (vendor.js:13424)
> {code}
> Analysis : Upon analysing the code : 
> https://github.com/apache/ambari/blob/release-2.7.5/ambari-web/app/controllers/main/admin/federation/step3_controller.js#L110
> It looks we are blindly taking 0th nameService as the one that have namenode1 
> and namenode2 and then assiging the namenode1 and namenode2 :
> {code:java}
> var nameServices = 
> App.HDFSService.find().objectAt(0).get('masterComponentGroups').mapProperty('name');
> ret.nameServicesList = nameServices.join(',');
> ret.nameservice1 = nameServices[0];
> ret.newNameservice = this.get('content.nameServiceId');
> ret.namenode1 = hdfsSiteConfigs['dfs.namenode.rpc-address.' + 
> ret.nameservice1 + '.nn1'].split(':')[0];
> ret.namenode2 = hdfsSiteConfigs['dfs.namenode.rpc-address.' + 
> ret.nameservice1 + '.nn2'].split(':')[0];
> {code}
> The abouve logic is wrong, when you try to fetch `nameServices` as abouve the 
> order is not neccessarly the way it was created
> This logic need to rewramped.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (AMBARI-25542) Could not resolve dependencies for project org.apache.ambari:ambari-metrics-storm-sink-legacy:jar:2.7.5.0.0: Failure to find org.apache.storm:storm-core:jar:0.10.0.2.3

2020-09-29 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko reassigned AMBARI-25542:


Assignee: Dmytro Grinenko

> Could not resolve dependencies for project 
> org.apache.ambari:ambari-metrics-storm-sink-legacy:jar:2.7.5.0.0: Failure to 
> find org.apache.storm:storm-core:jar:0.10.0.2.3.0.0-2557 in 
> https://repo.maven.apache.org/maven2 was cached in the local repository
> ---
>
> Key: AMBARI-25542
> URL: https://issues.apache.org/jira/browse/AMBARI-25542
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: 2.7.5
> Environment: Ubuntu
>Reporter: Miftahul Huda
>Assignee: Dmytro Grinenko
>Priority: Blocker
> Attachments: Screenshot from 2020-08-07 09-23-30.png
>
>
> Attempting to build Ambari with this command:
> {{mvn -B clean install jdeb:jdeb -DnewVersion=}}{{2.7}}{{.}}{{3.0}}{{.}}{{0}} 
> {{-DbuildNumber=4295bb16c439cbc8fb0e7362f19768dde1477868 -DskipTests 
> -Dpython.ver=}}{{"python >= 2.6"}}
> Throws Command execution failed:
> !Screenshot from 2020-08-07 09-23-30.png!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25546) The maximum parameter on the heapmap page still supports negative numbers And NaN after parsing

2020-09-29 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25546:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> The maximum parameter on the heapmap page still supports negative numbers And 
> NaN after parsing
> ---
>
> Key: AMBARI-25546
> URL: https://issues.apache.org/jira/browse/AMBARI-25546
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.7.4
>Reporter: echohlne
>Assignee: Dmytro Grinenko
>Priority: Minor
> Fix For: 2.7.6
>
> Attachments: heatmap--metrics-NaN-fixed-screentshot.png, 
> heatmap--metrics-NaN-screentshot.png, 
> heatmap-metrics-negative-fixed-screenshot.png, 
> heatmap-metrics-negative-screentshot.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We like this open source software very much, but we found a little problem in 
> use.
> the maximum parameter on the heapmap page still supports negative numbers and 
> NaN after JS parsing which is not very kindly.
> examples has been shown in the attachment.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25546) The maximum parameter on the heapmap page still supports negative numbers And NaN after parsing

2020-09-29 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25546:
-
Assignee: Dmytro Grinenko
  Status: Patch Available  (was: Open)

> The maximum parameter on the heapmap page still supports negative numbers And 
> NaN after parsing
> ---
>
> Key: AMBARI-25546
> URL: https://issues.apache.org/jira/browse/AMBARI-25546
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-web
>Affects Versions: 2.7.4
>Reporter: echohlne
>Assignee: Dmytro Grinenko
>Priority: Minor
> Fix For: 2.7.6
>
> Attachments: heatmap--metrics-NaN-fixed-screentshot.png, 
> heatmap--metrics-NaN-screentshot.png, 
> heatmap-metrics-negative-fixed-screenshot.png, 
> heatmap-metrics-negative-screentshot.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We like this open source software very much, but we found a little problem in 
> use.
> the maximum parameter on the heapmap page still supports negative numbers and 
> NaN after JS parsing which is not very kindly.
> examples has been shown in the attachment.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25545) fix downloaded zip-file name shows empty in the fileview page.

2020-09-29 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25545.
--
Resolution: Fixed

> fix downloaded zip-file name shows empty in the fileview page.
> --
>
> Key: AMBARI-25545
> URL: https://issues.apache.org/jira/browse/AMBARI-25545
> Project: Ambari
>  Issue Type: Bug
>  Components: contrib
>Affects Versions: 2.7.4
> Environment: ambari 2.7.4
>Reporter: echohlne
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
> Attachments: question-fixed-screenshot.png, question-screenshot.png
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Steps to Reproduce:
>  # create a directory contains non-ascii characters such as create a Chinese 
> directory or a Japanese directory.
>  # Select a directory just created in step 1, then click download button, and 
> you can see that the name of the generated zip file is incorrect.
>  
> The problem screenshot is shown in the attachment.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (AMBARI-25545) fix downloaded zip-file name shows empty in the fileview page.

2020-09-29 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko reassigned AMBARI-25545:


Assignee: Dmytro Grinenko

> fix downloaded zip-file name shows empty in the fileview page.
> --
>
> Key: AMBARI-25545
> URL: https://issues.apache.org/jira/browse/AMBARI-25545
> Project: Ambari
>  Issue Type: Bug
>  Components: contrib
>Affects Versions: 2.7.4
> Environment: ambari 2.7.4
>Reporter: echohlne
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
> Attachments: question-fixed-screenshot.png, question-screenshot.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Steps to Reproduce:
>  # create a directory contains non-ascii characters such as create a Chinese 
> directory or a Japanese directory.
>  # Select a directory just created in step 1, then click download button, and 
> you can see that the name of the generated zip file is incorrect.
>  
> The problem screenshot is shown in the attachment.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (AMBARI-25562) Nightly test is failing due to Ambari Metrics Host Aggregator

2020-09-28 Thread Dmytro Grinenko (Jira)
Dmytro Grinenko created AMBARI-25562:


 Summary: Nightly test is failing due to Ambari Metrics Host 
Aggregator
 Key: AMBARI-25562
 URL: https://issues.apache.org/jira/browse/AMBARI-25562
 Project: Ambari
  Issue Type: Bug
  Components: ambari-metrics
Affects Versions: 2.7.6
Reporter: Dmytro Grinenko
 Fix For: 2.7.6


{code:java}
Results :Tests in error: 
  
AggregatorWebServiceTest.:45->JerseyTest.:217->JerseyTest.getContainer:335
 » ArrayIndexOutOfBounds
  
AggregatorWebServiceTest.:45->JerseyTest.:217->JerseyTest.getContainer:335
 » ArrayIndexOutOfBounds
  
AggregatorWebServiceTest.:45->JerseyTest.:217->JerseyTest.getContainer:335
 » ArrayIndexOutOfBoundsTests run: 18, Failures: 0, Errors: 3, Skipped: 0[INFO] 

[INFO] Reactor Summary:
[INFO] 
[INFO] ambari-utility 1.0.0.0-SNAPSHOT  SUCCESS [ 10.591 s]
[INFO] ambari-metrics 2.7.5.0.0 ... SUCCESS [  0.525 s]
[INFO] Ambari Metrics Common 2.7.5.0.0  SUCCESS [ 57.949 s]
[INFO] Ambari Metrics Hadoop Sink 2.7.5.0.0 ... SUCCESS [ 18.953 s]
[INFO] Ambari Metrics Flume Sink 2.7.5.0.0  SUCCESS [ 14.128 s]
[INFO] Ambari Metrics Kafka Sink 2.7.5.0.0  SUCCESS [ 11.566 s]
[INFO] Ambari Metrics Storm Sink 2.7.5.0.0  SUCCESS [  7.246 s]
[INFO] Ambari Metrics Storm Sink (Legacy) 2.7.5.0.0 ... SUCCESS [  6.247 s]
[INFO] Ambari Metrics Collector 2.7.5.0.0 . SUCCESS [05:12 min]
[INFO] Ambari Metrics Monitor 2.7.5.0.0 ... SUCCESS [  2.775 s]
[INFO] Ambari Metrics Grafana 2.7.5.0.0 ... SUCCESS [  4.479 s]
[INFO] Ambari Metrics Host Aggregator 2.7.5.0.0 ... FAILURE [  5.123 s]
[INFO] Ambari Metrics Assembly 2.7.5.0.0 .. SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  07:32 min
[INFO] Finished at: 2020-09-28T23:07:17Z
[INFO]  
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (AMBARI-25560) UT failing due to tar download error

2020-09-28 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko updated AMBARI-25560:
-
Fix Version/s: (was: trunk)
   2.7.6

> UT failing due to tar download error
> 
>
> Key: AMBARI-25560
> URL: https://issues.apache.org/jira/browse/AMBARI-25560
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: trunk
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> {code:java}
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 03:36 min
> [INFO] Finished at: 2020-09-28T05:49:54Z
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.7:run (default) on project 
> ambari-metrics-timelineservice: An Ant BuildException has occured: Can't get 
> https://s3.amazonaws.com/dev.hortonworks.com/HDP/centos7/3.x/BUILDS/3.1.4.1-1/tars/hbase/hbase-2.0.2.3.1.4.1-1-bin.tar.gz
>  to 
> /opt/ambari/ambari-metrics/ambari-metrics-timelineservice/target/embedded/hbase.tar.gz
> [ERROR] around Ant part ... src="https://s3.amazonaws.com/dev.hortonworks.com/HDP/centos7/3.x/BUILDS/3.1.4.1-1/tars/hbase/hbase-2.0.2.3.1.4.1-1-bin.tar.gz";
>  
> dest="/opt/ambari/ambari-metrics/ambari-metrics-timelineservice/target/embedded/hbase.tar.gz"/>...
>  @ 5:251 in 
> /opt/ambari/ambari-metrics/ambari-metrics-timelineservice/target/antrun/build-Download
>  HBase.xml {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (AMBARI-25560) UT failing due to tar download error

2020-09-28 Thread Dmytro Grinenko (Jira)


 [ 
https://issues.apache.org/jira/browse/AMBARI-25560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmytro Grinenko resolved AMBARI-25560.
--
Resolution: Fixed

> UT failing due to tar download error
> 
>
> Key: AMBARI-25560
> URL: https://issues.apache.org/jira/browse/AMBARI-25560
> Project: Ambari
>  Issue Type: Bug
>  Components: ambari-metrics
>Affects Versions: trunk
>Reporter: Dmytro Grinenko
>Assignee: Dmytro Grinenko
>Priority: Major
> Fix For: 2.7.6
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> {code:java}
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 03:36 min
> [INFO] Finished at: 2020-09-28T05:49:54Z
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.7:run (default) on project 
> ambari-metrics-timelineservice: An Ant BuildException has occured: Can't get 
> https://s3.amazonaws.com/dev.hortonworks.com/HDP/centos7/3.x/BUILDS/3.1.4.1-1/tars/hbase/hbase-2.0.2.3.1.4.1-1-bin.tar.gz
>  to 
> /opt/ambari/ambari-metrics/ambari-metrics-timelineservice/target/embedded/hbase.tar.gz
> [ERROR] around Ant part ... src="https://s3.amazonaws.com/dev.hortonworks.com/HDP/centos7/3.x/BUILDS/3.1.4.1-1/tars/hbase/hbase-2.0.2.3.1.4.1-1-bin.tar.gz";
>  
> dest="/opt/ambari/ambari-metrics/ambari-metrics-timelineservice/target/embedded/hbase.tar.gz"/>...
>  @ 5:251 in 
> /opt/ambari/ambari-metrics/ambari-metrics-timelineservice/target/antrun/build-Download
>  HBase.xml {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


  1   2   3   4   5   6   7   8   9   10   >