Bug 1693362

Summary: [RFE] How to tell if RedHat domain is out of sync after upgrade without UI
Product: Red Hat CloudForms Management Engine Reporter: Ryan Spagnola <rspagnol>
Component: ApplianceAssignee: drew uhlmann <duhlmann>
Status: CLOSED ERRATA QA Contact: Ganesh Hubale <ghubale>
Severity: low Docs Contact: Red Hat CloudForms Documentation <cloudforms-docs>
Priority: low    
Version: 5.10.4CC: abellott, dmetzger, duhlmann, gtanzill, jrafanie, lavenel, mshriver, obarenbo, simaishi, yrudman
Target Milestone: GA   
Target Release: 5.11.0   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: 5.11.0.5 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-12-12 13:36:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Comment 5 drew uhlmann 2019-05-08 18:22:05 UTC
This functionality exists without the need to turn on the UI worker role already. 


The UI is running this:

if version != available_version
  _("%{name} domain: Current version - %{version}, Available version - %{available_version}") %
  {:name => domain.name, :version => version, :available_version => available_version}
end

These methods can be directly run in console:

=> MiqAeDomain.find_by(:name => "ManageIQ").version
"gaprindashvili-7"
=> "gaprindashvili-7"
irb(main):017:0> MiqAeDomain.find_by(:name => "ManageIQ").available_version
"gaprindashvili-7"
=> "gaprindashvili-7"

I'm curious if that comparison is enough for the purposes of this ticket.

Comment 7 drew uhlmann 2019-05-13 11:41:44 UTC
Absolutely, Ryan. I'm currently working out where the best place for that logging is since we have a variety of plausible options available to us.

Comment 8 Loic Avenel 2019-05-13 12:41:35 UTC
(In reply to drew uhlmann from comment #7)
> Absolutely, Ryan. I'm currently working out where the best place for that
> logging is since we have a variety of plausible options available to us.

Log is a good place but we have to make sure with log rotation it still available.. As an example if you do it as Emvserverd starting it will be only once and few weeks later it will be not available

Comment 9 drew uhlmann 2019-05-13 12:43:28 UTC
I don't understand why the log rotation matters. The only time this information should be at all relevant is when we do updates of the existing system. I don't understand why we would care about this information from months ago. 

I think that the ideal implementation of this is that the plugins should have a health check, so we could conceivably say something like, loop over all the plugins and if they have a health check method implemented, run it.
But that still doesn't address the question of how often the check for that should run, or where it should be stored.

Comment 10 Joe Rafaniello 2019-05-14 15:55:44 UTC
If log rotation is a concern, I think we could do this check and log message as part of the last_startup.txt that's generated when the server starts up.  As long as the version is still mismatched, we'd continually log the same thing and we wouldn't lose it.

https://github.com/ManageIQ/manageiq/blob/8d219521d39198f7dab21492212b9fdf2a2e2263/app/models/miq_server.rb#L236

Comment 11 Loic Avenel 2019-05-14 15:59:20 UTC
(In reply to Joe Rafaniello from comment #10)
> If log rotation is a concern, I think we could do this check and log message
> as part of the last_startup.txt that's generated when the server starts up. 
> As long as the version is still mismatched, we'd continually log the same
> thing and we wouldn't lose it.
> 
> https://github.com/ManageIQ/manageiq/blob/
> 8d219521d39198f7dab21492212b9fdf2a2e2263/app/models/miq_server.rb#L236

Excellent idea

Comment 12 drew uhlmann 2019-05-14 16:17:51 UTC
https://github.com/ManageIQ/manageiq/pull/18756

Comment 14 drew uhlmann 2019-07-08 13:58:00 UTC
Hey Ganesh, yeah, those steps aren't going to work to verify this. 

For verification purposes, you really would like to have a system with a different RedHat domain on disk version versus the version in the db. So you'd like to grep the logs for this string: "domain version on disk differs from db version" after doing an upgrade to an appliance, when the version discrepancy exists.

Comment 17 errata-xmlrpc 2019-12-12 13:36:09 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:4199