Migrating from AWS Marketplace to AWS OpsWork Automate


#1

We’ve been trying to migrate our original AWS Marketplace instance across to AWS OpsWork Automate server for several months so far and finding the lack of documentation to be rather unlike Chef.

So far been really unimpressed with the Automate option, as far as I can tell it complicates the process with no benefit and many basic things like node status just don’t work. I’m assuming I’ve missed some documentation on transitioning from a Chef Server setup to Chef Automate and Server and not that you’ve just released a junk product.

https://blog.chef.io/2017/10/16/migrating-chef-server-knife-ec-backup-knife-tidy/ was posted recently and I thought great they’ve finally done some documentation, turns out doesn’t work. Can’t restore the clients into the organisation, can’t restore the nodes correctly,

Is there any documentation that actually covers how to do this?


#2

Can you share the exact command you ran and the error you got?


#3

Commands run where straight out of the blog post mentioned earlier https://blog.chef.io/2017/10/16/migrating-chef-server-knife-ec-backup-knife-tidy/

/opt/opscode/embedded/bin/knife ec restore my_backup_destination --with-user-sql --with-key-sql -c /etc/opscode/pivotal.rb

was run and got the following for all clients when attempting to restore the keys.

Updating key data for client[od-server-00111]
WARNING: Could not find organization for client[od-server-00111], skipping.
WARNING: Organizations much be restored before key data can be imported.

This doesn’t happen on our offline builds when testing the backup.


#4

Forgot to mention, running it a second time didn’t restore the keys either and the logs from the command indicated that the organisation they belonged to was created correctly


#5

It seems that the organization already exists on the destination but has a different org_id than the one in the backup. When using the --with-user-sql --with-key-sql options, a restore has to be pointed at an empty Chef Server. This is because with those options, it does a PostgreSQL level backup/restore of the user data and will conflict or mismatch if that data already exists.

Since it appears that you are restoring to a Chef Server with data already in it you have a couple of options. You can try a new backup and restore this time without the the --with-user-sql --with-key-sql on both operations. This should work regardless if the org_ids are different since it’s no longer a DB level operation. The caveat to that approach is that your users will not have their passwords copied since the passwords are only preserved in a DB level backup. Depending on the number of users and whether or not they are logging into the Chef Server manage UI or just using knife this may or may not be a problem. The alternative is to restore to an empty Chef Server and continue to use the --with-user-sql --with-key-sql options - the org_id will no longer conflict or mismatch then and you should be all set.