After running "openstack-deploy all-in-one", I find that I do have
something resembling a working openstack installation. Thanks for that!

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).
- Something is running, but where? (localhost:80, it turns out, with
  non-SSL HTTP redirected to its SSL version)
- 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)

I realize that the goal of openstack-deploy is probably to support
openstack-tempest-ci rather than to support users; 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"

If only it were a bit better documented.

Hi Wouter,

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).

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.

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.
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.

That is correct.

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.

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)

Control: severity -1 normal
Control: retitle -1 openstack-deploy: incomplete, undocumented

Oh, okay. I did say "resembling", mostly because I hadn't had a chance
of testing it out yet, in much detail.

That's possibly also something that should be documented. The script
already does a great deal and gets you partway there; it's fine if that
doesn't yet do everything, but then at least a hint in the documentation
as to what it doesn't do yet in some reasonable detail, with a pointer to
the upstream bits of documentation that should be followed, would be
useful.

Right.

This, too, sounds like something that might need to be documented.

Right.

Right, yes, I saw that. But my point is that it should be documented
somehow/somewhere what the meaning of all those questions is. What
happens if I enter something else?

For the generated passwords, this is rather obvious, but not for all of
the asked questions.

Yes.

I have. Even so, just accepting the default does work, due to mariadb
metapackages doing the right thing.

Actually, after running "openstack-deploy all-in-one" on a pristine
Debian system (installed from d-i, "apt install openstack-deploy",
running "openstack-deploy all-in-one") and accepting the defaults (apart
from the keystone endpoint that doesn't have a default, as per above), I
found that the openstack-dashboard-ssl-redirect.conf and
openstack-dashboard-ssl.conf apache2 sites were enabled.

I think this makes sense, but it didn't work for my setup; however, this
is likely to be because reaching my openstack test VM's webinterface
required me to use an ssh jumphost and do a few "interesting" things.

(additionally, the default configuration doesn't seem to allow
connecting to the dashboard from a remote system. I'm not sure yet
whether that's me or whether the configuration simply needs to be
updated)

[...]

Right.

I had suspected that it would already, but I can understand that
implementing that is not trivial.

Fair enough.

I have to disagree here.

For the simple case of "let me install things and see how it works",
having an all-in-one setup working *is* a useful thing. For people who
simply want to test and play with things, documentation is very very
useful.

Even in its current state, where openstack-deploy gets you part of the
way there, but not completely, I think it can be useful for such users,
provided it's clear to them what they get and what they don't get, what
they may want to add if they want more, and how they should do so --
even if that's not in full howto-style detail.

People who will be implementing a large setup (say, dozens of nodes or
more) should already be expected read up on openstack and all the
options that exist before they go ahead and install things, so the
openstack-deploy script doesn't necessarily need to cater to them (at
least not in a first implementation). However, if the all-in-one case
works really really well, that would go a long way towards enabling
people to understand openstack better, and would likely net you some
more interested contributors.

Having said that, I completely understand that it's work, and somebody
needs to do it.

I would love to be able to contribute, but at this point in time I can
only point out holes in the documentation from a newbie's POV. The
openstack-deploy run that triggered this bug report was my first attempt
at learning how Openstack works...

As a first and obvious step, it might be useful if the questions that
are asked by openstack-deploy were a bit more self-documenting; e.g.,
rather than just saying "please enter value X [default xyz]", do
something along the lines of "we need value X for purpose foo which will
be used by the neutron, keystone, and rabbitmq services. For more
infomation, see <URL>.\nValue X [default xyz]". This doesn't need to be
very complicated or large; the main point is that it should allow a user
who goes "wtf is this" to understand what the point is to the question,
and where to look for further information.

The documentation doesn't need to complete, but it should be enough to
get started.

[...]

Looking at things more closely, I find that:

- The installed services are a strict superset of the "compute starter
  kit" as defined on
https://www.openstack.org/software/sample-configs#compute-starter-kit
  (which contains nova, glance, keystone, and neutron), and therefore
  should already have basic functionality of the "let's see how this
  works" type.
- Uploading the image downloaded from
http://cdimage.debian.org/cdimage/openstack/current/debian-9.2.2-20171105-openstack-amd64.qcow2
  through the webinterface seems to work.
- Creating a network through the webinterface seems to work.
- Creating a "flavor" through the webinterface seems to work.
- After doing all that, I can go through the "Launch instance" wizard in
  the webinterface. It accepts my choices; but when it gets around to
  actually trying to spawn the VM, the machine becomes unresponsive.
  Once it starts being responsive again, it says "No valid host was
  found. There are not enough hosts available." It's not clear to my
  what exactly went wrong; this may be fixed by some configuration, or
  it may not. At this point, I can't remove the instance anymore either,
  with a "CSRF token missing or incorrect" error message.

