*** rpittau|afk is now known as rpittau | 07:08 | |
*** arxcruz is now known as arxcruz|off | 09:05 | |
jnamdar | hi all | 09:05 |
---|---|---|
jnamdar | I have a working stack with a few nodes that I setup with openstack ansible a while ago, and I'm looking to install an additional service | 09:06 |
jnamdar | (which is Octavia.) Can I just run the os-octavia-install playbook? | 09:07 |
jnamdar | Or do I need to deploy the whole thing from scratch | 09:07 |
jnamdar | (I'm running on Stein) | 09:07 |
opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Set bullseye jobs to voting https://review.opendev.org/c/openstack/openstack-ansible/+/805172 | 09:33 |
noonedeadpunk | jnamdar: you need to define group in openstack_user_config, create containers and then run os-octavia-install | 09:34 |
noonedeadpunk | But you alse need to solve networking thing | 09:34 |
noonedeadpunk | I believe https://docs.openstack.org/openstack-ansible-os_octavia/latest/configure-octavia.html#openstack-ansible-deployment is pretty accurate to follow | 09:35 |
jnamdar | thanks | 09:37 |
opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-galera_server stable/wallaby: Partial Revert "Bump MariaDB version to 10.5.9" https://review.opendev.org/c/openstack/openstack-ansible-galera_server/+/805135 | 09:48 |
opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-galera_server stable/wallaby: Partial Revert "Bump MariaDB version to 10.5.9" https://review.opendev.org/c/openstack/openstack-ansible-galera_server/+/805135 | 09:49 |
noonedeadpunk | I wonder what way we should follow for managing LB endpoints. Currently we use mostly task https://opendev.org/openstack/openstack-ansible/src/branch/master/playbooks/common-tasks/haproxy-endpoint-manage.yml | 10:17 |
noonedeadpunk | But there's another "smarter" way which is usage of https://github.com/logan2211/ansible-haproxy-endpoints | 10:17 |
noonedeadpunk | But tbh, I think I prefer our old way rather then this role. Because while it's kind of cool to disable service on haproxy only during it's restart, but I bet there could be some cases when service starts malfunction even before restart (ie weird policy or rootwrap overrides) | 10:19 |
noonedeadpunk | So IMO it's safer to disable backend before we start messing up with service itself | 10:19 |
noonedeadpunk | also it feels that right now we disable whole controller on haproxy during galera restart, since backend will be just ommited https://opendev.org/openstack/openstack-ansible/src/branch/master/playbooks/galera-install.yml#L47-L49 -> https://github.com/logan2211/ansible-haproxy-endpoints/blob/master/handlers/main.yml#L19 | 10:21 |
noonedeadpunk | Also that include is easier to maintain and it's more readable rather then magic `Manage LB` handler... | 10:22 |
noonedeadpunk | Which I bet would be pretty hard to properly maintain... | 10:23 |
opendevreview | Merged openstack/openstack-ansible master: Add guide for distribution upgrades to docs https://review.opendev.org/c/openstack/openstack-ansible/+/804875 | 10:54 |
opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible stable/wallaby: Add guide for distribution upgrades to docs https://review.opendev.org/c/openstack/openstack-ansible/+/805140 | 11:10 |
opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible stable/victoria: Add guide for distribution upgrades to docs https://review.opendev.org/c/openstack/openstack-ansible/+/805141 | 11:10 |
opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Add serial execution to all playbooks https://review.opendev.org/c/openstack/openstack-ansible/+/805188 | 11:32 |
opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Move galera tasks to pre_tasks https://review.opendev.org/c/openstack/openstack-ansible/+/805193 | 12:04 |
noonedeadpunk | andrewbonney: when did you re-created LXC containers during OS upgrade and re-joined galera cluster? | 12:28 |
noonedeadpunk | As after OS upgrade containers remain running previous one anyway? | 12:28 |
noonedeadpunk | ah, ok, you was re-installing OS | 12:33 |
andrewbonney | Yeah, in-place upgrades can be a bit messy so we always start from fresh hosts | 12:34 |
noonedeadpunk | Thinking about it now, it might be really faster to re-setup.... | 12:44 |
noonedeadpunk | Just was thinking about upgrade to preserve galera data to reduce syncing time | 12:45 |
noonedeadpunk | esp with PXE boot | 12:46 |
andrewbonney | Yeah. Unfortunately the xinetd script makes it look to haproxy like the whole cluster is down while that happens, so if you have a lot of data it's a pain | 12:48 |
noonedeadpunk | oh, wait, but it's looking for `wsrep_local_state`? So if you disable haproxy backend it should be fine? | 12:50 |
andrewbonney | The trouble is the primary changes state when it becomes a donor to the freshly installed instance | 12:55 |
andrewbonney | I've been meaning to experiment with the script but haven't got round to it yet | 12:55 |
andrewbonney | The 'available_when_donor' option in https://github.com/olafz/percona-clustercheck/blob/master/clustercheck#L67 is interesting | 12:58 |
opendevreview | Merged openstack/openstack-ansible-galera_server master: Update galera to 10.6.4 https://review.opendev.org/c/openstack/openstack-ansible-galera_server/+/804370 | 12:58 |
jnamdar | I have to say the octavia config doc is tough to read lol, I'm afraid my networking level is not enough | 13:09 |
*** frenzy_friday is now known as erbot | 13:13 | |
*** erbot is now known as frenzy_friday | 13:15 | |
spatel | jnamdar what do you looking for octavia? | 13:20 |
jnamdar | spatel: I'm looking to install it so I can launch some Rally tests against it | 13:21 |
jnamdar | like deploying some load balancers and such | 13:21 |
spatel | so what is the issue related networking? | 13:22 |
spatel | i know its little complicated but once you know flow its super easy | 13:22 |
spatel | i tried my way to simplify it in my blog https://satishdotpatel.github.io/openstack-ansible-octavia/ | 13:23 |
jnamdar | spatel: if I understand the doc correctly I have to add a new bridge on my controllers | 13:27 |
spatel | yes br-lbaas | 13:28 |
jnamdar | but then I don't know what to choose between a flat or vlan network | 13:29 |
jnamdar | I know I already have a few networks entries for my existing openstack install (storage, vlan, vxlan, mgmt) | 13:30 |
jnamdar | Can I just create the bridge and add a flat typed network entry in my openstack_user_config.yml ? | 13:31 |
jnamdar | I'll take a look at your article thanks :) | 13:32 |
spatel | jnamdar is this production? | 13:39 |
spatel | yes you need to add br-lbaas which will map with octavia container | 13:40 |
spatel | you can see i added br-lbaas in my doc in openstack_user_config.yml | 13:40 |
spatel | - network: | 13:40 |
spatel | container_bridge: "br-lbaas" | 13:40 |
spatel | container_type: "veth" | 13:40 |
spatel | i would say try this in LAB box first to get hold of it | 13:41 |
spatel | I am running my octavia in production using this method of networking | 13:42 |
jnamdar | yeah I'll try that thx | 13:50 |
jnamdar | nah it isn't prod :) | 13:50 |
spatel | jnamdar that is good | 14:14 |
spatel | mostly all my openstack lab running inside VMware so its very easy to create private switches and VLAN in VMware to simulate production | 14:15 |
jnamdar | spatel: in the user_variables.yml, what does the arg octavia_provider_network_name mean ? | 14:39 |
jnamdar | Are you referring to your br-vlan bridge net_name from the openstack_user_config ? | 14:40 |
spatel | vlan | 14:40 |
spatel | that is default OSA use to map br-vlan with vlan | 14:40 |
spatel | if you look at my config i have the same variables | 14:41 |
jnamdar | ok I see. I think I didn't use the default name tho. My net_name is "provider-flat" for the br-vlan bridge | 14:41 |
jnamdar | did you host your full config files from the blog somewhere so I can compare maybe? | 14:42 |
spatel | no i didn't.. | 14:48 |
spatel | if you are using different interface name then you can adjust according | 14:49 |
jnamdar | yeah my config differs from the default. I have only one br-vlan bridge which is of type flat | 14:49 |
jnamdar | maybe I should not use a lbaas bridge of type vlan then lol | 14:51 |
jnamdar | I should probably do this I guess https://docs.openstack.org/openstack-ansible-os_octavia/latest/configure-octavia.html#flat-networking-scenario | 14:51 |
jnamdar | instead of your config | 14:51 |
opendevreview | Merged openstack/openstack-ansible master: Bump master branch https://review.opendev.org/c/openstack/openstack-ansible/+/801510 | 14:56 |
opendevreview | Merged openstack/openstack-ansible master: Set doc jobs to voting https://review.opendev.org/c/openstack/openstack-ansible/+/804891 | 14:56 |
spatel | jnamdar sure... we are running large production so flat not going to work for me | 15:16 |
spatel | you can use whatever better for you bottom line is amphora vm should be able to talk to Octavia controller, no matter what you use.. | 15:17 |
*** rpittau is now known as rpittau|afk | 15:51 | |
*** sshnaidm is now known as sshnaidm|afk | 16:09 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!