Age | Commit message (Collapse) | Author |
|
The use of chef was never complete, had isses with updating binary
database files and had a cumbersome implementation. Since we are using
Ansible in meta-overc we are dropping the use of chef here and will
look to being at par with meta-overc by using Ansible if/when we get
time to look at runtime configuration in meta-cloud-services.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
This class provides a framework for recipes(packages) to register
their configuration files with the deploychef package. This class
works together with the deploychef package. This implementation
makes it possible for the deploychef package, with the help of
chef-solo, to recreate registered configuration files at run-time.
Only services that inherit this class and register their configuration
files are re-configurable at run-time; and by configurable, we mean to
make chefsolo templates out of their configuration files and to be aware
of the list of daemons that need to be killed/started at run-time.
Therefore, openstackchef class requires the recipes/classes inheriting
it to advertise their configuration files, list of start/stop daemons
and finally a special callback function when necessary.
In order to avoid duplication of common placeholders and
substitution across the various recipes inheriting this class,
we keep a dictionary of common placeholders and substitutions,
but rely on the recipes to define the values these placeholders take
at run-time.
See the description at the top of the class files (openstackchef.bbclass
and openstackchef_inc.bbclass ) for more details.
This class makes chef-solo template files out of the configuration
files exposed to it by the recipes.
The resulting templates are stored at
/opt/deploychef/cookbooks/openstack/templates/default.
on the resulting rootfs.
It also creates a file containing a set of chef-solo default template
values known as attributes in chef-solo world. The default values are
provided by the recipes and classes inheriting this class.
The chefsolo attributes file is stored at
/opt/deploychef/cookbooks/openstack/attributes/default.rb
at the end of rootfs creation process.
At run-time, the deploychef package whose package files are stored
at '/opt/deploychef', makes a call to chef-solo.
Chef-solo in turn uses the attributes and templates files to overwrite
the configuration files for services like neutron, nova, swift, etc..
that registered configuration files with openstackchef class
at build time. See accompanying documentation for further explanation.
Signed-off-by: Mustapha Lansana <Mustapha.Lansana@windriver.com>
|
|
This patch set configures an apache vhost server on port 8081 which will
serve as the main authentication method and documents the change in
README.keystone.
Signed-off-by: Liam R. Howlett <Liam.Howlett@WindRiver.com>
|
|
This README covers general trove setup in OpenStack.
Signed-off-by: Liam R. Howlett <Liam.Howlett@WindRiver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Add a README file pertaining to the openldap/keystone/pam usage.
Signed-off-by: Amy Fong <amy.fong@windriver.com>
|
|
Signed-off-by: Vu Tran <vu.tran@windriver.com>
|
|
The metadata service is working as the following:
- metadata is being served by nova-api on controller at port 8775.
- VM instance requests metadata by 169.254.169.254 (eg, curl http://169.254.169.254/latest/meta-data)
- metadata request comes to neutron-ns-metadata-proxy on controller in dhcp network name space.
- neutron-ns-metadata-proxy forwards the request to neutron-metadata-agent through a unix domain socket (/var/lib/neutron/metadata_proxy).
- neutron-metadata-agent sends the request to nova-api on port 8775 to be serviced.
To support metadata service, neutron-ns-metadata-proxy is baked into the controller image. Also neutron-metadata-agent startup script
(/etc/init.d/neutron-metadata-agent) and config file (/etc/neutron/metadata_agent.ini) are added to start up metadata agent at system
initialization. dhcp_agent.ini and nova.conf are updated as well.
A README.metadata is added in the Documentation/ directory.
Signed-off-by: Andy Ning <andy.ning@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
cirros 0.3.0 has a bug which ignores classless static routes passed by
dhcp option 121. This static route is needed for the instance to access
metadata service from 169.254.169.254. 0.3.2 has this bug fixed.
Details about this bug can be found at: https://bugs.launchpad.net/cirros/+bug/1190372
Updated documents that reference specific version of cirros as well.
Note: 0.3.2 download URI (SRC_URI) has been changed from "https://launchpad.net/cirros/trunk" to "http://download.cirros-cloud.net", since cirros binary downloads are all in the new URI.
Signed-off-by: Andy Ning <andy.ning@windriver.com>
|
|
By default cinder-backup driver is swift. To test
ceph cinder-backup driver, the backup_driver in
cinder.conf must be set to ceph. Update README.ceph-openstack
to reflect this.
Also change "$" to "#" for test steps which are not commands.
Signed-off-by: Vu Tran <vu.tran@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Using Barbican with Keystone authentication has some known
problems. Specifically, the problme is that Keystone now uses PKI
tokens, which are too long for the Barbican protocol to handle in
its current configuration. This patch delivers a readme file to
document these issues for the end-user.
Signed-off-by: Keith Holman <Keith.Holman@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Add documentation for testing swift, ceph, heat.
Create a script and instructions on a script that launches a controller
and a specified number of compute nodes.
Signed-off-by: Amy Fong <amy.fong@windriver.com>
|