Open bschonec opened 9 years ago
@bschonec Looks like the parameter was there for future implementation, but it never got actually used, so it would have no effect currently. What is/was your use case?
I have about 150 internal Zend servers that need updating. None of those servers have access to the Internet and hence cannot get out to the external Zend/YUM repository to get their updates.
However, I have mirrored the external repository with my Red Hat Satellite server and the internal Zend servers do have access to Satellite. Unfortuntely, when the ZendServerPuppet module runs, it installs the repository with "enabled = 1". (see manifests/repo/redhat.pp). In my case, the Zend servers then try to go out to repos.zend.com for their updates and they fail because of the lack of external Internet access.
If I can set "enabled = 0" -- or better yet, not install the repository at all -- then my Zend servers will use the internal Satellite repository that I have set up for them because the ZendServerPuppet supplied repository will be disabled.
@bschonec makes sense - ok thanks for the feedback. I'll have a fix submitted soon.
@mkherlakian any update? It's been over a year since I submitted this issue.
@mkherlakian any update? It's been over a year and a half since I submitted this issue.
@mkherlakian What have you done in the meantime? I personally make an exception in my firewall for repos.zend.com.
@ubellavance , Unfortunately, I don't have that option. My servers can't get out to the internet by design and policy. Since I have a Satellite server that they CAN reach, I need the ability to 'disable' the repositories from being created/enabled. That way, the severs will contact Satellite (internally) and get their updates.
@ubellavance I do the same. @bschonec I have someone looking into this right now. I believe that the issue wasn't updated, but there was some work done for that a few weeks back - https://github.com/zend-patterns/ZendServerPuppet/commit/045ac8b6e14ff49c66d7c5422fff79073374cc9f. We are testing to see if that was enough to get it working.
@bschonec, I've learnt that in most puppet modules, PRs are almost the only way to get things fixed/changed. The change you're requesting doesn't seem to be complicated at all. Would you rather be able to set the URL in this module or just make it enabled=0?
@mkherlakian the commit looks good. I think it's ready for testing.
@ubellavance enabled=0 I think would work. I have no problem if the /etc/yum.repos.d files get created (although to be honest I'd prefer they NOT get created). If it's easier to do 'enabled=0' I won't argue.
I have no need to set the URL since my servers default to Satellite to get all their updates.
@bschonec with the proposed fix, it shouldn't create the file at all.
I think that the option that would provide the most flexibility is to allow the user to set the repo - it would certainly be helpful for updates. It would also account for users wanting to download previews or betas on different URL repos which we do from time to time. Thoughts?
Well, I'm the beggar here so I can't be the chooser but for people with server that can access the Internet, I can see how they'd want the /etc/yum.repos.d files created. One could argue that if you wanted the repositories disabled you'd just remove the repository files but it might be more clear to the next administrator where updates were coming from if the repository files existed AND you could enable/disable the repositories with "enabled=1" "enabled=0". However for MY purposes I'd prefer not to have the repository files created at all because I mirror Zend's repository files locally on my Satellite server. I take the opinion of "don't give me information that doesn't add anything to the equation." ie: don't create the repo files only to disable the repository. That's a waste of my time. So again, in MY case, I have no need for modifying the repo files if I can just eliminate them. However, for 99% of people I think they're not going to have the luxury of a Satellite server sitting inside their firewall so they most definitely will want to manage the repo files.
@mkherlakian I think that it would be better to be able to set the repo as well as enable/disable it. I think almost all the work for enable/disable has been done, and according to what I see in the code, implementing the changes to be able to set a custom URL for the repo should be quite easy.
@bschonec One doesn't exclude the other. With the commit #14 , you'd have exactly what you want: no file in /etc/yum.repos.d/. Would you be able to do some testing?
@ubellavance yep. Give me a day or two.
@bschonec I think you'll be a happy camper soon!
@ubellavance @bschonec thanks guys! I'll wait for the PR and merge as soon as it comes in.
@mkherlakian What PR are you waiting for? Can @bschonec start testing commit #14?
Should be fixed in #61
@bschonec can we close this issue since #61 is merged?
Setting manage_reposo to false has no effect on the module's behavior to manage /etc/yum.repos.d. The /etc/yum.repos.d/zend.repo file always gets created and "enabled=1" is always set.