While in a best-practice deployment, each OpenStack project's services would live on a different machine, this is not always practical. For example, in small deployments there might be too few machines available, or a limited number of public IP addresses. Components from different OpenStack projects are not necessarily engineered to be able to be co-located, however many users report success with a variety of deployment scenarios.
The following is a series of pointers to be used when co-location of services from different OpenStack projects on the same machine is a must:
Ensure dependencies aren't in conflict. The OpenStack Continuous Integration team does attempt to ensure there is no conflict - so if you see issues during package installation, consider filing a bug.
Monitor your systems and ensure they are not overloaded. Some parts of OpenStack use a lot of CPU time (eg Swift Proxy Servers), while others are IO focused (eg Swift Object Server). Try to balance these so they complement each other.
Beware of security. Different parts of OpenStack assume different security models. For example, Swift assumes the storage nodes will be on a private network and does not provide additional security between nodes in the cluster.
Ensure the ports you are running the services on don't conflict. Most ports used by OpenStack are configurable.
