*** This bug has been marked as a duplicate of bug 1188161 ***

This is not a duplicate of any Admin portal issue (BZ1188161). And as the BZ which supposed to be "parent" of this one as duplicate was closed, I'm reopening this one and delinking as duplicate.

This bug is trivial to fix as a downstream-only patch. Do we want that? Anything else will take considerably more time.

BTW, even that is not trivial, if we want to make something that will automatically link to the correct version, e.g.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/chap-Backups.html

for 3.5, and for 4.0:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/4.0/html/Administration_Guide/chap-Backups.html

(In reply to Yedidyah Bar David from comment #3)
> This bug is trivial to fix as a downstream-only patch. Do we want that?
> Anything else will take considerably more time.

I would prefer avoid to use downstream only patches within engine-backup code.
Can we add a conf file created by the spec file with an env pointing to the right URL?

If the file doesn't exist, point to oVirt documentation.
If the file exists, use the URL defined there.
Having it created by the spec file make it more simple to point to different urls for different releases.

Postponing to 3.6.3.

Me too would not want downstream-only patches in engine-backup, but I also think we should try over time to minimize the downstream-only patch for the spec if possible.

Perhaps add it somehow to rhevm-branding-rhev ?

(In reply to Yedidyah Bar David from comment #7)
> Me too would not want downstream-only patches in engine-backup, but I also
> think we should try over time to minimize the downstream-only patch for the
> spec if possible.
> 
> Perhaps add it somehow to rhevm-branding-rhev ?

May make sense. can you check if it fits there?

I now looked at it some more, and am thinking about adding a directory, e.g. [1] with a link to it in [2], and have engine-backup do something like:

for f in [2]/*/engine-backup/*.sh; do
    [ -r "${f}" ] && . "${f}"
done

Alexander: What do you think? In particular:

1. Is it too intrusive to be done inside [1] [2]?

2. If so, is it too intrusive to be done in this package, but outside of these directories?

[1] /usr/share/ovirt-engine/branding/rhev-2.brand/engine-backup
[2] /etc/ovirt-engine/branding/

A few notes.

1. The 'standard' way of having externalized URLs (or resources) is using the external_resources.properties file in the branding package. We use this for several different external URLs already. If it is easy for you guys to read a properties file and get a key out of that, that would probably be the easiest way to go.
2. If we point to the installed documentation, what happens when the documentation is NOT installed. Either a problem during install or the user uninstalled it to save disk space? Although it looks like we are not actually linking there, just giving a pointer there.
3. If 1 is not possible, its fairly trivial to add a directory under your [1] for engine-backup with whatever we want.

We currently imitate properties files reading in bash with some python code that uses configparser. I think that will be good enough also for this case.

How do I achieve something like comment 4? Have something replaced with the "major.minor" version? Thanks.

Here is what the Java code when determining the value to display.

It reads external_resources.properties from:

XX.brand where XX has the for NN-YYYY (NN = number like 00, YYYY is a string).
It sorts on NN low to high.
Then it takes the external_properties from the highest NN and pick the value from there.

This is to allow a higher valued branding package to override a lower one. For instance lets say that

obrand.common.enginebackup.help_url=http://www.ovirt.org/Ovirt-engine-backup

In 00-ovirt.brand external_resources.properties, then we can have

obrand.common.enginebackup.help_url=https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/chap-Backups.html

In 02-rhev.brand external_resources.properties.

Because 02 is higher than 00, the displayed version will be the one from 02-rhev.brand.

Since you DON'T have to replace a particular value in a higher number branding package, you will have to read them in order, and replace the value with the latest as you read them. You can't just read the external_resources.properties from the highest number branding package as it might not override the value from a lower one.

Ok, this is helpful, but is there a "standard" way to replace "3.5" in the link above with the current version? Or I have to do that with custom code?

Because the branding package is version specific, we don't try to replace 3.5 or something code. Its just part of the URL. So if we release 4.0 we will release a corresponding branding package with new URLs. So your code won't actually care about the 3.5 or 4.0 as that will change in the branding package.

Alexander merged to rhevm-branding-rhev a link to 3.5 docs.

There are still no 3.6 docs.

In 3.6 beta docs, the link name was changed - from chap-Backups.html [1] in 3.5 to chap-Backups_and_Migration.html [2] in 3.6-beta.

Julie:

Will the final link be [3] (currently 404)?
When will it go live?

Thanks.

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/chap-Backups.html
[2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6-Beta/html/Administration_Guide/chap-Backups_and_Migration.html
[3] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Administration_Guide/chap-Backups_and_Migration.html

(In reply to Yedidyah Bar David from comment #15)
> Alexander merged to rhevm-branding-rhev a link to 3.5 docs.
> 
> There are still no 3.6 docs.
> 
> In 3.6 beta docs, the link name was changed - from chap-Backups.html [1] in
> 3.5 to chap-Backups_and_Migration.html [2] in 3.6-beta.
> 
> Julie:
> 
> Will the final link be [3] (currently 404)?
> When will it go live?
> 
> Thanks.
> 
> [1]
> https://access.redhat.com/documentation/en-US/
> Red_Hat_Enterprise_Virtualization/3.5/html/Administration_Guide/chap-Backups.
> html
> [2]
> https://access.redhat.com/documentation/en-US/
> Red_Hat_Enterprise_Virtualization/3.6-Beta/html/Administration_Guide/chap-
> Backups_and_Migration.html
> [3]
> https://access.redhat.com/documentation/en-US/
> Red_Hat_Enterprise_Virtualization/3.6/html/Administration_Guide/chap-
> Backups_and_Migration.html
Hi Didi,
 Yes, that should be the URL for 3.6. We normally release it a few hours before the GA announcement day(currently 9 Mar?).

Cheers,
Julie

Very well. Pushed a patch to change the link.

QE: Note that the link will not work until very close to GA.

Tried with:
rhevm-3.6.3.1-0.1.el6.noarch

# engine-backup --help | sed -n '/Wiki/,$p' | head -n3
 Wiki

 See http://www.ovirt.org/Ovirt-engine-backup for more info.

I have verified the key and value are in the branding package. Maybe the order in which stuff is loaded is wrong?

Sorry, my mistake. Patch was pushed only to master.

Verified with:
rhevm-3.6.3.3-0.1.el6.noarch

# engine-backup --help | sed -n '/Documentation/,$p' | head -n4
 Documentation

 For more information, please see:
 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Administration_Guide/chap-Backups_and_Migration.html