[PKG-Openstack-devel] Bug#883723: Bug#883723: openstack-deploy: undocumented

[Thomas Goirand]

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)