Bug 1693362 - [RFE] How to tell if RedHat domain is out of sync after upgrade without UI
Summary: [RFE] How to tell if RedHat domain is out of sync after upgrade without UI
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.10.4
Hardware: All
OS: All
low
low
Target Milestone: GA
: 5.11.0
Assignee: drew uhlmann
QA Contact: Ganesh Hubale
Red Hat CloudForms Documentation
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-27 16:14 UTC by Ryan Spagnola
Modified: 2019-12-12 13:36 UTC (History)
10 users (show)

Fixed In Version: 5.11.0.5
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-12 13:36:09 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:4199 0 None None None 2019-12-12 13:36:23 UTC

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


Note You need to log in before you can comment on or make changes to this bug.