'ServiceTemplateCatalog' => nil,
or change it to 'ServiceTemplateCatalog' => descendant_ids
but no changes takes place (parent tenant can still see child catalogs - if set to nil it should be tenant only)
@jrafanie It seems like docker version (lasker) doesn't read filterer.rb at all. I changed the 'ServiceTemplateCatalog' => nil, or change it to 'ServiceTemplateCatalog' => descendant_ids but no changes takes place (parent tenant can still see child catalogs - if set to nil it should be tenant only)
I ported my test to lasker and it still passes: service template (catalog item) owned by a group in a parent tenant can be seen by a user in a group in a subtenant. The opposite isn't true: a service template owned by a group in a subtenant cannot be seen by a user in a group in an ancestor tenant. This is how is should work. Can you give me guidance on how to see what you're seeing @kTipSSIoYv ? I'm not sure where you're seeing this behavior.
@Fryguy @jrafanie I have this code to display AWX Tower IDs
repo = $evm.vmdb(:ManageIQ_Providers_AnsibleTower_AutomationManager_ConfigurationScript).all.each do |repo|
dialog_hash[repo.id] = repo.name
end
I want to include ManageIQ_Providers_AnsibleTower_AutomationManager_ConfigurationWorkflow
along with ManageIQ_Providers_AnsibleTower_AutomationManager_ConfigurationScript
.. Is it possible?
@Fryguy I've figured out that part.. It appends to the existing hash when I try the following..
repo = $evm.vmdb(:ManageIQ_Providers_AnsibleTower_AutomationManager_ConfigurationScript).all.each do |repo|
dialog_hash[repo.id] = repo.name
end
repo = $evm.vmdb(:ManageIQ_Providers_AnsibleTower_AutomationManager_ConfigurationWorkflow).all.each do |repo|
dialog_hash[repo.id] = repo.name
end
Hello everyone! I'm trying to install fluentd on a machine that has manageiq installed but when attempting to install I'm getting a lot of rpm conflicts with manageiq-gemset. Has anyone had this issue or found a workaround that won't hurt either fluentd or manageiq?
fluentd version: td-agent-4.3.0-1.el8.x86_64
manageiq-gemset version: manageiq-gemset-13.1.0-1.el8.x86_64
The actual error message is below:
"Unknown Error occured: Transaction test error:
file /usr/lib/.build-id/3a/a6377e3b490d35f6b2e13af2a0a487992a4d7b from install of td-agent-4.3.0-1.el8.x86_64 conflicts with file from package manageiq-gemset-13.1.0-1.el8.x86_64
file /usr/lib/.build-id/6b/074ebdad7c55f515e55faf0c859d96ce823c74 from install of td-agent-4.3.0-1.el8.x86_64 conflicts with file from package manageiq-gemset-13.1.0-1.el8.x86_64
file /usr/lib/.build-id/7b/152f6fd3336942261a5c46bb46cf1355c8368f from install of td-agent-4.3.0-1.el8.x86_64 conflicts with file from package manageiq-gemset-13.1.0-1.el8.x86_64
file /usr/lib/.build-id/86/47df0ea0bafe7bd29ac2c12584acdb9addb147 from install of td-agent-4.3.0-1.el8.x86_64 conflicts with file from package manageiq-gemset-13.1.0-1.el8.x86_64"
rpm -qlvp td-agent-4.3.0-1.el8.x86_64 | grep a6377e3b490d35f6b2e13af2a0a487992a4d7b
rpm -qlvp manageiq-gemset-13.1.0-1.el8.x86_64 | grep a6377e3b490d35f6b2e13af2a0a487992a4d7b
Thank you! For each one it shows the different locations for the conflicting package (had to run manageiq-gemset ones without -p as it was already installed)
I'm sorry but maybe I'm missing something. With these conflicting files would it be safe to remove the manageiq one/force install the rpm as they're the same version of the gem files?
/usr/lib/.build-id/3a/a6377e3b490d35f6b2e13af2a0a487992a4d7b -> ../../../../opt/td-agent/lib/ruby/gems/2.7.0/gems/nokogiri-1.12.5-x86_64-linux/lib/nokogiri/2.6/nokogiri.so
/usr/lib/.build-id/3a/a6377e3b490d35f6b2e13af2a0a487992a4d7b -> ../../../../opt/manageiq/manageiq-gemset/gems/nokogiri-1.12.5-x86_64-linux/lib/nokogiri/2.6/nokogiri.so
Hello!
I have some VMs that have ManageIQ already initialized and we wanted to see if there was an easy way to un-init either by way of script or anything else that someone might know of. I was pointed to this erb file: base.ks.erb, but before we decide to attempt to create our own un-init script that goes in reverse of this I wanted to see if someone may have either seen or made something similar or if there is a util that can be used.
Thanks!
--key
you can just delete the /var/www/miq/vmdb/certs/v2_key
/var/lib/pgsql/*
and probably /var/www/miq/vmdb/config/database.yml
that will go a long way towards un-config of the internal database and region