Deal with git am failures

Today I needed to take my model git branch which was based off of the develop branch a week ago, and rebase it off of the master. First I did the obvious, git rebase master in my model branch, that yielded tons of conflicts. The conflicts were a result of commits in the develop branch being squashed when they got merged to master to keep the history clean. Instead of fixing tons of conflicts, I simply chose to take my 3 commits and create patches from them:

git format-patch -3 HEAD

I created a new branch off of master and applied my patches using git am.

git checkout master
git checkout -b model_updates
git am ~/0001-add-rhev-params-remove-serialized-hash.patch 
git am ~/0002-start-v21-of-deployments.patch
git am ~/0003-rename-columns-and-include-missing-columns.patch

Patch 0001 and ultimately 0003 applied without problems. Patch 0002 on the other hand gave me fits, I expected it, but I refused to recode the change. git am ... just fails when it hits a conflict. Using the trusty Google, I found this blog: Deal with git am failures. I followed the instructions from that blog post:

git am --abort #abort the previously failed 0002 patch run
git apply ~/0002-start-v21-of-deployments.patch --reject # yield .rej files I could inspect
git add server/app/controllers/fusor/api/v2/deployments_controller.rb # ensure changes are fine
git add server/app/controllers/fusor/api/v21/ # new files from patch
git am --resolved # tells git we're good to go, proceed.

Done! Way easier than dealing with the conflicts from the rebase. Easier than trying to recode the patch as well.

Re-run a modified ActiveRecord Migration

Rails has this cool feature called ActiveRecord Migration. It’s an easy way to create and update your database. But if you get it wrong it is super annoying. This is where migrations and me loathe each other.

I had a migration which had the wrong column names. Now I could easily create another migration to change the names, but I’m still developing and I don’t want yet another migration. First thing I did was modified the migration before rolling things back. That is definitely going to fail. SO I reverted my changes.

class AddRhevParams < ActiveRecord::Migration
  def change
    remove_column :fusor_deployments, :rhev_params
    add_column :fusor_deployments, :rhev_hypervisor_host_id, :integer
    add_column :fusor_deployments, :rhev_engine_host_id, :integer
    add_column :fusor_deployments, :rhev_hypervisor, :string
    add_column :fusor_deployments, :rhev_engine, :string
    add_column :fusor_deployments, :rhev_database, :string
    add_column :fusor_deployments, :rhev_cluster, :string
    add_column :fusor_deployments, :rhev_storage, :string
    add_column :fusor_deployments, :rhev_cpu, :string
    add_column :fusor_deployments, :rhev_share, :string
  end
end

First I tried rake db:rollback STEP=1 hoping that it would put the DB in the state prior to my latest migration. For whatever reason it failed with an IrreversableMigration error.

$ rake db:rollback STEP=1
The Apipie cache is turned off. Enable it and run apipie:cache rake task to speed up API calls.
Workaround for RbVmomi may not work as ComputeResource is already loaded: ComputeResource
[deprecated] I18n.enforce_available_locales will default to true in the future. If you really want to skip validation of your locale you can set I18n.enforce_available_locales = fal
se to avoid this message.
==  AddRhevParams: reverting ==================================================
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

ActiveRecord::IrreversibleMigration/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:42:in `block in inverse'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:40:in `map'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:40:in `inverse'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:401:in `block (3 levels) in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:358:in `revert'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:400:in `block (2 levels) in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:399:in `block in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_pool.rb:129:in `with_connection'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:389:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:528:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:720:in `block (2 levels) in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:775:in `call'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:775:in `block in ddl_transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/transactions.rb:208:in `transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:775:in `ddl_transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:719:in `block in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:700:in `each'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:700:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:574:in `down'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:656:in `move'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:562:in `rollback'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/railties/databases.rake:276:in `block (2 levels) in '
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/bin/ruby_executable_hooks:15:in `eval'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/bin/ruby_executable_hooks:15:in `'
caused by: (ActiveRecord::IrreversibleMigration) ActiveRecord::IrreversibleMigration
    ... skipped 46 lines
