OpenStack – I am stuck on Newton for now

Issues with upgrading from Newton to Ocata have made me hold off upgrading to Ocata, I did make a few attempts.

Attempt One

After a normal upgrade from Newton to Ocata there were errors in the logs saying the placement service was optional in Newton but required in Ocata… and should have been installed in Newton before an upgrade was attempted. And while login to Horizon dashboard worked attempting to display pretty much anything using it failed.

Found a web post on setting that up so installed the placement package, configured it, added the service, added the endpoints etc… and eventually eliminated all the errors in the logs. Same issues with horizon.

The placement database required and initialised was nova_api_cell0.

As it still didn’t fix the issues with the horizon web interface reverted back and tried…

Attempt Two

Reverted back to the backed-up Newton system (don’t you just love VMs). And installed the placement service there before performing the upgrade.

The placement database required and initialised was nova_cell0.

Upgraded to Ocata and got the same errors for the placement service not being configured correctly. Running the database migration/upgrade scripts gave the error that the database was still missing… The nova_api sync step failed again because of a missing database, you guessed it, Ocata needs the database nova_api_cell0 not the nova_cell0 used by Newton… so had to recreate that database and run the simple cell creation script to populate that database.

So now I had two new databases both containing the same tables, was it safe to delete the first ?.

Anyway I had the same issues with Horizon not being able to display anything usefull. Dropped those VMs.

Attempt Three

Reverted back to the Newton VMs with no placement service installed… Ok I was lazy and did not want to build a new empty set of VMs for what may be a pointless exercise.

I stopped all openstack services and dropped all mariadb tables used by openstack. Changed the repository to the RDO Ocata one and did a fresh packstack install. The openstack mariadb databases were created, but none for the placement service nor was placement installed. However I cannot remember if I updated packstack itself before re-running packstack, so my bad… will have to find time to test a all-in-one on a fresh VM when I find the time.

Summary, why I stay on Newton for now

  • in “attempt one” I did spend days customising the “*rpmnew” configuration files to try and get my configuration ported across and the [placement_database] section in nova.conf for Newton does not exist in the rpmnew file installed for Ocata, lack of info on why or what it defaults to
  • direct upgrade to Ocata has error messages saying placement should be configured on Newton first… which is a waste of time as Newton and Ocata require different database names, so don’t bother getting it working in Newton all you have to so a lot of rework
  • and the big issue, is that the horizon web interface is unable to display anything useful; it cannot even display active hypervisors/compute-nodes which I assume means it cannot deploy instances onto them either… that is a show stopper. It may simply be a case of the authorisation URLs changing from V2 to V3 but as well as configuration file changes it would require manual deletion/recreation of endpoints, and I cannot find any documentation on the changes needed (the commands to delete add endpoints are of course documented as part of the standard documentation; it is the names/uri’s/url’s that need to be created for Ocata that are impossible to find)

Next steps… upgrade attempts on hold

The main reason I have put on hold more attempts to upgrade is that I need a working environment so cannot keep trashing my lab machine.

I need it to play with a stack installing puppet server and a couple of agent servers to see if it can be of any use to me. For server “application” build I do not think puppet is likely to be of much use to me as all my VMs and instances are single purpose; but for server “management” it might be of use (ie: making sure all servers with agents have the same nrpe custom check scripts propagated to them, all servers have a bacula-fd service configured and running etc.), but that will be a different post as my “servers” run a range of different operating systems and I have a lot of reading to do on how agents provide ‘facts’ to allow it all to hang together… but I have put on hold breaking my lab environment for now.

And something totally unrelated to the post. Neither the horizon interface or command line interfaces for resizing instances work for me in Newton. And after a resize operation fails the instance has a rubbish flavor id (an id that does not match any existing flavor). OK I should have sized the instance correctly in the first place and didn’t, but there appear to be placeholder commands that partially complete a task and leave a mess to clean up… but as cleaning up helps understand some of the underlying activities that could be considered a learning bonus.

About mark

At work, been working on Tandems for around 30yrs (programming + sysadmin), plus AIX and Solaris sysadmin also thrown in during the last 20yrs; also about 5yrs on MVS (mainly operations and automation but also smp/e work). At home I have been using linux for decades. Programming background is commercially in TAL/COBOL/SCOBOL/C(Tandem); 370 assembler(MVS); C, perl and shell scripting in *nix; and Microsoft Macro Assembler(windows).
This entry was posted in OpenStack. Bookmark the permalink.