Description of problem: publishing of puppet modules places the modules in a randomly generated dir. Library environment: [root@yyyy modulesezp4tE]# ls foreman_scap_client openscap [root@yyyy modulesezp4tE]# pwd /etc/puppet/environments/KT_Default_Organization_Library_puppet_foreman_scap_cv_3/modulesezp4tE Libary->prabhjeet environamnet: [root@yyyy modulesQvTiys]# ls foreman_scap_client openscap [root@yyyy modulesQvTiys]# pwd /etc/puppet/environments/KT_Default_Organization_Prabhjeet_puppet_foreman_scap_cv_3/modulesQvTiys NOTE: the random modules dir_Structure int he end. Version-Release number of selected component (if applicable): Beta-snap1-snap6 How reproducible: always Steps to Reproduce: 1. create a puppet repo and sync 2. publish the puppet repo 3. Note that the puppet_module gets generated in a randomly generated dir_structure. Actual results: randomly named directory. Expected results: puppet modules are deployed to /etc/puppet/environments/<environment>/module Additional info:
Version : Sat6.1-Beta-snap1-compose3
Can you provide an example of the directory name that you see? Is it something like? KT_Default_Organization_Library_OS_18 If so, it is based on logic which uses the following syntax: KT_[org label]_[lifecycle environment label]_[content view label]_[content view id] It is possible that the algorithm could change; however, it is not really random.
For example: /etc/puppet/environments/KT_Default_Organization_Library_puppet_foreman_scap_cv_3/modulesezp4tE /etc/puppet/environments/KT_Default_Organization_Prabhjeet_puppet_foreman_scap_cv_3/modulesQvTiys Please note the end of the dir_structure which is : modulesezp4tE or modulesQvTiys
puppet-foreman_scap_client will be shipped as an RPM file. I am not sure why would user want to create a puppet repo for puppet-foreman _scap_client. What is the use-case?
Moved to POST since the upstream pulp bug is now ON_QA and available.
Looking at puppet-foreman_scap_client I was under the impression that we need to go by the puppet-modules/puppet-classes approach. If we will be using it in RPM file format, can we get access to these RPMs. @simon Lukasik: I think this is because I have no idea about the OpenScap workflow, atleast some rough documentation regarding it would help. :)
Created attachment 992744 [details] required puppet class foreman_scap_client The use-case being the attached screenshot message from the UI while creating the OSCAP policy. I had picked the "puppet-foreman_scap_client" puppet-module from forge.puppetlabs and was trying to publish it. The message from the screen-shot made me feel we need to go the puppet-module/puppet-classes approach, but now really interested in knowing how to take it forward using the RPM approach and have puppet-classes visible. Some steps would help.
Update for comment 8: I see the package rubygem-foreman_scap_client-0.1.0-1.el6_6sat.noarch a) but not sure how do we get the puppet-classes from it. b) May be I will try to create a repo, sync and publish it and check if puppet-classes will populate. I think will take this discussion offline, here after.
Now puppet-classes get populated once the puppet-modules are synced, published and promted. VERIFIED with sat6.1 beta snap3
This bug is slated to be released with Satellite 6.1.
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/RHSA-2015:1592