Bug 1335428 - Repo names formed incorrectly causing to skip repo addition
Summary: Repo names formed incorrectly causing to skip repo addition
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: gdeploy
Version: rhgs-3.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: RHGS 3.1.3
Assignee: Nandaja Varma
QA Contact: Jonathan Holloway
URL:
Whiteboard:
Depends On:
Blocks: Gluster-HC-1 1311817
TreeView+ depends on / blocked
 
Reported: 2016-05-12 08:39 UTC by Sahina Bose
Modified: 2016-07-04 01:12 UTC (History)
7 users (show)

Fixed In Version: gdeploy-2.0-16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-23 05:30:38 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:1250 0 normal SHIPPED_LIVE gdeploy update for Red Hat Gluster Storage 3.1 update 3 2016-06-23 09:11:59 UTC

Description Sahina Bose 2016-05-12 08:39:01 UTC
Description of problem:

When there are 2 repos configured for instance :
http://download.eng.tlv.redhat.com/rel-eng/repos/rhel-7.2-z-candidate/x86_64
http://download.eng.tlv.redhat.com/rel-eng/repos/rhevh-rhel-7.2-candidate/x86_64

- Both these repos are named as x86_64.repo - causing only 1 to be added

The logic of parsing the last token in repo url  as repo name is wrong

If I use yum-config-manager --add-repo the file is created as 
download.eng.tlv.redhat.com_rel-eng_repos_rhel-7.2-z-candidate_x86_64.repo

whereas with gdeploy repo names are latest.repo, x86_64.repo!



Version-Release number of selected component (if applicable):
2.0-11

How reproducible:
Always

Steps to Reproduce:
1. As in description


Actual results:


Expected results:


Additional info:

(item={'url': 'http://download.eng.tlv.redhat.com/rel-eng/repos/rhel-7.2-z-candidate/x86_64', 'name': 'x86_64'})
changed: [10.70.42.203] => (item={'url': 'http://download.eng.tlv.redhat.com/rel-eng/repos/rhel-7.2-z-candidate/x86_64', 'name': 'x86_64'})
changed: [10.70.42.203] => (item={'url': 'http://download.eng.tlv.redhat.com/rel-eng/repos/rhevh-rhel-7.2-candidate/x86_64', 'name': 'x86_64'})
changed: [10.70.42.219] => (item={'url': 'http://download.eng.tlv.redhat.com/rel-eng/repos/rhevh-rhel-7.2-candidate/x86_64', 'name': 'x86_64'}

Comment 2 Sahina Bose 2016-05-17 16:07:22 UTC
Tried this with gdeploy-2.0-14
[yum1]
action=install
gpgcheck=no
repos=http://rhsqe-repo.lab.eng.blr.redhat.com/brew/glusterfs-3.7-latest-el7rhgs/,http://jenkins.lab.eng.blr.redhat.com/hc/vdsm/latest/,http://jenkins.lab.eng.blr.redhat.com/hc/vdsm/4.17.28-0.1/,http://download.eng.tlv.redhat.com/rel-eng/repos/rhel-7.2-z-candidate/x86_64/
packages=vdsm,vdsm-gluster,ovirt-hosted-engine-setup,screen,gluster-nagios-addons,xauth
update=yes

But only 1 repo file created failing the deployment.

changed: [10.70.42.203] => (item={'url': 'http://rhsqe-repo.lab.eng.blr.redhat.com/brew/glusterfs-3.7-latest-el7rhgs/', 'name': '_20160517205803'})
changed: [10.70.42.203] => (item={'url': 'http://jenkins.lab.eng.blr.redhat.com/hc/vdsm/latest/', 'name': '_20160517205803'})
changed: [10.70.42.203] => (item={'url': 'http://jenkins.lab.eng.blr.redhat.com/hc/vdsm/4.17.28-0.1/', 'name': '_20160517205803'})
changed: [10.70.42.203] => (item={'url': 'http://download.eng.tlv.redhat.com/rel-eng/repos/rhel-7.2-z-candidate/x86_64/', 'name': '_20160517205803'})

Comment 3 Sachidananda Urs 2016-05-17 17:54:38 UTC
Now we will generate UUID for the repo names, so that we don't conflict and
step on other repos.

The following patch will fix the issue:

diff --git a/gdeployfeatures/yum/yum.py b/gdeployfeatures/yum/yum.py
index af6b5a4..ba5bb5e 100644
--- a/gdeployfeatures/yum/yum.py
+++ b/gdeployfeatures/yum/yum.py
@@ -4,8 +4,8 @@ Add functions corresponding to each of the actions in the json file.
 The function should be named as follows <feature name>_<action_name>
 """
 from gdeploylib import defaults, Helpers
-from datetime import datetime
-import os
+from uuid import uuid4
+from os.path import realpath, basename
 
 helpers = Helpers()
 
@@ -14,8 +14,8 @@ def yum_install(section_dict):
     repo = section_dict.get('repos')
     if repo:
         repo = helpers.listify(repo)
-        reponame = [os.path.basename(x) for x in repo]
-        reponame = [(str(x) + '_' + datetime.now().strftime('%Y%m%d%H%M%S'))
+        reponame = [basename(realpath(x)) for x in repo]
+        reponame = [(str(x) + '_' + uuid4().hex)
                 for x in reponame]
         data = []
         for url, name in zip(repo, reponame):

Comment 4 Sachidananda Urs 2016-05-17 18:31:39 UTC
Commit https://github.com/gluster-deploy/gdeploy/commit/df9d61e065efe849c9c3c15f16aadf3fe4ad6fc7 fixes the issue.

Comment 6 Sahina Bose 2016-05-18 05:31:26 UTC
If I rerun gdeploy on the nodes, it's going to create duplicate repo files?

Comment 7 Sahina Bose 2016-05-18 07:03:30 UTC
Moving back to assigned as duplicate file names are created on each re-run.

Comment 8 Sachidananda Urs 2016-05-18 07:25:17 UTC
Proposed fix is to keep the entire path for the repo name, with / replaced with _

+        reponame = [re.sub(r'http(s*):\/\/', '', x) for x in repo]
+        reponame = [x.replace('/', '_') for x in reponame]

With this change the repos will look like:

jenkins.lab.eng.blr.redhat.com_hc_vdsm_latest.repo
rhsqe-repo.lab.eng.blr.redhat.com_brew_glusterfs-3.7-latest-el7rhgs.repo

Comment 10 Sachidananda Urs 2016-05-19 03:01:17 UTC
Commit: https://github.com/gluster/gdeploy/commit/567f434f6d038fba9cd55560bf5155ecd2b4e1c2

Fixes the issue.

Comment 11 Sachidananda Urs 2016-05-24 05:36:21 UTC
Build was made on 19th missed moving to ON_QA. This fix is available as part of gdeploy-2.0-16

Comment 12 Jonathan Holloway 2016-06-04 00:30:12 UTC
Marking this BZ verified.

Repo files are now created with individual filenames as described in Comment 8 above, and subsequent runs of gdeploy with the same config no longer create duplicate repo files.

Comment 14 errata-xmlrpc 2016-06-23 05:30:38 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/RHEA-2016:1250


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