Project

General

Profile

Bug #11443

ptable template ID changed during upgrade from 1.8.2 -> 1.9, breaks unattended provisioning

Added by salman butt almost 5 years ago. Updated over 4 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
DB migrations
Target version:
-
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:

Description

I upgraded from version 1.8.2 to 1.9 earlier this morning. No problems were encountered during the upgrade, or the app restart after.

Performing a test provision after the upgrade resulted in this error:

http://pastebin.com/3eFfmn6E

After some digging around, I found that my ptable template ID changed from 12 to 67, somehow. The OS had been created in foreman approximately 3 weeks ago, and the ptable had been associated with it. I had provisioned several VMs under this OS -- most recent was two days ago. No other changes were made to the KS template, or the ptable template.

One odd thing: Attempting to preview the KS template for a host which already existed (existingHost01) rendered the template w/out any problems. When I attempted to preview the KS template for the host I was attempting to provision today (newTestProv01), the template threw an error.

I checked the OS and verified that the ptable was listed as associated, and the checkbox was checked.

Please let me know if I can provide further information.


Related issues

Related to Foreman - Feature #7096: Partition Tables should just be a kind of Provisioning TemplatesClosed2014-08-14

History

#1 Updated by Dominic Cleal almost 5 years ago

  • Related to Feature #7096: Partition Tables should just be a kind of Provisioning Templates added

#2 Updated by Dominic Cleal almost 5 years ago

  • Category set to DB migrations
  • Legacy Backlogs Release (now unused) set to 72

db/migrate/20150514114044_migrate_ptables_to_templates.rb ought to handle this.

#3 Updated by Dominic Cleal almost 5 years ago

Could you running these commands please? I haven't been able to replicate this.

foreman-rake db:migrate:status | grep 20150514114044
foreman-rake db:migrate:up VERSION=20150514114044

#4 Updated by salman butt almost 5 years ago

Dominic,

Please see below:

[root@ny2lppuppet01 build]# foreman-rake db:migrate:status | grep 20150514114044
20150514114044 Migrate ptables to templates

[root@ny2lppuppet01 build]# foreman-rake db:migrate:up VERSION=20150514114044
[root@ny2lppuppet01 build]#

#5 Updated by Dominic Cleal almost 5 years ago

Thanks, seems that it ran but there's an error still.

A user reported on IRC that it was only two hosts in build mode that weren't updated correctly.

Editing and re-saving a host, ensuring that the correct partition table is selected under the OS tab should fix any affected hosts.

#6 Updated by Marek Hulán almost 5 years ago

I'm unable to reproduce. I migrated down the migration 20150514114044, then up again looking at host in build mode, it's ptable_id was updated correctly to new object. New object would fail the migration if it was not saved. It doesn't seem as a migration issue. A log from original migration run could help otherwise I'm not sure if we can find the cause and fix it.

#7 Updated by Dominic Cleal almost 5 years ago

  • Status changed from New to Need more information
  • Legacy Backlogs Release (now unused) deleted (72)

Yeah, I've tried to reproduce it a few times too, including this morning with a host in build mode. My only guess is that perhaps it's performing validation on hosts during the migration and some aspect of orchestration is failing, but I've no evidence for it.

/var/log/foreman-install.log on Debian or /var/log/foreman/db_migrate.log on an RPM installation may help if it shows errors.

#8 Updated by Tomer Brisker over 4 years ago

  • Status changed from Need more information to Rejected

Could not be reproduced and no new info was provided in 6 months. Closing, feel free to reopen if this is still an issue and provide more information.

Also available in: Atom PDF