Hi Jörg,

I would first of all try to get the compute profiles via hammer:

[root@node3 ~]# hammer compute-profile list
---|---------
ID | NAME
---|---------
1  | 1-Small
2  | 2-Medium
3  | 3-Large
---|---------

Then try to get more details over the CLI:

[root@node3 ~]# hammer compute-profile info --id 3
[root@node3 ~]# hammer compute-profile info --id 3
ID:                 3
Name:               3-Large
Created at:         2019/11/26 13:13:47
Updated at:         2019/11/26 13:13:47
Compute attributes:
 1) ID:               1
    Name:             4 CPUs and 16 GB memory
    Compute Resource: Xen1
    VM attributes:    {"vcpus_max"=>"4", "memory_min"=>"8489271296", "memory_max"=>"17179869184", "iso"=>"2844d010-a140-4319-81c2-59a25acd1e60", "start"=>"1", "target_sr"=>"8cbdc0ba-e536-01b0-f4c1-da54bda17df7", "builtin_template"=>"", "volumes_attributes"=>{"1574775028450"=>{"sr"=>"51cbbd45-eac9-13ff-9822-984052ddbf2a", "virtual_size_gb"=>"100"}}}

If that fails, you can still try to get something out of the database:

[root@node3 ~]# su - postgres
-bash-4.2$ psql
postgres=# \c foreman
foreman=# select * from compute_attributes;
 id | compute_profile_id | compute_resource_id |          name           |                                vm_attrs                                 |         created_at         |         updated_at
----+--------------------+---------------------+-------------------------+-------------------------------------------------------------------------+----------------------------+----------------------------
  1 |                  3 |                   1 | 4 CPUs and 16 GB memory | --- !ruby/hash:ActiveSupport::HashWithIndifferentAccess                +| 2019-11-26 13:30:38.960835 | 2019-11-26 13:30:38.960835
    |                    |                     |                         | vcpus_max: '4'                                                         +|                            |
    |                    |                     |                         | memory_min: '8489271296'                                               +|                            |
    |                    |                     |                         | memory_max: '17179869184'                                              +|                            |
    |                    |                     |                         | iso: 2844d010-a140-4319-81c2-59a25acd1e60                              +|                            |
    |                    |                     |                         | start: '1'                                                             +|                            |
    |                    |                     |                         | target_sr: 8cbdc0ba-e536-01b0-f4c1-da54bda17df7                        +|                            |
    |                    |                     |                         | builtin_template: ''                                                   +|                            |
    |                    |                     |                         | volumes_attributes: !ruby/hash:ActiveSupport::HashWithIndifferentAccess+|                            |
    |                    |                     |                         |   '1574775028450': !ruby/hash:ActiveSupport::HashWithIndifferentAccess +|                            |
    |                    |                     |                         |     sr: 51cbbd45-eac9-13ff-9822-984052ddbf2a                           +|                            |
    |                    |                     |                         |     virtual_size_gb: '100'                                             +|                            |
    |                    |                     |                         |                                                                         |                            |
(1 row)

You can also try to find something that is different with one of your compute resources and try to eliminate that on the database level.

You could also try to create a new Compute Ressource and afterwards change the association of the profiles on database level. You probably only need to change the 'compute_resource_id' of the profile.

Anyway, before changing anything on database level, make sure to create a backup => https://theforeman.org/manuals/1.23/index.html#5.5.1Backup

Hi Enrico,

using hammer (# hammer compute-profile list|grep ^[0-9]|cut -d\| -f1|xargs -iXX hammer compute-profile info --id XX) no profile fails.

Since we use hammer to deploy hosts, with the existing profiles Foreman works "as is".

But yet we cannot add new (working) profiles or edit the existing profiles from that single ressource.

Any clues what I can do?

When I choose a random compute profile, the error occurs only when selecting this one specific compute-ressource. If I choose any other ressource, no problem.

This looks like the problem is located inside the compute ressource.

Have you got any SQL-hints what to do to figure out what is wrong with this one compute-ressource?

Question: If I delete that Ressource, and create a new one with the same name, will the profiles still work?

Okay, you cannot delete a compute ressource without prior removing of all associated profiles :-(

Interesting:

/usr/share/foreman/app/models/concerns/fog_extensions/vsphere:

Original file fails on the specific ressource:

# cat folder.rb_ORIG
module FogExtensions
  module Vsphere
    module Folder
      extend ActiveSupport::Concern
      def to_label
        path.slice((path.index(datacenter) + datacenter.length + 1)..-1).gsub('/', ' / ')
      end
    end
  end
end

If I remove the ".gsub()"-appendix:

# cat folder.rb
module FogExtensions
  module Vsphere
    module Folder
      extend ActiveSupport::Concern
      def to_label
        path.slice((path.index(datacenter) + datacenter.length + 1)..-1)
      end
    end
  end
end

Problem is gone.

So why has this specific compute ressource a problem with method `gsub', while the others not?

I guess Foreman works in our case without that gsub-method, because we do not deploy VMs in subfolders inside die vSphere ressource-pool/cluster.

So I would take this code-modification as "workaround".