Bug #2317
closedForeman starts creating VM's with the name foreman_########
Description
Once and awhile Foreman starts creating VM's on our RHEV instance with names like foreman_32546452 instead of using the FQDN name with dashes instead of dots, as it normally does.
I have not been able to track down what is causing this or what clears it, but after attempts of stopping and starting foreman, puppet, ovirt-engine and closing my browser and clearing the cache the desired behaviour will resume.
I'm not sure how I can debug this beyond providing /var/log/foreman/production.log the next time it happens.
Files
Updated by Anonymous over 11 years ago
- File wrongname.png wrongname.png added
I think what I am finding is that this happens when I have a browser session open, do some stuff, create/delete vm's (I'm using RHEV in my case) etc. and then restart the (httpd, using passenger) service, perhaps a few times. If I don't log out/clear my browser history this seems to occasionally happen. When it does happen, clearing my browser cache seems to get it functioning correctly again.
Updated by Ohad Levy over 11 years ago
this some how were hash attributes (the default vm hash) is merged with the requested details incorrectly (probably in the wrong direction).
Updated by Dominic Cleal over 11 years ago
- Category set to Compute resources - oVirt
- Target version set to 1.2.0
Updated by Joseph Magen over 11 years ago
- Status changed from Assigned to Need more information
Jason, I could not duplicate this issue. If the name is blank, then the default name is foreman_#### because of this method in compute_resource.rb
def vm_instance_defaults
{
'name' => "foreman_#{Time.now.to_i}",
}
end
When it's created, the default name is overridden
def new_vm(attr={})
vm = client.servers.new vm_instance_defaults.merge(attr)
I cannot reproduce when the name is blank and it's NOT caught by the validation errors.
Updated by Anonymous over 11 years ago
I have had a hard time reproducing it as well. I can make it happen in 1.1stable3 (have not tried hard with 1.2-RC1) it seems if I do some stuff - create/delete hosts, etc. and am frequently restarting the httpd service (using passenger) in between doing things. I encountered it fairly often when testing the setup early on when getting everything configured, but now that things are running and the service is not being frequently restarted it pretty much does not happen.
Updated by Ohad Levy over 11 years ago
Joseph, could this be that we are not using a hash_with_in_differnce ?
maybe we somehow do {"name" => ..}.merge(:name => ..) ?
Updated by Joseph Magen over 11 years ago
good point, it could be {"name" => ..}.merge(:name => .. I will look into further
Updated by Toni Schmidbauer about 11 years ago
I'm hitting the same bug. just tried to create a new ovirt guest and got the foreman_###... name in ovirt. deleting the guest and recreating it did not help. but after restarting apache and once again creating the machine, everything is back to normal (no foreman_### name in ovirt and foreman).
Updated by Joseph Magen about 11 years ago
https://github.com/theforeman/foreman/pull/733
Jason, Toni,
Can you try this fix? https://github.com/theforeman/foreman/pull/733
I'm guess the merged hash contained both "name" and :name as keys
{"name" => foreman_234234234, :name => 'the_real_name'}
vm_instance_defaults.merge(attr.to_hash.symbolize_keys)
now vm_instance_defaults has :name as the key, so it will be overwritten by {:name => 'the_real_name'}
Updated by Joseph Magen about 11 years ago
- Status changed from Need more information to Ready For Testing
Updated by Anonymous about 11 years ago
I have been trying repeatedly to reproduce this (using what I think is the reproducer of restarting httpd while I have an open session and then trying to create a VM) and so far it has not happened, so I think this might have been it. :)
I'll continue to try to get it to do the wrong thing, but so far so good.
Updated by Toni Schmidbauer about 11 years ago
didn't happen to me after applying your patch. i'm going to create a few test vm's on monday, if i hit this bug again i will update the case.
thanks
toni
Updated by Joseph Magen about 11 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset 557b8543c26619442be7412ddd5780ec7c550605.