| opendevreview | Yadnesh Kulkarni proposed openstack/puppet-tripleo stable/wallaby: Ceilometer: Add support for oslo.cache parameters https://review.opendev.org/c/openstack/puppet-tripleo/+/898202 | 07:17 |
|---|---|---|
| planzo | Hello all, is this channel the right place to ask a specific, but probably for you easy to answer question regarding blacklist deployments that is not documented? | 07:19 |
| planzo | I've obviously no chance to get this information on another way, so I was hoping someone of you could help me with that :( | 07:19 |
| opendevreview | Yadnesh Kulkarni proposed openstack/tripleo-heat-templates stable/wallaby: Ceilometer: Enable oslo.cache backend https://review.opendev.org/c/openstack/tripleo-heat-templates/+/898203 | 07:28 |
| opendevreview | Yadnesh Kulkarni proposed openstack/tripleo-heat-templates stable/wallaby: Ceilometer: Enable oslo.cache backend https://review.opendev.org/c/openstack/tripleo-heat-templates/+/898203 | 07:32 |
| xbezdick[m] | planzo what you need? | 08:43 |
| planzo | I would like to upscale the compute nodes without include the controller nodes. | 08:44 |
| planzo | The reason for the question is explained quite simple. The overcloud deployment takes about 12 hours only handling the 3 controllers. Why this is taking so long is of secondary importance to me. In my opinion, the controller nodes do not need to be touched at all during upscaling. Unfortunately, it is not documented anywhere whether this is possible or not. | 08:50 |
| xbezdick[m] | it shouldn't take 12hours to start with | 09:28 |
| xbezdick[m] | sadly I think there are multiple things needed on ctrl side - you do not need full deployment but /etc/hosts has to be updated and probably keys might be pushed to ctrl | 09:29 |
| xbezdick[m] | tldr I think you have to run full deployment but it shouldn't take 12hours | 09:29 |
| xbezdick[m] | also what version? | 09:29 |
| planzo | It's based on Ussuri. | 09:32 |
| planzo | We put a lot of effort into research and answer the question why it takes so long. A major problem seems to be that the deployment spends a lot of time recreating the qrouter and dnsmasqdhcp containers which are about 1500 per ctlr node. | 09:34 |
| planzo | At a specific time, we gave up to try to fix that issue. | 09:34 |
| planzo | In the earlier days, I was operating an ubuntu-plain-based openstack environment and scaling that was just simply installing a new compute node, putting all necessary configurations of nova etc. on it and it "calls" to mysql and rabbitmq. after this, it was simply a part of the cluster and nothing more has had to be done on the controllers | 09:37 |
| planzo | But yes, this might be different when using tripleo, but I couldn't get any answer to this until now | 09:38 |
| xbezdick[m] | the part about rereating qrouter and dnsmasqdhcp sounds like there is triggered restart of neutron containers which should not be happening at all | 09:44 |
| xbezdick[m] | I would consider jumping to wallaby for starters | 09:45 |
| planzo | Thank you very for your recommondation and answering my question! | 10:12 |
| opendevreview | Sergii Golovatiuk proposed openstack/tripleo-heat-templates stable/wallaby: Remove VDO package https://review.opendev.org/c/openstack/tripleo-heat-templates/+/898220 | 11:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!