| opendevreview | Franco Mariotti proposed openstack/kolla-ansible master: Clarifies misleading error on ceilometer role`s precheck task https://review.opendev.org/c/openstack/kolla-ansible/+/876599 | 01:07 |
|---|---|---|
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: Revert "Revert "ansible: bump min to 2.13 and max to 2.14"" https://review.opendev.org/c/openstack/kolla-ansible/+/881018 | 07:06 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: systemd_worker: do not compare unit when restart policy is no https://review.opendev.org/c/openstack/kolla-ansible/+/883034 | 07:14 |
| mnasiadka | SvenKieske: this (https://review.opendev.org/c/openstack/kolla/+/882924) is still failing for upgrade jobs, can you have a look? | 07:26 |
| mnasiadka | and cinder is not happy in the service_token patch in k-a | 07:38 |
| SvenKieske | mnasiadka: looking now into it | 08:11 |
| opendevreview | Verification of a change to openstack/kolla master failed: mariadb: log bootstrap output to file https://review.opendev.org/c/openstack/kolla/+/882247 | 08:14 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: Revert "Revert "ansible: bump min to 2.13 and max to 2.14"" https://review.opendev.org/c/openstack/kolla-ansible/+/881018 | 08:21 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: Revert "Revert "ansible: bump min to 2.13 and max to 2.14"" https://review.opendev.org/c/openstack/kolla-ansible/+/881018 | 08:53 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: Revert "Revert "ansible: bump min to 2.13 and max to 2.14"" https://review.opendev.org/c/openstack/kolla-ansible/+/881018 | 09:11 |
| SvenKieske | can anyone remember jobs timing out on uploading logs to swift? | 09:23 |
| mnasiadka | it happens from time to time - you can only complain on #opendev ;-) | 09:29 |
| opendevreview | Michal Nasiadka proposed openstack/ansible-collection-kolla master: baremetal: remove warn: false https://review.opendev.org/c/openstack/ansible-collection-kolla/+/883053 | 09:36 |
| opendevreview | Michal Nasiadka proposed openstack/ansible-collection-kolla master: baremetal: rework firewalld check https://review.opendev.org/c/openstack/ansible-collection-kolla/+/883054 | 09:40 |
| opendevreview | Michal Nasiadka proposed openstack/ansible-collection-kolla master: baremetal: rework firewalld check https://review.opendev.org/c/openstack/ansible-collection-kolla/+/883054 | 09:49 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: Revert "Revert "ansible: bump min to 2.13 and max to 2.14"" https://review.opendev.org/c/openstack/kolla-ansible/+/881018 | 09:52 |
| SvenKieske | mnasiadka: could you point me in the right direction? where do I have to look to find the authentication configuration for the cli usage in our tests? | 09:58 |
| mnasiadka | we just source admin-openrc.sh if I remember correctly - just have a look in test-core-openstack.sh | 09:58 |
| SvenKieske | ah found it! yes, seems to be right | 10:01 |
| SvenKieske | mhm okay, so I would guesstimate that this can't have anything to do with the privs of the used user as the template uses just the keystone admin user.. | 10:04 |
| opendevreview | Verification of a change to openstack/kolla-ansible master failed: Fix Bash variable expansion issues in openrc file https://review.opendev.org/c/openstack/kolla-ansible/+/881469 | 11:05 |
| SvenKieske | mnasiadka: we do have a proper setup "service" project in our test env, don't we? I updated the service token change with some findings from the keystone logs..this is really weird.. I'll take a deeper look but I would be glad for more pointers more familiar with the test setup. | 12:31 |
| SvenKieske | *from people | 12:31 |
| SvenKieske | the thing is, keystone doesn't seem to be able to find any service project | 12:40 |
| * SvenKieske is digging into the code how this is supposed to work. | 12:41 | |
| BobZAnnapolis_ | folks, anyone know of a documentation page that exists that describes the EDR for the different databases ? Relations, field names, descriptions, etc. I'm looking for something more complete / documented than doing a "describe table". tia | 13:26 |
| SvenKieske | BobZAnnapolis: you're talking about the databaselayout of each openstack service? that would be a question for each respective project, I suppose. I personally don't know about any such thing. There might be something in the wiki from some design phases/blueprints. | 13:38 |
| spatel | I am trying to upgrade to zed but look like images are there in Quay.io - https://quay.io/repository/openstack.kolla/ubuntu-source-kolla-toolbox?tab=tags | 14:05 |
| spatel | Does that means, I have to build images myself? | 14:05 |
| spatel | oh wait they changed the tag in zeg? zed-ubuntu-jammy | 14:14 |
| rockey | spatel: it's highly recommended to utilize kolla to build your own images for production use | 14:30 |
| spatel | This is quick development environment to try out upgrade. I am downloading images from quay.io and pushing them to local repo. | 14:31 |
| mnasiadka | SvenKieske: I'm pretty sure the service project is there and we have service users for each service in the service project ;-) | 15:26 |
| mnasiadka | SvenKieske: maybe the CI failed with something mariadb related, I can have a look on Monday | 15:26 |
| SvenKieske | mhm, interesting, yeah, keystone can't even find keystone itself. good idea to look at the db, I'll see if I can find something there also. | 15:27 |
| mnasiadka | SvenKieske: but I think it needs reproducing on a local env with cinder unfortunately ;) | 15:41 |
| mnasiadka | Anyway, it's the high priority thing to fix right now | 15:42 |
| mnasiadka | spatel: we changed image naming since zed - see https://quay.io/repository/openstack.kolla/kolla-toolbox?tab=tags | 15:43 |
| SvenKieske | mhm, yeah might be. are you using devstack for that or what kind of setup do you use? | 15:49 |
| mnasiadka | kolla-ansible single node should be fine | 15:52 |
| mnasiadka | will have a look at it on Monday | 15:53 |
| mnasiadka | SvenKieske: basically https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html should be enough | 16:13 |
| mnasiadka | (to setup an all-in-one env quite quickly) | 16:13 |
| SvenKieske | sure, ty | 16:13 |
| spatel | mnasiadka Thanks!! i figured that tag name has been changed | 16:35 |
| spatel | mnasiadka I want to destroy just rabbitMQ on all 3 controller nodes in that case does this command will help? kolla-ansible -i multinode destroy -t rabbitmq | 16:36 |
| mnasiadka | no, destroy does not accept tags | 16:36 |
| spatel | oh!! | 16:39 |
| spatel | what is the quick way to destroy specific container from multiple nodes? | 16:40 |
| spatel | mnasiadka quick question, Do i need openstack_release: "zed-ubuntu-jammy" in global.yml? because when I add that tag it will appending that tab in existing tag like foobar:zed-ubuntu-jammyzed-ubuntu-jammy something like that | 16:44 |
| spatel | I have removed openstack_release: "zed-ubuntu-jammy" in global.yml and all works without error | 16:44 |
| mnasiadka | spatel: no, just zed | 16:44 |
| spatel | ohh | 16:44 |
| mmalchuk | spatel ansible overcloud -i /path/to/inventory -m ansible.builtin.shell -a "docker rm -f container_name" | 16:46 |
| spatel | what is overcloud here? | 16:48 |
| spatel | group name? | 16:48 |
| mnasiadka | SvenKieske: the same happens on a local env, but now I have some basis to work on :) | 16:48 |
| mmalchuk | spatel group name | 16:48 |
| spatel | Got it - $ ansible control -i multinode -m ansible.builtin.shell -a "docker stop horizon" | 16:49 |
| mmalchuk | spatel now You can use ad-hoc Ansible commands) | 16:49 |
| spatel | mmalchuk +1 | 16:50 |
| spatel | mmalchuk during upgrade process if I want to do piecemeal upgrade (each components one by one) in that case can I use kolla-ansible -i inventory upgrade -t rabbitmq | 16:51 |
| spatel | Assuming upgrade support tags | 16:52 |
| mmalchuk | spatel please refer documentation about upgrade procedure | 16:52 |
| SvenKieske | mnasiadka: hey you said you will look monday :P :D | 16:52 |
| spatel | mmalchuk I am reading here - https://docs.openstack.org/kolla-ansible/latest/user/operating-kolla.html#upgrade-procedure | 16:53 |
| spatel | Not seeing any section to do upgrade per components and what is the way to do in production | 16:53 |
| mnasiadka | SvenKieske: see point 2 in https://docs.openstack.org/cinder/ussuri/configuration/block-storage/service-token.html#troubleshooting | 16:55 |
| mmalchuk | spatel right | 16:55 |
| mnasiadka | SvenKieske: we're not setting service_token_roles, so the default is "service", and that's a nonexistent role (well, not granted to nova user - it has admin | 16:55 |
| mnasiadka | when I set service_token_roles = admin in cinder.conf, then it works | 16:55 |
| mmalchuk | spatel also You can check source code to be sure | 16:56 |
| spatel | mmalchuk so in 200 compute node cloud it will upgrade whole stack in single shot? | 16:56 |
| mnasiadka | sean-k-mooney: is there a problem if we set service_token_roles = admin and keep nova user only with admin role - or is it better to add the default "service" role to nova user? | 16:56 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: always add service_user section to nova.conf https://review.opendev.org/c/openstack/kolla-ansible/+/882893 | 16:58 |
| mmalchuk | spatel it should, rabbitmq role have upgrade task. make backups before doing this dangerous action | 16:58 |
| mnasiadka | I added service_token_roles = admin for now SvenKieske - let's sort it out on Monday ;) | 16:59 |
| spatel | mmalchuk I just gave you example as a rabbitmq but i would like to upgrade one components at a time to make sure not whole cloud blowup in single command | 17:00 |
| spatel | Day one upgrade all infra components, day two upgrade API nodes and Day 3 upgrade computes etc.. | 17:00 |
| mmalchuk | spatel interesting. from which version and to? | 17:02 |
| spatel | Yoga to Zed | 17:07 |
| spatel | for large environment you never know what could go wrong with single command | 17:08 |
| spatel | I like slow and steady approach | 17:08 |
| mmalchuk | spatel I have Xena cloud with around the same number of computes and I only planing upgrade to Zed | 17:11 |
| spatel | mmalchuk how are you planning to upgrade? that is what I am interested in | 17:12 |
| mmalchuk | spatel I'm only planning... and fear of broken cloud stops ne | 17:14 |
| SvenKieske | that sounds right; i debated that part in fact with sean but we thought the default should be sufficient :D | 17:16 |
| spatel | mmalchuk haha!!! | 17:17 |
| mnasiadka | SvenKieske: then maybe we should add the service role instead, but this time really on Monday :) | 17:17 |
| spatel | I will run some test in my lab to do piecemeal approach and see if its possible | 17:18 |
| mnasiadka | spatel: let us know how it went! | 17:18 |
| spatel | I will | 17:18 |
| mmalchuk | spatel create a blog and do records | 17:18 |
| spatel | sure!! why not | 17:18 |
| opendevreview | Dawud proposed openstack/kolla-ansible master: Use friendly prometheus instance labels https://review.opendev.org/c/openstack/kolla-ansible/+/876357 | 17:37 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible stable/wallaby: always add service_user section to nova.conf https://review.opendev.org/c/openstack/kolla-ansible/+/883017 | 19:28 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible stable/wallaby: always add service_user section to nova.conf https://review.opendev.org/c/openstack/kolla-ansible/+/883017 | 19:30 |
| opendevreview | Michal Nasiadka proposed openstack/kolla-ansible stable/wallaby: always add service_user section to nova.conf https://review.opendev.org/c/openstack/kolla-ansible/+/883017 | 19:32 |
| -opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be offline briefly for a patchlevel update, but should return to service in a few minutes | 20:41 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!