Open Stack

You can contact me offline. I would suggest neutron and I can send you my answerfile, more flexibility and going forward that’s pretty much the way to go. Nova will be depreciated as far as I know, 12-18 months.

 
On Jun 16, 2014, at 15:32, Eric Berg <eberg at rubensteintech.com> wrote:

> Thanks, Remo.
> 
> Are you saying that there's no pre-configuration of the network interfaces required for a packstack install?  I am using packstack.  My packstack file is below.
> 
> Regarding neutron, I banged on it for a week or two and it seemed like serious overkill for a config with a single control host and one or two compute hosts with no network host.  I want to route tenant traffic for each compute box separately.   Neutron just seems like way more trouble than its worth for a very small implementation.  I got it to work for an allinone install, but the move to multiple hosts left me frustrated and disgusted.  Plus, we're a small shop and the obtuse nature of neutron networking led me to decide that it would be irresponsible to implement our cloud     based on technology that was effectively unsupportable.  I'm sure neutron is just lovely if you have a team of network engineers available to support it.    The architecture that was requested of     me is to have two hosts that handle everything and fail over for one another.  We currently have one host running release 2.x for the past few years.  When I started down this path, that's what we     thought we'd be setting up.  Nova with flat networking is as close as I've been able to get to an architecture that uses few hosts, avoids the single point of failure network host and I could get it to work.
> 
> So, I'm still left with the question of how to pre-configure my network.  My approach again is to use my first nic (em1) with no ip, but as a member of the br100 bridge for primary tenant traffic.  The 2nd NIC will be used for mgmt/api and will get a standard IP and will reside on a separate private vlan.
> 
> We also want to have a back net which will carry traffic between, for example, the databases and the web servers, but which will not be accessible directly from the public network.  I think I can make that happen with another virtual network without too much problem.
> 
> Here's my packstack answers file.
> 
> [general]
> CONFIG_SSH_KEY=/root/.ssh/id_rsa.pub
> CONFIG_MYSQL_INSTALL=y
> CONFIG_GLANCE_INSTALL=y
> CONFIG_CINDER_INSTALL=y
> CONFIG_NOVA_INSTALL=y
> CONFIG_NEUTRON_INSTALL=n
> CONFIG_HORIZON_INSTALL=y
> CONFIG_SWIFT_INSTALL=y
> CONFIG_CEILOMETER_INSTALL=y
> CONFIG_HEAT_INSTALL=n
> CONFIG_CLIENT_INSTALL=y
> CONFIG_NTP_SERVERS=
> CONFIG_NAGIOS_INSTALL=y
> EXCLUDE_SERVERS=
> CONFIG_DEBUG_MODE=y
> CONFIG_VMWARE_BACKEND=n
> CONFIG_VCENTER_HOST=
> CONFIG_VCENTER_USER=
> CONFIG_VCENTER_PASSWORD=
> CONFIG_VCENTER_CLUSTER_NAME=
> CONFIG_MYSQL_HOST=192.168.0.37
> CONFIG_MYSQL_USER=root
> CONFIG_MYSQL_PW=qweqwe
> CONFIG_AMQP_SERVER=rabbitmq
> CONFIG_AMQP_HOST=192.168.0.37
> CONFIG_AMQP_ENABLE_SSL=n
> CONFIG_AMQP_ENABLE_AUTH=n
> CONFIG_AMQP_NSS_CERTDB_PW=qweqwe
> CONFIG_AMQP_SSL_PORT=5671
> CONFIG_AMQP_SSL_CERT_FILE=/etc/pki/tls/certs/amqp_selfcert.pem
> CONFIG_AMQP_SSL_KEY_FILE=/etc/pki/tls/private/amqp_selfkey.pem
> CONFIG_AMQP_SSL_SELF_SIGNED=y
> CONFIG_AMQP_AUTH_USER=amqp_user
> CONFIG_AMQP_AUTH_PASSWORD=10c8e15e798e494d
> CONFIG_KEYSTONE_HOST=192.168.0.37
> CONFIG_KEYSTONE_DB_PW=qweqwe
> CONFIG_KEYSTONE_ADMIN_TOKEN=03bf026a2b9d42ec8556d07729740993
> CONFIG_KEYSTONE_ADMIN_PW=qweqwe
> CONFIG_KEYSTONE_DEMO_PW=qweqwe
> CONFIG_KEYSTONE_TOKEN_FORMAT=PKI
> CONFIG_GLANCE_HOST=192.168.0.37
> CONFIG_GLANCE_DB_PW=qweqwe
> CONFIG_GLANCE_KS_PW=qweqwe
> CONFIG_CINDER_HOST=192.168.0.37
> CONFIG_CINDER_DB_PW=qweqwe
> CONFIG_CINDER_KS_PW=qweqwe
> CONFIG_CINDER_BACKEND=lvm
> CONFIG_CINDER_VOLUMES_CREATE=y
> CONFIG_CINDER_VOLUMES_SIZE=20G
> CONFIG_CINDER_GLUSTER_MOUNTS=
> CONFIG_CINDER_NFS_MOUNTS=
> CONFIG_NOVA_API_HOST=192.168.0.37
> CONFIG_NOVA_CERT_HOST=192.168.0.37
> CONFIG_NOVA_VNCPROXY_HOST=192.168.0.37
> CONFIG_NOVA_COMPUTE_HOSTS=192.168.0.21
> CONFIG_NOVA_CONDUCTOR_HOST=192.168.0.37
> CONFIG_NOVA_DB_PW=qweqwe
> CONFIG_NOVA_KS_PW=qweqwe
> CONFIG_NOVA_SCHED_HOST=192.168.0.37
> CONFIG_NOVA_SCHED_CPU_ALLOC_RATIO=16.0
> CONFIG_NOVA_SCHED_RAM_ALLOC_RATIO=1.5
> CONFIG_NOVA_COMPUTE_PRIVIF=em2
> CONFIG_NOVA_NETWORK_HOSTS=192.168.0.21
> CONFIG_NOVA_NETWORK_MANAGER=nova.network.manager.FlatDHCPManager
> CONFIG_NOVA_NETWORK_PUBIF=em1
> CONFIG_NOVA_NETWORK_PRIVIF=em2
> CONFIG_NOVA_NETWORK_FIXEDRANGE=10.0.0.0/22
> CONFIG_NOVA_NETWORK_FLOATRANGE=192.168.20.0/24
> CONFIG_NOVA_NETWORK_DEFAULTFLOATINGPOOL=nova
> CONFIG_NOVA_NETWORK_AUTOASSIGNFLOATINGIP=n
> CONFIG_NOVA_NETWORK_VLAN_START=100
> CONFIG_NOVA_NETWORK_NUMBER=1
> CONFIG_NOVA_NETWORK_SIZE=254
> CONFIG_NEUTRON_SERVER_HOST=192.168.0.37
> CONFIG_NEUTRON_KS_PW=qweqwe
> CONFIG_NEUTRON_DB_PW=qweqwe
> CONFIG_NEUTRON_L3_HOSTS=192.168.0.37
> CONFIG_NEUTRON_L3_EXT_BRIDGE=br-ex
> CONFIG_NEUTRON_DHCP_HOSTS=192.168.0.37
> CONFIG_NEUTRON_LBAAS_HOSTS=
> CONFIG_NEUTRON_L2_PLUGIN=openvswitch
> CONFIG_NEUTRON_METADATA_HOSTS=192.168.0.37
> CONFIG_NEUTRON_METADATA_PW=qweqwe
> CONFIG_NEUTRON_ML2_TYPE_DRIVERS=local
> CONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPES=local
> CONFIG_NEUTRON_ML2_MECHANISM_DRIVERS=openvswitch
> CONFIG_NEUTRON_ML2_FLAT_NETWORKS=*
> CONFIG_NEUTRON_ML2_VLAN_RANGES=
> CONFIG_NEUTRON_ML2_TUNNEL_ID_RANGES=
> CONFIG_NEUTRON_ML2_VXLAN_GROUP=
> CONFIG_NEUTRON_ML2_VNI_RANGES=
> CONFIG_NEUTRON_L2_AGENT=openvswitch
> CONFIG_NEUTRON_LB_TENANT_NETWORK_TYPE=local
> CONFIG_NEUTRON_LB_VLAN_RANGES=
> CONFIG_NEUTRON_LB_INTERFACE_MAPPINGS=
> CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE=vxlan
> CONFIG_NEUTRON_OVS_VLAN_RANGES=physnet1
> CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=physnet1:br-ex
> CONFIG_NEUTRON_OVS_BRIDGE_IFACES=
> CONFIG_NEUTRON_OVS_TUNNEL_RANGES=1:3000
> CONFIG_NEUTRON_OVS_TUNNEL_IF=eth1
> CONFIG_NEUTRON_OVS_VXLAN_UDP_PORT=4789
> CONFIG_OSCLIENT_HOST=192.168.0.37
> CONFIG_HORIZON_HOST=192.168.0.37
> CONFIG_HORIZON_SSL=n
> CONFIG_SSL_CERT=
> CONFIG_SSL_KEY=
> CONFIG_SWIFT_PROXY_HOSTS=192.168.0.37
> CONFIG_SWIFT_KS_PW=qweqwe
> CONFIG_SWIFT_STORAGE_HOSTS=192.168.0.37
> CONFIG_SWIFT_STORAGE_ZONES=1
> CONFIG_SWIFT_STORAGE_REPLICAS=1
> CONFIG_SWIFT_STORAGE_FSTYPE=ext4
> CONFIG_SWIFT_HASH=606f14f8a4474af3
> CONFIG_SWIFT_STORAGE_SIZE=2G
> CONFIG_PROVISION_DEMO=n
> CONFIG_PROVISION_TEMPEST=n
> CONFIG_PROVISION_DEMO_FLOATRANGE=192.168.20.0/24
> CONFIG_PROVISION_TEMPEST_REPO_URI=https://github.com/openstack/tempest.git
> CONFIG_PROVISION_TEMPEST_REPO_REVISION=master
> CONFIG_PROVISION_ALL_IN_ONE_OVS_BRIDGE=n
> CONFIG_HEAT_HOST=192.168.0.37
> CONFIG_HEAT_DB_PW=qweqwe
> CONFIG_HEAT_AUTH_ENC_KEY=6282b556fce5463a
> CONFIG_HEAT_KS_PW=qweqwe
> CONFIG_HEAT_CLOUDWATCH_INSTALL=n
> CONFIG_HEAT_CFN_INSTALL=n
> CONFIG_HEAT_CLOUDWATCH_HOST=192.168.0.37
> CONFIG_HEAT_CFN_HOST=192.168.0.37
> CONFIG_CEILOMETER_HOST=192.168.0.37
> CONFIG_CEILOMETER_SECRET=6393b48eeeea415e
> CONFIG_CEILOMETER_KS_PW=qweqwe
> CONFIG_MONGODB_HOST=192.168.0.37
> CONFIG_NAGIOS_HOST=192.168.0.37
> CONFIG_NAGIOS_PW=qweqwe
> CONFIG_USE_EPEL=y
> CONFIG_REPO=
> CONFIG_RH_USER=
> CONFIG_RH_PW=
> CONFIG_RH_BETA_REPO=n
> CONFIG_SATELLITE_URL=
> CONFIG_SATELLITE_USER=
> CONFIG_SATELLITE_PW=
> CONFIG_SATELLITE_AKEY=
> CONFIG_SATELLITE_CACERT=
> CONFIG_SATELLITE_PROFILE=
> CONFIG_SATELLITE_FLAGS=
> CONFIG_SATELLITE_PROXY=
> CONFIG_SATELLITE_PROXY_USER=
> CONFIG_SATELLITE_PROXY_PW=
> 
> 
> 
> On 6/16/14, 4:33 PM, Remo Mattei wrote:
>> Hi Eric, 
>> I would use packstack it works really well for what you need to do. Any reasons why you want Nova Network vs Neutron?
>> 
>> The only thing you need is make sure your two nics are up and running. 
>> 
>> 
>> On Jun 16, 2014, at 13:19, Eric Berg <eberg at rubensteintech.com> wrote:
>> 
>>> I'm trying to implement this architecture:
>>> RDO on CentOS 6.5 installed via packstack
>>> nova networking.  Not neutron.
>>> flat network
>>> one control host (single NIC)
>>> initially, one compute host with another to be added ( 2 NICs)
>>> My internal office network is 192.168.0.0/16, and 192.168.20.0/24 is dedicated to the floating IPs for our OpenStack cloud
>>> Much of the network documentation leaves out on which host the specific configs are to be done, so it's not clear to me how to prepare my hosts for openstack installation.  There are indications that some nics should have no IP address assigned but rather be part of a bridge which has the IP address, but the docs are vague about that and different architectures seem to need different configs.
>>> Packstack may be complicating things -- at least in my mind -- since I'm not sure what network configuration puppet is implementing via packstack and what I have to do before the install.
>>> My primary question is, "How do I set up my network before installation?"
>>> My Ethernet interfaces are em1 and em2.  Here's my understanding at this point:  
>>> I will use em2 as the management interface, which I should configure with an IP address (already has this address...just leave this interface as is) 
>>> The em1 interface is the one that will interface with my VMs via a bridge (br100), so that interface should not have an IP address, because the bridge will.
>>> What parts of this have to be set up before the installation?
>>> Thanks!
>>> Eric
>>> 
> 
> !DSPAM:1,539f723d145462095171086!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140616/af16153d/attachment.html>