It feels like the system is fairly close to a working setup, though.

I have extensively contributed to the upstream documentation. There's
even 2 install guide that you'll find for OpenStack in Newton:

https://docs.openstack.org/newton/install-guide-debconf/
https://docs.openstack.org/newton/install-guide-debian/

What you can do is simply run openstack-deploy, then read the steps of
the install-guide. Most of the steps will be already performed by the
script, like installing the package, registering endpoint in the
keystone catalog, setting the keystone_authtoken and configuring the db.

Unfortunately, because the doc people appeared unstaff after rackspace
laid-off a lot of its personnel, this is the last install-guide for
OpenStack. It's quite fortunate that it is also the best install-guide
for Debian, where I could check everything was working as expected. So I
very much recommend this reading.

In theory, I would agree. Though I found that contributing to the doc
upstream was a much better way to address the documentation.

Oh good! :)

Installing horizon without any preseeding just work too, though you end
up having horizon installed under /horizon instead of the root of the
web server, which is Debian policy compliant. You can just
dpkg-reconfigure openstack-dashboard-apache if that's what you prefer.

I believe that's just you, but I may be wrong! :)

Now that I gave you a pointer to upstream install-guide for Debian, do
you still have the same view on this?

I'd like to reach that point where just running the openstack-deploy
script would be enough. Though there's one par that can't ever be done
automatically: networking. Indeed, it really depend on your
configuration and topology. I've been thinking about this for a long
time and can't think it out.

I very much appreciate your feedback already. Thanks !

I see your point. I'll try to write something down. I in fact already
did some of this as a blog entry to explain openstack-tempest-ci, which
may be useful for newbies to just try the Debian OpenStack all-in-one
version within a KVM machine. The only issue is that that machine has to
be quite big (at least 24 GB of RAM).

Thanks again for your feedback,
Cheers,

Thomas Goirand (zigo)

Missed that. A simple pointer to that documentation from the script (or
even the wiki) would have gone a *long* way towards helping me out on
things here :-)

Right.

Heh. Will do, thanks :-)

For clarity, I'm not saying that you need to have full documentation in
openstack-deploy itself. It makes perfect sense for it to point to the
relevant upstream documentation. However, it doesn't even do that
today. It just runs, magic happens, and I can see that things are
running; but it doesn't tell me what or where, and it doesn't tell me
what the next steps are. After openstack-deploy ran, there are somewhere
between 10 and 20 listening ports on localhost, with no indication of
where to go next.

It doesn't need to be much, but it could be more than there is today :-)

Right :)

No, it is not :-)

Actually, it turns out that if DEBUG is enabled in the django
configuration, which appears to be the default, then only localhost
connections are allowed. So, no, not me ;)

I'll answer this bit later (haven't yet had the time to look at this in
detail)

IMHO, that's fine. Just document the choices which the user has to make,
how to make them, and, crucially, what choices have already been made
for the user by the openstack-deploy script.

Honestly, I think openstack-deploy would be massively more usable if it
just had some output at the end saying something along the lines of...

---
Success! The following services have been installed and fully
configured:

- U
- V

The following services have been installed, but require more
configuration before they can be properly used:

- W
- X

You may be interested in the following additional services, which are
also packaged for Debian but have not been installed:

- Y
- Z

For more information on how to configure these services, please see the
upstream documentation at <url>.

The configuration that was generated by this script (including generated
passwords) can be found in the file '/root/openrc.sh'.
---

...because it gives the user immediate feedback of the changes that were
made, and where to look for further information.

(I'm not that sure about the "additional services" bit of the above,
since that might end up being a slippery slope -- but the first two,
surely, should be doable).

As everyone knows, documentation is only read if all else fails, so you
need to force people to look at it by throwing it in their face even
when they didn't ask for it ;-)

Oh dear. That's about the amount of memory on that particular bare metal
machine :-)

Sure.

The "No valid host was found" should be interpreted as "no compute host
is working, I can't start the VM". Since you have only one compute node,
it means that host doesn't work.

Have you made sure to replace nova-compute-kvm by nova-compute-qemu,
since you're in a VM? After doing so, make sure to restart nova-compute.

This is a known bug in Horizon in Stretch, due to an incompatibility
with Django 1.10. It has been fixed since, but I haven't investigated in
which commit, so I could backport it.

