<div><div dir="auto">For the records, I’m actually working on a fairly large overhaul of our Openstack services deployement using Kolla-Ansible. We’re leveraging kolla-ansible to as smoothly as possible migrate all ou legacy architecture to a shiny new using exactly the same topology as described upper (Using cumulus/calico etc).</div></div><div dir="auto"><br></div><div dir="auto">One of the new services that we try to provide with such method is Octavia.</div><div dir="auto"><br></div><div dir="auto">As I too faced some trouble I find them not that hard to solve either by reading carefully the current APIs ref, guides available and source code or by asking for help right here.</div><div dir="auto"><br></div><div dir="auto">People responding to octavia’s questions are IMHO blazing fast and really clear and add great details about internals mechanisms which is really appreciated.</div><div dir="auto"><br></div><div dir="auto">As I’ve almost finish our own deployment I had noted almost all pitfalls that I faced and which part of the documentation that was missing.</div><div dir="auto"><br></div><div dir="auto">I’ll finish my deployment and test and redact a clean (and I hope as complet as possible) documentation as I feel it’s something really needed.</div><div dir="auto"><br></div><div dir="auto">On a side note regarding CA and SSL I had an issue that I solved by correctly rebuilding my amphora. Another tip and trick here is to use Barbican when possible as it really help a lot.</div><div dir="auto"><br></div><div dir="auto">I hope it can help anyone else willing to use Octavia as I truly think this service is a huge addition to Openstack and its gaining more and more momentum since the Pike/Queens releases.</div><div><br><div class="gmail_quote"><div dir="ltr">Le mar. 23 oct. 2018 à 19:49, Michael Johnson <<a href="mailto:johnsomor@gmail.com">johnsomor@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am still catching up on e-mail from the weekend.<br>
<br>
There are a lot of different options for how to implement the<br>
lb-mgmt-network for the controller<->amphora communication. I can't<br>
talk to what options Kolla provides, but I can talk to how Octavia<br>
works.<br>
<br>
One thing to note on the lb-mgmt-net issue, if you can setup routes<br>
such that the controllers can reach the IP addresses used for the<br>
lb-mgmt-net, and that the amphora can reach the controllers, Octavia<br>
can run with a routed lb-mgmt-net setup. There is no L2 requirement<br>
between the controllers and the amphora instances.<br>
<br>
Michael<br>
<br>
On Tue, Oct 23, 2018 at 9:57 AM Erik McCormick<br>
<<a href="mailto:emccormick@cirrusseven.com" target="_blank">emccormick@cirrusseven.com</a>> wrote:<br>
><br>
> So in your other email you said asked if there was a guide for<br>
> deploying it with Kolla ansible...<br>
><br>
> Oh boy. No there's not. I don't know if you've seen my recent mails on<br>
> Octavia, but I am going through this deployment process with<br>
> kolla-ansible right now and it is lacking in a few areas.<br>
><br>
> If you plan to use different CA certificates for client and server in<br>
> Octavia, you'll need to add that into the playbook. Presently it only<br>
> copies over ca_01.pem, cacert.key, and client.pem and uses them for<br>
> everything. I was completely unable to make it work with only one CA<br>
> as I got some SSL errors. It passes gate though, so I aasume it must<br>
> work? I dunno.<br>
><br>
> Networking comments and a really messy kolla-ansible / octavia how-to below...<br>
><br>
> On Tue, Oct 23, 2018 at 10:09 AM Florian Engelmann<br>
> <<a href="mailto:florian.engelmann@everyware.ch" target="_blank">florian.engelmann@everyware.ch</a>> wrote:<br>
> ><br>
> > Am 10/23/18 um 3:20 PM schrieb Erik McCormick:<br>
> > > On Tue, Oct 23, 2018 at 7:53 AM Florian Engelmann<br>
> > > <<a href="mailto:florian.engelmann@everyware.ch" target="_blank">florian.engelmann@everyware.ch</a>> wrote:<br>
> > >><br>
> > >> Hi,<br>
> > >><br>
> > >> We did test Octavia with Pike (DVR deployment) and everything was<br>
> > >> working right our of the box. We changed our underlay network to a<br>
> > >> Layer3 spine-leaf network now and did not deploy DVR as we don't wanted<br>
> > >> to have that much cables in a rack.<br>
> > >><br>
> > >> Octavia is not working right now as the lb-mgmt-net does not exist on<br>
> > >> the compute nodes nor does a br-ex.<br>
> > >><br>
> > >> The control nodes running<br>
> > >><br>
> > >> octavia_worker<br>
> > >> octavia_housekeeping<br>
> > >> octavia_health_manager<br>
> > >> octavia_api<br>
> > >><br>
> > >> and as far as I understood octavia_worker, octavia_housekeeping and<br>
> > >> octavia_health_manager have to talk to the amphora instances. But the<br>
> > >> control nodes are spread over three different leafs. So each control<br>
> > >> node in a different L2 domain.<br>
> > >><br>
> > >> So the question is how to deploy a lb-mgmt-net network in our setup?<br>
> > >><br>
> > >> - Compute nodes have no "stretched" L2 domain<br>
> > >> - Control nodes, compute nodes and network nodes are in L3 networks like<br>
> > >> api, storage, ...<br>
> > >> - Only network nodes are connected to a L2 domain (with a separated NIC)<br>
> > >> providing the "public" network<br>
> > >><br>
> > > You'll need to add a new bridge to your compute nodes and create a<br>
> > > provider network associated with that bridge. In my setup this is<br>
> > > simply a flat network tied to a tagged interface. In your case it<br>
> > > probably makes more sense to make a new VNI and create a vxlan<br>
> > > provider network. The routing in your switches should handle the rest.<br>
> ><br>
> > Ok that's what I try right now. But I don't get how to setup something<br>
> > like a VxLAN provider Network. I thought only vlan and flat is supported<br>
> > as provider network? I guess it is not possible to use the tunnel<br>
> > interface that is used for tenant networks?<br>
> > So I have to create a separated VxLAN on the control and compute nodes like:<br>
> ><br>
> > # ip link add vxoctavia type vxlan id 42 dstport 4790 group 239.1.1.1<br>
> > dev vlan3535 ttl 5<br>
> > # ip addr add <a href="http://172.16.1.11/20" rel="noreferrer" target="_blank">172.16.1.11/20</a> dev vxoctavia<br>
> > # ip link set vxoctavia up<br>
> ><br>
> > and use it like a flat provider network, true?<br>
> ><br>
> This is a fine way of doing things, but it's only half the battle.<br>
> You'll need to add a bridge on the compute nodes and bind it to that<br>
> new interface. Something like this if you're using openvswitch:<br>
><br>
> docker exec openvswitch_db<br>
> /usr/local/bin/kolla_ensure_openvswitch_configured br-mgmt vxoctavia<br>
><br>
> Also you'll want to remove the IP address from that interface as it's<br>
> going to be a bridge. Think of it like your public (br-ex) interface<br>
> on your network nodes.<br>
><br>
> From there you'll need to update the bridge mappings via kolla<br>
> overrides. This would usually be in /etc/kolla/config/neutron. Create<br>
> a subdirectory for your compute inventory group and create an<br>
> ml2_conf.ini there. So you'd end up with something like:<br>
><br>
> [root@kolla-deploy ~]# cat /etc/kolla/config/neutron/compute/ml2_conf.ini<br>
> [ml2_type_flat]<br>
> flat_networks = mgmt-net<br>
><br>
> [ovs]<br>
> bridge_mappings = mgmt-net:br-mgmt<br>
><br>
> run kolla-ansible --tags neutron reconfigure to push out the new<br>
> configs. Note that there is a bug where the neutron containers may not<br>
> restart after the change, so you'll probably need to do a 'docker<br>
> container restart neutron_openvswitch_agent' on each compute node.<br>
><br>
> At this point, you'll need to create the provider network in the admin<br>
> project like:<br>
><br>
> openstack network create --provider-network-type flat<br>
> --provider-physical-network mgmt-net lb-mgmt-net<br>
><br>
> And then create a normal subnet attached to this network with some<br>
> largeish address scope. I wouldn't use <a href="http://172.16.0.0/16" rel="noreferrer" target="_blank">172.16.0.0/16</a> because docker<br>
> uses that by default. I'm not sure if it matters since the network<br>
> traffic will be isolated on a bridge, but it makes me paranoid so I<br>
> avoided it.<br>
><br>
> For your controllers, I think you can just let everything function off<br>
> your api interface since you're routing in your spines. Set up a<br>
> gateway somewhere from that lb-mgmt network and save yourself the<br>
> complication of adding an interface to your controllers. If you choose<br>
> to use a separate interface on your controllers, you'll need to make<br>
> sure this patch is in your kolla-ansible install or cherry pick it.<br>
><br>
> <a href="https://github.com/openstack/kolla-ansible/commit/0b6e401c4fdb9aa4ff87d0bfd4b25c91b86e0d60#diff-6c871f6865aecf0057a5b5f677ae7d59" rel="noreferrer" target="_blank">https://github.com/openstack/kolla-ansible/commit/0b6e401c4fdb9aa4ff87d0bfd4b25c91b86e0d60#diff-6c871f6865aecf0057a5b5f677ae7d59</a><br>
><br>
> I don't think that's been backported at all, so unless you're running<br>
> off master you'll need to go get it.<br>
><br>
> From here on out, the regular Octavia instruction should serve you.<br>
> Create a flavor, Create a security group, and capture their UUIDs<br>
> along with the UUID of the provider network you made. Override them in<br>
> globals.yml with:<br>
><br>
> octavia_amp_boot_network_list: <uuid><br>
> octavia_amp_secgroup_list: <uuid><br>
> octavia_amp_flavor_id: <uuid><br>
><br>
> This is all from my scattered notes and bad memory. Hopefully it makes<br>
> sense. Corrections welcome.<br>
><br>
> -Erik<br>
><br>
><br>
><br>
> ><br>
> ><br>
> > ><br>
> > > -Erik<br>
> > >><br>
> > >> All the best,<br>
> > >> Florian<br>
> > >> _______________________________________________<br>
> > >> OpenStack-operators mailing list<br>
> > >> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
> > >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
><br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div></div>