[
https://issues.apache.org/jira/browse/AMBARI-12125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Lysnichenko updated AMBARI-12125:
----------------------------------------
Attachment: AMBARI-12125.patch
> If agent is not restarted after upgrade, it reads new version file and
> registers as a new version
> -------------------------------------------------------------------------------------------------
>
> Key: AMBARI-12125
> URL: https://issues.apache.org/jira/browse/AMBARI-12125
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
> Reporter: Dmitry Lysnichenko
> Assignee: Dmitry Lysnichenko
> Fix For: 2.1.0
>
> Attachments: AMBARI-12125.patch
>
>
> I think now I understand how issue occurs.
> I had consideration for a while that traceback does not match lines in
> CustomServiceOrchestrator.py source. Now the picture is complete: line
> numbers match exactly CustomServiceOrchestrator.py as it appears in 2.0.maint
> branch.
> That means that agent on affected host was upgraded, but not restarted after
> package upgrade.
> The bug here is in workflow:
> - server is upgraded
> - agents on hosts are upgraded. Linux systems allow overwriting files in use
> (e.g. running binaries)
> - agent on all hosts but one are restarted
> - server is restarted
> - agent, that was not upgraded, registers on server. During registration, it
> provides version that appears at /var/lib/ambari-agent/data/version file. But
> agent version file is already upgraded! So *old* agent executable reads *new*
> version file, and successfully registers on server.
> That is an actual bug.
> The fix probably would be to substitute agent version directly into agent
> script, and not into separate files. Python would not re-import sources after
> upgrade.
> The same applies to the server upgrade.
> Another option is to check if agent is running from package upgrade scripts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