ActiveRecord::IrreversibleMigration: ActiveRecord::IrreversibleMigration
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:42:in `block in inverse'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:40:in `map'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:40:in `inverse'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:401:in `block (3 levels) in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:358:in `revert'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:400:in `block (2 levels) in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:399:in `block in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_pool.rb:129:in `with_connection'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:389:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:528:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:720:in `block (2 levels) in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:775:in `call'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:775:in `block in ddl_transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/transactions.rb:208:in `transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:775:in `ddl_transaction'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:719:in `block in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:700:in `each'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:700:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:574:in `down'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:656:in `move'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:562:in `rollback'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/railties/databases.rake:276:in `block (2 levels) in '
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/bin/ruby_executable_hooks:15:in `eval'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/bin/ruby_executable_hooks:15:in `'
Tasks: TOP => db:rollback
(See full trace by running task with --trace)

Then I tried rake db:migrate:down --trace VERSION= and that failed with the same error.

$ rake db:migrate:down --trace VERSION=20150216190947
** Invoke db:migrate:down (first_time)
** Invoke environment (first_time)
** Execute environment
The Apipie cache is turned off. Enable it and run apipie:cache rake task to speed up API calls.
Workaround for RbVmomi may not work as ComputeResource is already loaded: ComputeResource
[deprecated] I18n.enforce_available_locales will default to true in the future. If you really want to skip validation of your locale you can set I18n.enforce_available_locales = fal
se to avoid this message.
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:migrate:down
==  AddRhevParams: reverting ==================================================
rake aborted!
ActiveRecord::IrreversibleMigration: ActiveRecord::IrreversibleMigration
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:42:in `block in inverse'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:40:in `map'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration/command_recorder.rb:40:in `inverse'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:401:in `block (3 levels) in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:358:in `revert'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:400:in `block (2 levels) in migrate'
/home/vagrant/.rvm/rubies/ruby-1.9.3-p448/lib/ruby/1.9.1/benchmark.rb:280:in `measure'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:399:in `block in migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_pool.rb:129:in `with_connection'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:389:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:528:in `migrate'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:679:in `run'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/migration.rb:578:in `run'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/railties/databases.rake:238:in `block (3 levels) in '
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/task.rb:240:in `call'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/task.rb:240:in `block in execute'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/task.rb:235:in `each'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/task.rb:235:in `execute'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/home/vagrant/.rvm/rubies/ruby-1.9.3-p448/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/task.rb:165:in `invoke'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:150:in `invoke_task'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:106:in `block (2 levels) in top_level'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:106:in `each'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:106:in `block in top_level'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:115:in `run_with_threads'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:100:in `top_level'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:78:in `block in run'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:176:in `standard_exception_handling'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/lib/rake/application.rb:75:in `run'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/gems/rake-10.4.2/bin/rake:33:in `'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/bin/rake:19:in `load'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448@global/bin/rake:19:in `'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/bin/ruby_executable_hooks:15:in `eval'
/home/vagrant/.rvm/gems/ruby-1.9.3-p448/bin/ruby_executable_hooks:15:in `'
Tasks: TOP => db:migrate:down

Doing some googling, I found you can run rails console and run the migrations by hand, see Executing Migration Commands From Rails Console.

I then ran these commands in my rails console:

ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_hypervisor_host_id
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_engine_host_id
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_hypervisor
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_engine
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_database
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_cluster
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_storage
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_cpu
ActiveRecord::Migration.remove_column :fusor_deployments, :rhev_share
ActiveRecord::Migration.add_column :fusor_deployments, :rhev_params, :text

Then I went into the database and deleted the reference to my migration from the schema_migrations.

=# delete from schema_migrations where version = '20150216190947';

That cleaned up the migration and I was able to rerun using rake db:migrate

class AddRhevParams < ActiveRecord::Migration
  def change
    remove_column :fusor_deployments, :rhev_params
    add_column :fusor_deployments, :rhev_hypervisor_host_id, :integer
    add_column :fusor_deployments, :rhev_engine_host_id, :integer
    add_column :fusor_deployments, :rhev_hypervisor_hostname, :string
    add_column :fusor_deployments, :rhev_engine_hostname, :string
    add_column :fusor_deployments, :rhev_database_name, :string
    add_column :fusor_deployments, :rhev_cluster_name, :string
    add_column :fusor_deployments, :rhev_storage_name, :string
    add_column :fusor_deployments, :rhev_storage_type, :string
    add_column :fusor_deployments, :rhev_storage_address, :string
    add_column :fusor_deployments, :rhev_cpu_type, :string
    add_column :fusor_deployments, :rhev_share_path, :string
  end
end

So if you have trouble rolling things back automatically, you can try using rails console and mucking with the schema_migrations database table.

remote virt-manager access via SSH

For the most part I always used virt-manager locally to manage my development guests. There was a nice article, sorry it escapes me right now, on how to setup a policy to avoid entering the password locally a bazillion times.

When I worked from home using virt-manager to remotely manage my guests on my workstation was unbearable. Why? Because it meant entering the root password a bazillion times. After years of suffering through this, TODAY! I finally found this really old Fedora documentation:

Virtualization Guide

What’s the secret? SSH-KEYS! UGH! trivial. All this time all I had to do was setup my keys so I could login to the box. This removed the necessity for entering the root password a BAZILLION time. Now I enter my passphrase once and done. UGH! really so simple.

So if you’ve been trying to use virt-manager to remotely manage your guests and having to enter the password in that tiny @$$ password box, try setting up your ssh-keys correctly.

Nexus 4 Android 5.0 Lollipop

For some reason the Lollipop OTA wouldn’t install on my Nexus 4. It kept failing with the following error:

Package expects build fingerprint of
google/occam/mako:4.4.4/KTU84P/1227136:user/release-keys or
google/occam/mako:5.0/LRX21T/1576899:user/release-keys: this device has
google/occam/mako:4.4.2/KOT49H/937116:user/release-keys.

E:Error in
/cache/1c6f10c34ed54fb29844906b2f041c900ba23a6b.signed-occam-LRX21T-from-KTU84P.1c6f10c3.zip

I tried a couple of times but no avail. The reports I read mentioned something might have changed for being root. I unlocked and rooted the Nexus 4 when I bought it, but I don’t remember really doing anything that really should’ve messed anything up. But oh well. I even tried flashing the two recoveries that matched: KOT49H and KTU84P. That didn’t help.

So I downloaded the factory image and ran the flash-all.sh.

[jesusr@dhcp137-228 occam-lrx21t]$ adb reboot bootloader
[jesusr@dhcp137-228 occam-lrx21t]$ ./flash-all.sh 
sending 'bootloader' (2264 KB)...
OKAY [  0.073s]
writing 'bootloader'...
OKAY [  0.370s]
finished. total time: 0.443s
rebooting into bootloader...
OKAY [  0.001s]
finished. total time: 0.001s
sending 'radio' (45537 KB)...
OKAY [  1.437s]
writing 'radio'...
OKAY [  3.373s]
finished. total time: 4.811s
rebooting into bootloader...
OKAY [  0.001s]
finished. total time: 0.001s
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
archive does not contain 'system.sig'
--------------------------------------------
Bootloader Version...: MAKOZ30f
Baseband Version.....: XXXXXX-XXXXXXXX-2.0.1701.04
Serial Number........: XXXXXXXXXXXXXXXX
                       
--------------------------------------------
checking product...
OKAY [  0.002s]
checking version-bootloader...
OKAY [  0.002s]
checking version-baseband...
OKAY [  0.002s]
sending 'boot' (6348 KB)...
OKAY [  0.204s]
writing 'boot'...
OKAY [  0.397s]
sending 'recovery' (6892 KB)...
OKAY [  0.220s]
writing 'recovery'...
OKAY [  0.398s]
erasing 'system'...
OKAY [  3.935s]
sending 'system' (809641 KB)...
OKAY [ 25.481s]
writing 'system'...
OKAY [ 62.844s]
erasing 'userdata'...
OKAY [ 76.469s]
formatting 'userdata' partition...
Creating filesystem with parameters:
    Size: 14129561600
    Block size: 4096
    Blocks per group: 32768
    Inodes per group: 8144
    Inode size: 256
    Journal blocks: 32768
    Label: 
    Blocks: 3449600
    Block groups: 106
    Reserved block group size: 847
Created filesystem with 11/863264 inodes and 95427/3449600 blocks
sending 'userdata' (137438 KB)...
writing 'userdata'...
OKAY [ 13.446s]
erasing 'cache'...
OKAY [  0.190s]
formatting 'cache' partition...
Creating filesystem with parameters:
    Size: 587202560
    Block size: 4096
    Blocks per group: 32768
    Inodes per group: 7168
    Inode size: 256
    Journal blocks: 2240
    Label: 
    Blocks: 143360
    Block groups: 5
    Reserved block group size: 39
Created filesystem with 11/35840 inodes and 4616/143360 blocks
sending 'cache' (10984 KB)...
writing 'cache'...
OKAY [  1.029s]
rebooting...

finished. total time: 184.628s
[jesusr@dhcp137-228 occam-lrx21t]$ 

Phone has rebooted and re-downloading apps from Google. Next I’ll restore my Helium backup hopefully that worked :)