This class does not provision any resources, it only does error checking. The error checking is restrictive and not very valuable, and it hinders reusability. This patch removes the class and all similar error checking not contained in the class.
The openstack::setup::router and openstack::setup::sharednetwork classes only create two networks and one router with very little configuration options. This change moves the network data into the example hiera files and uses create_resources on a hash to create as many networks, subnets, and routers are the user wants. We move this into openstack::profile::neutron::router since these resources will always reside on the network node.
Having a class that sets up a single hard-coded image is not very useful, except for demos. This change moves the image data into the example hiera files and uses create_resources on a hash of data to create as many images as the user wants. We move this into openstack::profile::glance::api since now a one-line function does not need its own class.
Profiles should be self-contained as much as possible. Removing the dependency relationship between the firewallchain resources and the repository classes causes no ill effects, plus it simplifies the code because it is no longer conditional on osfamily.
We declare the neutron::server class on non-controller nodes in order to manage some configs needed by agents and routers. We only turn the neutron-server service on if the node is a controller. Previously, we avoided installing the package if the node was not a controller. However, on Ubuntu, the neutron::plugin::ml2 class needs to manage /etc/default/neutron-server, which comes from the neutron-server package. Also on Ubuntu, the neutron::server class tries to manage the neutron-server. Even if it is ensuring it is stopped, it fails if there is no startup script for the service. This should be better architected to avoid these issues, but the quick fix for now is to add the package back onto the nodes by using the default package_ensure parameter for the neutron::server class. We still ensure that the service is stopped.
Currently this module only supports using the default eventlet-based web server for API services. This is only sustainable in a production environment if using another web proxy in front of it, which is not included in this module. This patch adds the ability to turn on the keystone::wsgi::apache class and use the keystone API with Apache. Other notes: - SSL is hard-coded to be turned off, since this module doesn't support SSL yet. We will fix this later. - Since the neutron::server::notifications class was not contained in the openstack::common::neutron class, the nova_admin_tenant_id_setter may try to authenticate against the keystone API before the HTTP service is turned on. We contain it within the openstack::common::neutron class with anchors so that the ordering of the profile classes is effective. - The keystone_use_httpd parameter was added to the openstack base class. It attempts a hiera lookup, but defaults to false, which signifies that it should not set up Apache. - The allinone role declares some setup classes in addition to profiles. The cirros setup involves making a keystone API call, which will fail if keystone isn't set up yet. We add a relationship between the keystone profile and the cirros setup following the example of the ceilometer API ordering.
Without this patch, the neutron::agents::ml2::ovs class was bundled into the openstack::common::ovs class, which was included in the neutron server profile. Since the OVS agent is not required to run on the neutron server, include it only where it's actually needed. To accomplish this, this patch reorganizes the openstack::common::ovs class into two classes, openstack::common::ml2 for the ml2 plugin class, and openstack::common::ml2::ovs for the ml2 ovs agent, and includes openstack::common::ml2 where openstack::common::ovs used to be, but only includes the openstack::common::ml2::ovs class where needed. Closes #107
The defined function is not able to detect whether any resources have been collected in order to conditionally turn on the swift-proxy service once the ring resources exist, which was the intention of this section. The defined function instead is only able to check if the type is loadable, and always returned true since the ring resources are valid types. This commit removes that section since it was just a noop.
The Puppet Labs has multiple providers, so it is more accessible for trying out the examples. We're pinning the version to 1.0.0 because 1.0.1 seems to have issues with its networking interfaces. Additionally, this vagrant box comes with firewalld enabled and many firewall rules. Firewalld responds to iptables-save which confuses the firewall iptables provider and causes errors on the first round of puppet runs, even if disabling firewalld is puppet's first change. Because of this, we add a command to the deployment script to stop firewalld before running puppet so that puppet succeeds on the first run.
Without this patch, the yum_refresh class was only added for CentOS/RedHat systems and not Fedora systems because it was being included in the same class as epel. Since yum_refresh has nothing to do with epel and since yum_refresh is applicable to Fedora, this patch moves the yum_refresh inclusion to the repo class and does ordering within the yum_refresh class instead of for just the rdo repo.
The public_address, internal_address, and admin_address parameters were removed in keystone at 29b68753316c7ceeb0a6ece98b686c216968a3dd. This commit replaces our usage of those parameters with the new *_url parameters, using the old default scheme, port, and path to maintain current functionality. Eventually this should be replaced by configurable URL parameters. However, the address parameters are scattered throughout the module, care needs to be taken to address this with consistency. This patch fixes it just enough so that it compiles when using the master branch of the modules.