Instead of selecting the instance with the checkbox, just click on the
dropdown and click on terminate. This should work.

Once you've fixed the nova issue, I'm quite sure you'll have trouble
with the networking (unless you've followed the install guide to make
your networking setup). In any case, just look in your
/var/log/{nova,neutron}/*.log when starting the VM. And try without
horizon, with something like this:

openstack server create --image \
	$(openstack image list --format=csv | q -d , \
	-H 'SELECT ID FROM -') --flavor $(openstack flavor \
	list --format=csv | q -d , -H \
	'SELECT ID FROM - WHERE `Name`="m1.tiny"') \
	--nic net-id=$(openstack network list --format=csv \
	| q -d , -H \
	'SELECT ID FROM - WHERE `Name`="demo-net"') \
	test-server.debian.net

(you can adapt of course, with network name, image name, and flavor)

Cheers,

Thomas Goirand (zigo)

Well, on the bare metal I do have...

root@latin ~ # cat /sys/module/kvm_intel/parameters/nested
Y

...so I was under the impression that that should just work? I now see
that you also need to configure the host VM to have particular CPU bits
set, so maybe that was my mistake.

Anyway, since this is just meant for a test setup it's not critical, so
if my new attempt doesn't work I'll try the qemu thing.

Well, between this and the above and a few other mistakes I'd made, I
decided that starting over would be a good idea, so I destroyed the
containing VM and started over from scratch. So I can't test this right
now, but I think I couldn't do "terminate" since the VM wasn't
running...

I did have some network up, but I don't know whether it worked :-)

[...]

Sorry for the long delay. This project got set on the backburner a bit,
because plans had changed at a customer for whom I was planning to look
into this. I'm still interested however, so, I've been trying again
recently, and found that the reason keystone has no default is because
openstack-deploy wants to run /sbin/route, but that isn't in essential,
and openstack-deploy doesn't depend on it. Installing the net-tools
package before running openstack-deploy fixes that.

(I can probably file a separate bug for that, but...)

Hello,

Bug #883723 in openstack-meta-packages reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/openstack-team/debian/openstack-meta-packages/-/commit/07f1db5d950c8b94832d3c6bbf9096ee3e6798ed
------------------------------------------------------------------------
Documented the tooling and added a run summary

Documents the whole deployment tooling in a top-level README.md
(binary packages, tools, all-in-one and multi-node flows, the
/root/osinstallrc RC_* variables, and a full preseed-lib reference),
and makes openstack-deploy print a summary at the end of the
controller, compute and all-in-one runs: what got installed, where
the dashboard and the credentials are, and what is left to do by
hand (Closes: #883723).
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/883723

Hello,

Bug #883723 in openstack-meta-packages reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/openstack-team/debian/openstack-meta-packages/-/commit/59b5327be2faf5c76e9336b97fc6cf7b8c7c94ed
------------------------------------------------------------------------
Documented the tooling and added a run summary

Documents the whole deployment tooling in a top-level README.md
(binary packages, tools, all-in-one and multi-node flows, the
/root/osinstallrc RC_* variables, and a full preseed-lib reference),
and makes openstack-deploy print a summary at the end of the
controller, compute and all-in-one runs: what got installed, where
the dashboard and the credentials are, and what is left to do by
hand (Closes: #883723).
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/883723

Hello,

Bug #883723 in openstack-meta-packages reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/openstack-team/debian/openstack-meta-packages/-/commit/59b5327be2faf5c76e9336b97fc6cf7b8c7c94ed
------------------------------------------------------------------------
Documented the tooling and added a run summary

Documents the whole deployment tooling in a top-level README.md
(binary packages, tools, all-in-one and multi-node flows, the
/root/osinstallrc RC_* variables, and a full preseed-lib reference),
and makes openstack-deploy print a summary at the end of the
controller, compute and all-in-one runs: what got installed, where
the dashboard and the credentials are, and what is left to do by
hand (Closes: #883723).
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/883723

Hello,

Bug #883723 in openstack-meta-packages reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/openstack-team/debian/openstack-meta-packages/-/commit/59b5327be2faf5c76e9336b97fc6cf7b8c7c94ed
------------------------------------------------------------------------
Documented the tooling and added a run summary

Documents the whole deployment tooling in a top-level README.md
(binary packages, tools, all-in-one and multi-node flows, the
/root/osinstallrc RC_* variables, and a full preseed-lib reference),
and makes openstack-deploy print a summary at the end of the
controller, compute and all-in-one runs: what got installed, where
the dashboard and the credentials are, and what is left to do by
hand (Closes: #883723).
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/883723

We believe that the bug you reported is fixed in the latest version of
openstack-meta-packages, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 883723@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Thomas Goirand <zigo@debian.org> (supplier of updated openstack-meta-packages package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 09 Oct 2026 10:17:34 +0200
Source: openstack-meta-packages
Architecture: source
Version: 0.42
Distribution: unstable
Urgency: medium
Maintainer: Debian OpenStack <team+openstack@tracker.debian.org>
Changed-By: Thomas Goirand <zigo@debian.org>
Closes: 883723
Changes:
 openstack-meta-packages (0.42) unstable; urgency=medium
 .
   * Fixed and completed preseed-lib to match the current debconf
     questions of all OpenStack services (shared openstack-pkg-tools
     templates), added placement, gnocchi, ironic, magnum, octavia and
     vigie preseeding, and rewrote openstack-preseed on top of preseed-
     lib (now shipped in /usr/sbin).
   * openstack-preseed: fully automated with zero interaction: single-
     node and proxy-node auto-detect everything and save their values in
     /root/osinstallrc (also creating a remote-capable openstack RabbitMQ
     user), while compute-node reads them from that same file and only
     prompts for missing values.
   * openstack-deploy now prints a summary of what has been installed and
     of what still needs to be done at the end of a deployment run, and
     the whole deployment tooling is documented in a top-level README.md
     (Closes: #883723).
Checksums-Sha1:
 cee9e24fe2cf19fc651781e4729365a3723a6561 2452 openstack-meta-packages_0.42.dsc
 1734d7d09aed571aa96fd3dd69af5a2e79397358 59144 openstack-meta-packages_0.42.tar.xz
 9098febccb705a24cd8c00167650cee3ed31dc70 8392 openstack-meta-packages_0.42_amd64.buildinfo
Checksums-Sha256:
 a5f6b6f3db5bf477012556af6db27917e92c6976c4c4f232095fd47e52785cdd 2452 openstack-meta-packages_0.42.dsc
 68528707ac0fdc8260f830b532e9b6aed8bcfa28671a911ccd1e25e92e929f02 59144 openstack-meta-packages_0.42.tar.xz
 b5543d8ac3a45c39a7c4afca28887408030e84f58e3a8bd2b1553988b173a333 8392 openstack-meta-packages_0.42_amd64.buildinfo
Files:
 044944061bd1ee4b7d868e96513072e3 2452 net optional openstack-meta-packages_0.42.dsc
 6fcf5db310da4d4f9701c4667fe894e0 59144 net optional openstack-meta-packages_0.42.tar.xz
 f18190b809571467f1702af2dbce4bee 8392 net optional openstack-meta-packages_0.42_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEoLGp81CJVhMOekJc1BatFaxrQ/4FAmrIxg4ACgkQ1BatFaxr
Q/4PjxAAnYyhISioR4IkUKqKvkYtSI/+m5fFjtJ+VG5C/rcbNhTGHoeVoo0M7Ur3
+bWdDOvNSTMHjo3Db+57Xz+0YAYrDK7EZrvfxPwV3SnQI9SaSbUSfPBPE2D3UXvq
OXmojj8FLCY/PZT9/XzPezPTD7CSZ9loBwQeH5cvOjHvGjH37esOySbQPpw7cMWt
p3taGyzfE0aCEjnz1Et+P0uB4uQMwz1+g+mmRf29KQDh9OujUkBsK3CDhsC2hLsj
V3ZY56yJHwtYQvcXMyrs8Htx+dkyi5/RMhK7iD0mpiLrNu5FMulEXfLPqYl4zLR5
GEsl8W6AyKMliB+ZJxGxHNvsbiThmd7g5Ni8vUmz76ulicG+vDEq9ZNpMNmT71e4
TbK7Sa9dkbB62U1A/fB8S9sVN6jwrA/ajomTu7yRiELEaBqsEiwbbRD9HjNuO25P
In9CA4BaOLcDuW+vjNPbL6nkcv6c+EaUCHbJKxuGSLE9SjJ/JMHDQb3+1g+5vGZf
m6dHGac2pxdI542AxISyx5awS6LHg9JiGqwWTc4aWw8uAqA7my6bnEPpz+oMwXwi
Ph1sxJMhuWbx0L6o5CDU3ZRUip65l/vwDKvzEFQt12YyL+NhbVTwZbXvrTfv8IQ3
i4FLud3jfVHiMI3Aes5UySJ2pL0uH0AnaaJ671LtJyK8IrzLHsM=
=8XQO
-----END PGP SIGNATURE-----