- update keystone endpoints/user on boot (to avoid problems caused by,
e.g., a stale password or invalid endpoint urls)
- require GLANCE_DB_PASSWORD and GLANCE_KEYSTONE_PASSWORD in the
environment, since we start multiple containers
Change-Id: I31214b81280ed34409f92e79003c1116d5737d2e
Previously, the glance-api start script would use the container
IP instead of the proxy IP for the public url when creating the
keystone endpoint. This causes keystone to provide an unreachable
IP within the public url and other OS services are unable to
connect to the public url.
Change-Id: I44befc84a90f59d535a951ee81aaff0fa1ba952d
Previously the glance-base script did not configure the registry
host IP. This causes API to try connecting to registry on
localhost. Since registry is bound to MY_IP, api is unable to
connect to registry. This change adds support for the glance-base
script to configure the registry_host parameter in api.conf to
MY_IP.
Change-Id: I1c711ff8aa95abec5ca306f03bd7e0a3883ca578
- run "yum update" after installing RDO repository (to ensure we get any
package updates from this repository)
- "yum clean" after the "yum update" to prevent yum cache from being
baked into the image
Change-Id: Id897fd85214855bb08f7e16da4bbdf07b821d991
when booting the keystone container with an existing database, make sure
to update credentials for admin user and replace existing keystone
endpoint in the service catalog.
Change-Id: I2c66d75210ef7ba5a96077eea15a8c564e99f662
The image location for rabbitmq was incorrectly pointing at Lars
private repository. Change it to point to the global kollaglue repo.
Change-Id: Ib4fd84db9410fa7057730ff74be2acc0babfa438
Also, fixed up environment variable to use RABBITMQ_NODE_PORT, which is
what RabbitMQ expects (http://www.rabbitmq.com/configure.html).
Implements: blueprint kube-rabbitmq-container
Change-Id: Iacc2ea5d3c4a002e6920ed17cb21733a0cbd8d21
This should get us a working nova-compute. Once rabbitmq is operational
we can further debug and implement this container.
Change-Id: I0768b9f33bc43748f4e08da0edc111d669895cc8
- glance was using wrong var name for admin_password
- also missing "\" in several places, breaking multi-line crudini
commands.
- glance was using wrong tenant name
- in the registry container, glance-manage appears to reference
glance-api.conf
- the glance.json config file was not spawning a registry container
Change-Id: I280d1db3ed576988f2bf29ea665e1922a37f8752
This renames the keystone services so that they are named by function,
rather than port number (which would be confusing if they were running
on a different port).
Change-Id: Ibb0263a133c28a104563df431870a9effe584012
This patch updates all the json files that reference the mariadb service
variables to ues the new names.
Labelling things foo-master crept into this repository from the
kubernetes guestbook example (which has redis-master and redis-slaves).
We're not running clustered software at the moment so these labels are
unnecessary.
Change-Id: I229d04c89aa13cb6cc2e1c33a0a7b21e1c6e9caa
Labelling things foo-master crept into this repository from the
kubernetes guestbook example (which has redis-master and redis-slaves).
We're not running clustered software at the moment so these labels are
unnecessary.
Change-Id: Ibf4cb2b005cc57bcb11e298dd5109cfe309c9ec3
Let's get that quickly so we can add a gate. There was some respacing
along the way (used http://jsonlint.com)
Change-Id: Id18b9f9757306cf3f06e6221a21a9f600db1bd2e
This image configures haproxy to forward connections for all available
kubernetes services. It is meant to be run alongside other contains in
a kubernetes pod to provide access to "remote" services at a consistent
address so that keystone api endpoints can be configured in a sane
fashion.
Change-Id: Ic923c6a772f1bdf36b97b05a1d04de9e5b841ddd
this patch introduces the "crux" [1] tool for creating keystone
users, services, and endpoints in an idempotent fashion. E.g., to
create a user that doesn't exist:
$ crux user-create -n lars -t lars -p secret
creating new tenant
created tenant lars (d74cec5023c4428da533066bb11943db)
creating new user lars
created user lars (adf2c2d92e894a3d90a403c5885f192e)
And performing the same operation a second time:
$ crux user-create -n lars -t lars -p secret
using existing tenant lars (d74cec5023c4428da533066bb11943db)
using existing user lars (adf2c2d92e894a3d90a403c5885f192e)
The behavior is similar for creating keystone endpoints.
[1]: https://github.com/larsks/crux
Change-Id: I694e0c1bdcdde595e1af2ee8ef5d0f239a9ad4cd
we use openssl in many of our start scripts for password generation, so
openssl should probably be part of the base image.
Change-Id: I893adfa3b7d17249b6814fc161e6f3f1696d8cd6
