Showing headlines posted by dba477

RDO deployment bellow has been done via straightforward RDO Kilo packstack run demonstrates that Storage Node might work as traditional iSCSI Target Server and each Compute Node is actually iSCSI initiator client. Notice that Glance,Cinder,Swift Services are not running on Controller.

Post is actually step by step procedure of creating DVR system working with two external networks been built via flat network provider. Question which several times was raised up at ask.openstack.org, however was not addressed properly.

Test bellow is targeting two potential problems :- 1. Creating HAProxyKeepalived 3 Node Controller in RDO Mitaka with router supporting VRRP && DVR at a time per https://github.com/beekhof/osp-ha-deploy/blob/master/HA-keep... in regards of using DVR on Compute nodes. 2.Creating DVR system working with two flat external networks.

Post bellow is addressing the question when AIO RDO Liberty Node has to have external networks of VLAN type with predefined vlan tags. Straight forward packstack --allinone install doesn't allow to achieve desired network configuration. External network provider of vlan type appears to be required

It is actually an update for Neutron on RDO Liberty of original blog entry http://blog.aaronorosen.com/implementing-high-availability-i... . I only attempted to make post understandable for people with no knowledge how to access cloud VMs having just private IPs and highlighted Neutron Commands which are not commonly known and provide option to create floating IP working as VIP providing HA for a couple on Ubuntu 14.04 cloud instances

The correct name of this post is supposed to be "Nova and Neutron workflow && CLI for HAProxy/Keepalived 3 Node Controller RDO Liberty in an appropriate amount of detail". It follows up http://lxer.com/module/newswire/view/222164/index.html . Neutron work-flow on Controller is described including OVS flow rules on external brigge created by flat external network provider and eth0 external interface as VLAN OVS port of bridge br-eth0

As far as to my knowledge Cisco's schema has been implemented :- Keepalived, HAProxy,Galera for MySQL Manual install, at least 3 controller nodes. I just highlighted several steps which as I believe allowed me to bring this work to success.

Actually, setup down here was carefully tested in regards of Mitaka Milestone 1 which hopefully will allow to verify solution provided by Bug #1365473 Unable to create a router that's both HA and distributed. Delorean repos now are supposed to be rebuilt and ready for testing via RDO deployment in a week after each Mitaka Milestone

Posting bellow via straightforward RDO Liberty deployment demonstrates that Storage Node might work as traditional iSCSI Target Server and each Compute Node is actually iSCSI initiator client. This functionality is provided by tuning Cinder && Glance Services running on Storage Node.

Sample bellow (sic) demonstrates uninterrupted access, providing via HA Neutron router, to cloud VMs running on Compute node, when two installed Network Nodes node are swapping MASTER and BACKUP roles (as members of keepalived pair).

As advertised officially, in addition to the comprehensive OpenStack services, libraries and clients, this release also provides Packstack, a simple installer for proof-of-concept installations, as small as a single all-in-one box and RDO Manager an OpenStack deployment and management tool for production environments based on the OpenStack TripleO project.

This post is focused on verification of classic schema of Neutron workflow between qrouter and fip namespaces on Compute Nodes via distributed routers. Release of Openstack been tested was RDO Liberty RC2

Following bellow is supposed to test in multi node environment, Multiple external networks with a single L3 agent by Lars Kellogg-Stedman. However, current post contains an attempt to analyze and understand how traffic to/from external network flows through br-int when provider external networks has been involved

Posting is addressing question been asked at ask.openstack.org. Question : Can meta-data co-exist in qrouter and qdhcp namespace at the same time so that LANs without Routers involved can access meta-data ?

Why schema suggested by Benjamin Schmaus for RDO Juno in http://schmaustech.blogspot.com/2014/12/configuring-dvr-in-o... generates several errors on Liberty, which may be tracked down in reasonable time and finally brings to success, just silently fails on RDO Kilo taking away VXLAN tunnels forever. Posting bellow is supposed to address this issue.

Neutron DVR implements so called fip-namespace on every Compute Node where the VMs are running. So that VMs with FloatingIPs can forward the traffic to the External Network avoiding sending and receiving external data through VXLAN or GRE tunnels connecting them to Network Node (North-South Routing), wich is supposed to be a single point of failure for L3 routing in traditional configuration.

RDO Liberty (beta) passed 3 node deployment test : Controller+Network+Compute Configuration ML2&OVS&VXLAN. Regardless RH is mainly focused on RDO-Manager based Liberty deployments. I don't have desktop been able to run 6 VMs at a time, because I truly believe that it requires 8 CORE Intel CPU like Intel® Xeon® Processor E5-2690. On 4 CORE CPU like i7 it's just impossible . . .

Neutron DVR implements the fip-namespace on every Compute Node where the VMs are running. Thus VMs with FloatingIPs can forward the traffic to the External Network without routing it via Network Node.It also implements the L3 Routers across the Compute Nodes, so that tenants intra VM communication will occur without Network Node involvment.Neutron DVR provides the legacy SNAT behavior . . .

After upgrade to upstream version of openstack-puppet-modules-2015.1.9 procedure of RDO Kilo install on F22 significantly changed. Steps required to be undertaken on Controller follow below.

Posting bellow follows up http://redhatstackblog.redhat.com/2015/05/05/cpu-pinning-and... on RDO Kilo installed on Fedora 22 . After upgrade to upstream version of openstack-puppet-modules-2015.1.9 procedure of RDO Kilo install on F22 significantly changed. Details follow bellow