Bug #2317: Foreman starts creating VM's with the name foreman_######## - Foreman

Custom queries

3.11.5 release DONE
3.11.5 release TODO
3.12.2 release DONE
3.12.2 release TODO
3.13.0 release DONE
3.13.0 release TODO
All bugs by votes
All issues closed in the last 3 weeks
Easy and Trivial Issues
Easy Issues (only)
Foreman - new open issues in last 10 days
Good first issues - Foreman core
high prio open bugs
Host registration [open]
Mine
My issues closed in the last 3 weeks
old bugs
Open with target version set (aka blockers)
registration
taken-none
Team Atlas untriaged bugs
templates
Trivial Issues
Untriaged and opened in the past two weeks

Actions

Copy link

Bug #2317

closed

Foreman starts creating VM's with the name foreman_########

Added by Anonymous almost 12 years ago. Updated over 11 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Joseph Magen

Category:

Compute resources - oVirt

Target version:

1.2.0

Difficulty:

Triaged:

Bugzilla link:

Pull request:

Fixed in Releases:

Found in Releases:

Red Hat JIRA:

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

wrongname.png

View wrongname.png

38 KB

Screenshot of wrong name

Anonymous, 03/26/2013 10:41 AM

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by Anonymous almost 12 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.

Actions

Copy link

Updated by Ohad Levy almost 12 years ago

this some how were hash attributes (the default vm hash) is merged with the requested details incorrectly (probably in the wrong direction).

Actions

Copy link

Updated by Dominic Cleal almost 12 years ago

Category set to Compute resources - oVirt
Target version set to 1.2.0

Actions

Copy link

Updated by Ohad Levy over 11 years ago

Assignee set to Joseph Magen

Actions

Copy link

Updated by Joseph Magen over 11 years ago

Status changed from New to Assigned

Actions

Copy link

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.

Actions

Copy link

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.

Actions

Copy link

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 => ..) ?

Actions

Copy link

Updated by Joseph Magen over 11 years ago

good point, it could be {"name" => ..}.merge(:name => .. I will look into further

Actions

Copy link

#10

Updated by Toni Schmidbauer over 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).

Actions

Copy link

#11

Updated by Joseph Magen over 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'}

Actions

Copy link

#12

Updated by Joseph Magen over 11 years ago

Status changed from Need more information to Ready For Testing

Actions

Copy link

#13

Updated by Anonymous over 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.

Actions

Copy link

#14