Hi Wouter, On 12/06/2017 09:24 PM, Wouter Verhelst wrote: > Package: openstack-deploy > Version: 0.15 > Severity: minor > > After running "openstack-deploy all-in-one", I find that I do have > something resembling a working openstack installation. Thanks for that!
Yes, this was the initial goal, but no, after you've run the script, you *don't* have a working installation. What openstack-deploy does is *only* installing packages using preseeding, but that's unfortunately not enough to have something that works. For example, the networking setup is *not* performed by this operation, neither Cinder is installed or configured. Within my test setup, this is done by the openstack-deploy-proxy-network script. I would strongly advise for reading this script before using it. It also setups Neutron using openvswitch, which is fine for a small deployment, but wont scale past 10 nodes (too many GRE tunnels is very CPU intensive). Another goal of the openstack-deploy script is to provide a working preseed library, which can be re-used. That goal, IMO, is fully reached. See /usr/share/openstack-deploy/preseed-lib. However, it would need 2 improvements: 1/ support more OpenStack services, not just the core ones. 2/ get improvement for supporting newer debconf preseeding (it currently uses pre-jessie way, which still works, but should be updated). > Unfortunately, however, after all that has happened, one sits there with > a "now what" feeling: > > - The installation asks for a number of things. What do these things > mean? (just hitting "enter" to everything *seems* to work, except for > the "keystone endpoint IP, for which I just entered 127.0.0.1 in this > test environment). Most questions should be answered with the default, which is why the openstack-deploy script has a --non-interactive optional parameter. In Stretch (if that's what you're using), the only small issue with the default is the name of the MySQL server. It should in fact be mariadb-server. Probably you've found this out by yourself. > - Something is running, but where? (localhost:80, it turns out, with > non-SSL HTTP redirected to its SSL version) The default with the Debian OpenStack packages is to *not* use SSL. The reason is, mostly everyone uses an SSL terminator such as HAProxy to perform the SSL job. Under such environment, you'd just setup HAProxy to do the SSL, and modify the API endpoints to publish SSL in the Keystone service catalog. > - After fiddling with apache SSL settings so that those work (this was > on a pristine VM to test with), I need to log on. What with? (the > value of RC_KEYSTONE_ADMINPASS in /root/osinstallrc, it turns out) The openstack-deploy script writes an openrc.sh script. This script contains all the login credentials. What you should do is either copy/past the content of this script in your .bashrc, or simply source it manually on the shell. Then you can use the openstack command line tools. The initial goal of the /root/osinstallrc file, is to: 1/ Cache every answer that have been key-ed in. 2/ Be useful to transporting one's answer from one server to another over scp, so that we get a full cluster provisioning. While 1/ works already very well, 2/ isn't implemented yet, even though the mechanism should work quite well. > I realize that the goal of openstack-deploy is probably to support > openstack-tempest-ci rather than to support users That is correct. > but since it's > packaged in Debian, and since it seems to have several modes, all of > which should support larger installations too, it seems like a prime > candidate for "look at this if you want to build your own cloud" I would love to transform this script to support multi-node installation and be somehow useful for Debian users directly. But I have to admit it didn't reach that point yet. > If only it were a bit better documented. I unfortunately don't think some documentation could be useful until the script can support multi-node setup, and allow a fully working configuration for a running cloud, as per above. I would very much appreciate contribution toward this goal. Remember other operating system are taking advantage of full teams working on OpenStack, while I'm nearly alone (with very useful contribs from Onovy, especially on swift). I clearly lack time to make these scripts useful enough. However, it's shell scripting, it's easy to understand and contribute. Cheers, Thomas Goirand (zigo)
