I wanted to play some more with openstack. My existing environment was an Ubuntu VM running DevStack, so instances started under OpenStack were effectively VMs running inside VMs. When an OpemStack VM started it resoponded OK but it could take a few hours to boot up first; which I found a little frustrating.
So I decided to install DevStack onto a sort of spare physical machine, my backup VM server running Fedora20. Well that was a mistake. The major irritatiom was it removed the firewalld package from the server which is not permissable on a physical machine. The install (stack.sh) completed OK so I reinstalled and reconfigured firewalld.
After a reboot rejoin-stack.sh failed, so I had to rerun stack.sh again; and yes it removed firewalld again.
My conclusion from that is that DevStack should never be installed on a physical machine.
So as I don’t want to keep Ubuntu (it only ever existed in my environment as a VM to be a devstack host) I decided to create a Fedora20 VM in the hopes it would be a little faster.
Minimal F20 install built; DevStack cloned from github, stack.sh run… hung at creating VG stage at a pending reboot ???. Manually removed /var/run/nologin from the console, changed SELinux to permissive and rebooted. Reruning stack.sh completed that time.
And as a bonus after that the OpenStack command line glance/nova commands worked ok.
It should have been running fine after that but there were still a few issues.
Required applications installed are not set to start by default
Which is the point at which the ‘physical machine’ install went wrong. And the problems persisted but at least in a VM isolated from other tasks I could debug the issues.
- stack.sh starts httpd… but in the f20 devstack install the httpd service is set to disabled so it will not start on a reboot… and the rejoin-stack.sh does not start it
- stack.sh starts mariadb (mysql)… and as above, it is disabled… and the rejoin-stack.sh does not start it
- or basically stack.sh installs the required underlying applications but leaves them in a disabled state; which is decidedly not helpfull
So you have to “systemctl enable” httpd and mariadb before even thinking of rebooting… which is not at all obvious as the initial stack.sh started to a working state; and nowhere is it mentioned it will be dead on a reboot. But then if you didn’t have decades of experience with *nix systems you wouldn’t be playing with it.
Anyway after doing that (rejoin-stack.sh still needs to be run) all seemed well. The later release certainly has a lot more options than the older version I was playing with; and quite honestly it runs a heck of a lot faster inside a Fedora VM than it did under the Ubuntu VM.
But it is not fully functional; known OpenStack bug
You cannot import custom images in the current github version of openstack downloaded by devstack.
Not using “glance image-create” or the OpenStack web-based UI application. After a bit of research I found a very similar image-create issue as a known bug already reported to redhat. The error occurs using –file filename, with trying to pipe from stdin amd using –copy-from or –location. You just cannot do it.
And just a heads up that the issue also prevents the use of glance “image-delete” and “image-update” commands as well. Basically you cannot use the command line to manage images at all.
The web UI interface has an image create option, which I guess is BETA as it doesn’t work. The image create page says images can only be loaded using the url location method at present, which doesn’t work. Trying that creates a “queued” image that shows up as queued in glance “image-list” (which as noted above glance “image-delete” cannot be used to clean up) but a fuser on the file it is supposed to be reading via url shows the file is never opened.
But fortunately the web UI interface can delete the image, so whatever the security problem with the command line is it does not affect the web-interface; for existing images and delete anyway (and image property update also eventually completes using the web UI). So you can delete that way… but there is no working way to add an image.
Anyway….
If you want to play with setting up projects/users/floating-ips etc you can play with this (you will not learn anything not in a manual so why bother).
If you actually want to use it to build custom images to test new images and cloud-init functions to see how you can make it work for you, then forget it until the custom image support is working again.
As there is already a fault raised I will not waste time trying to figure out how to manually get around the errors unless it takes ages to get fixed.
I am more interested in slicing and dicing disk images and packages based on cloud-init parms passed to an image… which means I need to be able to install images. So future posts on OpenStack are on hold until image import is fixed.
Thumb twiddling
While killing time, I have on the assumption it will be fixed eventually, built F20 images to deploy mvs3.8j (a customised turnkey3 under hercules is the only app on that one, and while obviously untested is available as a download from the mvs38j section of my site if you want it [I will test it under the prior release of DevStack/OpenStack when I find time, maybe; I still have the old ubuntu kvm but would prefer to go forward rather than backward]) and my custom Fedora base image (still a bare image but with the addition of tools I think should be on a bare image like iotop/iftop/nrpe/bacula-fd etc); in the hope one day “glance image-create” will work again so I can test them.
And I will try to build an OpenIndianna image next weekend; that will probably take all weekend as I don’t know if it supports cloud init yet so will have to code the scripts to get the data passed to the instance and slot them in at the start of the svcs chain; at least the zfs filesystem used there should be able to resize to any supplied disk size reasonably easily.
I will just keep checking the redhat bugzilla problems until a fix is identified I guess; not until then can I test my new images.
Update: 12 Oct 2014
Trying to upgrade from github failed miserably.
Created a new minimal F20 VM and re-installed devstack from scratch from the latest github version.
It no longer gets the permission denied error when creating images… we are back to just hanging forever using stdin/–file/–copy-from options again. glance shows the image is queued and nova shows it is saving… but the input file it is supposed to be saving fuser shows is not actually opened, whether from local disk or remote url. I cannot understand why as during install it managed to pull down a Fedora image from github; but I have gone through the install scripts and used exactly the same ‘openstack’ command the install scripts used and that also hangs.
Will have one more try using an Ubuntu VM again instead of Fedora as the much older DevStack release I have that does allow images created was Ubuntu.
