Bug #11443
closedptable template ID changed during upgrade from 1.8.2 -> 1.9, breaks unattended provisioning
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:
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.
Updated by Dominic Cleal over 9 years ago
- Related to Feature #7096: Partition Tables should just be a kind of Provisioning Templates added
Updated by Dominic Cleal over 9 years ago
- Category set to DB migrations
- Translation missing: en.field_release set to 72
db/migrate/20150514114044_migrate_ptables_to_templates.rb ought to handle this.
Updated by Dominic Cleal over 9 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
Updated by salman butt over 9 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]#
Updated by Dominic Cleal over 9 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.
Updated by Marek Hulán over 9 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.
Updated by Dominic Cleal over 9 years ago
- Status changed from New to Need more information
- Translation missing: en.field_release 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.
Updated by Tomer Brisker almost 9 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.