| qwebirc68751 | Hi Guys, I'm trying to install Openstack Environment, Zed version - to train upgrade process with system upgrades to Bobcat (with upgrade to 2023.1 in the middle). | 00:02 |
|---|---|---|
| qwebirc68751 | Playebook setup-hosts and setup-infrastructure went without any errors. I've checked database cluster - up and running with 3 node's. | 00:03 |
| qwebirc68751 | When I run setup-openstack it ends on task: openstack.osa.db_setup : Create database for service with error: failed: [dev-os-controller01_keystone_container-493f8d15 -> dev-os-controller01_utility_container-0319acf7(10.13.17.94)] (item={'name': 'keystone', 'users': [{'username': 'keystone', 'password': 'XXX'}]}) => {"ansible_loop_var": "item", "changed": false, "item": {"name": "keystone", "users": [{"password": "XXX", " | 00:04 |
| qwebirc68751 | "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: Packet sequence number wrong - got 1 expected 2"}. | 00:04 |
| qwebirc68751 | Any ides what can be wrong? | 00:05 |
| qwebirc68751 | I can see file my.cnf (/root/.my.cnf) on utility container and it contains "client" section with host, user, password | 00:06 |
| qwebirc68751 | You can she full traceback here: https://owncloud.ohnsorge.pl/index.php/s/VDwYHzLkIqSalM0/download | 00:12 |
| qwebirc68751 | see* | 00:12 |
| noonedeadpunk | good morning | 08:28 |
| jrosser | morning | 08:35 |
| jrosser | there are still a couple of outstanding patches in the ops repo for capi https://review.opendev.org/c/openstack/openstack-ansible-ops/+/906363 | 09:58 |
| noonedeadpunk | so for capi it seems that biggest questions is octavia and skipping tempest | 11:00 |
| noonedeadpunk | and I also promised to look at docs in ops... | 11:00 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible master: Allow general purpose resources to be created during setup-openstack https://review.opendev.org/c/openstack/openstack-ansible/+/909411 | 11:01 |
| jrosser | ^ this is part 1 for skipping tempest | 11:04 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible-os_magnum master: Add job to test Vexxhost cluster API driver https://review.opendev.org/c/openstack/openstack-ansible-os_magnum/+/905199 | 11:05 |
| jrosser | and in turn it needs https://review.opendev.org/c/openstack/openstack-ansible/+/908766 | 11:05 |
| jrosser | noonedeadpunk: so the only thing i would like to point out on https://review.opendev.org/c/openstack/openstack-ansible/+/909411 is that there is kind of duplication between openstack-common-* and openstack-user-* variables | 11:06 |
| jrosser | and if this is valid/correct thing to do or not | 11:07 |
| noonedeadpunk | so when temepst wil try to create a public network, it should just pass with OK? | 11:07 |
| jrosser | to distinguish between things that created 'inline' during setup-openstack.yml from openstack-common-* | 11:07 |
| jrosser | and things that get created when you call playbooks/openstack-resource.yml directly from openstack-user-* | 11:07 |
| jrosser | i note that there is no way to run a single playbook to just create openstack-common-* things, and i'm not totally happy with that | 11:08 |
| jrosser | so about tempest, if i set tempest_run=false then it will never try to create that network | 11:10 |
| jrosser | hopefully as you say it will just be 'OK' and not do anything otherwise | 11:10 |
| jrosser | then we have the option to totally remove public network creation from the tempest role, as that feels kind of odd place to do it | 11:11 |
| noonedeadpunk | Well, it also probably depends a bit, but potentially yes... | 11:13 |
| jrosser | andrewbonney: would be interested if you have a view on my comment here https://review.opendev.org/c/openstack/openstack-ansible/+/909411 | 11:13 |
| noonedeadpunk | for me - more options to define is better - might get handy under some conditions | 11:17 |
| noonedeadpunk | about not being able to create all resources in same run - mostly I do find that tricky when you depend on "output" of the role before defining next set | 11:18 |
| noonedeadpunk | And also there's in fact no output.... | 11:18 |
| andrewbonney | A separate playbook does sound useful. I do often find myself commenting bits of setup-openstack, so that would avoid further need to do so | 11:27 |
| jrosser | currently there is no running of playbooks/openstack-resources as part of setup-everything | 11:35 |
| jrosser | so thats why i've introduced a new set of vars to for automatically created things, vs operator chooses when to run openstack-resources.yml | 11:36 |
| noonedeadpunk | yeah, makes sense | 11:36 |
| noonedeadpunk | and quite handy as well | 11:36 |
| jrosser | ok let me refactor this a bit and make a standalone playbook just like the others | 11:37 |
| noonedeadpunk | but um. we already have a standalone playbook? | 11:44 |
| noonedeadpunk | I guess I misunderstood a bit | 11:44 |
| jrosser | ok, so should i just call playbooks/openstack-resources.yml directly from setup-openstack before tempest? | 11:44 |
| jrosser | that would be simpler, but was not what happened with the original patch introducing that | 11:45 |
| noonedeadpunk | oh, ok, now I guess got what you mean | 11:48 |
| jrosser | yeah so i kind of 'wrap' openstack-resources.yml right now but inside setup-openstack.yml | 11:49 |
| noonedeadpunk | yeah, so having 2 same playbooks is not ideal indeed | 11:49 |
| jrosser | so i could move that wrapping to setup-common-resources.yml which then includes openstack-resources but using different vars | 11:50 |
| jrosser | btw vars: on import_playbook does indeed seem to work | 11:50 |
| noonedeadpunk | or do just combine user_resources with common_resources... | 11:52 |
| noonedeadpunk | But that might have really interesting consequences | 11:52 |
| jrosser | so whole reason for this complexity is your original patch didnt automatically run openstack_resources | 11:53 |
| jrosser | and so i feel there is some important reason for that | 11:53 |
| noonedeadpunk | no, not at all | 11:53 |
| noonedeadpunk | I don't know in fact | 11:53 |
| jrosser | as where/when to run it is maybe dependant on situation | 11:53 |
| jrosser | so if we are happy to always run it, then this becomes all much simpler | 11:54 |
| noonedeadpunk | I did not put much thinking originally and decided that we can iterate on usecases. | 11:54 |
| noonedeadpunk | I guess there were some nits in a role, like images being always downloaded | 11:54 |
| noonedeadpunk | So I guess I'm thinking about 2 options now - just use 2 tasks of openstack-resources.yml playbook, and adding conditions there | 11:55 |
| noonedeadpunk | ie when: openstack_common_identity or openstack_common_compute or openstack_common_network... | 11:56 |
| noonedeadpunk | or, do combine them... | 11:56 |
| noonedeadpunk | As having 2 playbooks probably overkill? | 11:56 |
| noonedeadpunk | dunno | 11:57 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Disable RPC configuration for Neutron with OVN in CI https://review.opendev.org/c/openstack/openstack-ansible/+/908521 | 15:24 |
| ThiagoCMC | Hey folks! I just noticed that `ceph-ansible` is deprecated, so sad. I always loved to deploy Ceph together with OpenStack using the `openstack-ansible` CLI in one go, everything from Ubuntu repositories (no Ceph repos, only Ubuntu UCA). I have an outdated deployment based on Ubuntu 20.04 (Victoria and Ceph 15). What's the plan for Ubuntu 24.04? Will OSA still support deploying Ceph using its CLI? I do not want Docker. | 15:48 |
| admin1 | ThiagoCMC hey | 15:50 |
| ThiagoCMC | Heeey! :-D | 15:50 |
| admin1 | you can use cephadm to import that and then use cephadm to control the old one, and then use ceph as external in osa | 15:50 |
| admin1 | import old ceph -> cephadm and then continue it further as independent via cephadm .. then give the conf and keys and configure osa to take the values from the config directly | 15:51 |
| ThiagoCMC | Hmmm, ok! Got it. | 15:51 |
| noonedeadpunk | but you'd still have docker... and centos in docker | 15:52 |
| ThiagoCMC | Ewwww... | 15:52 |
| ThiagoCMC | I see Ceph is pushing container-only deployments, I honestly don't like that. | 15:52 |
| opendevreview | Merged openstack/openstack-ansible-ops master: Add playbook to run functional test of magnum capi driver https://review.opendev.org/c/openstack/openstack-ansible-ops/+/906361 | 15:54 |
| noonedeadpunk | I mainly don't like part of higher vendor lock that I'd want to | 15:55 |
| noonedeadpunk | as you kind also depend on quay.io, as dockerhub doesn't have all versions/updates | 15:56 |
| noonedeadpunk | and then centos is not very reliable lately according to what we see in CI | 15:56 |
| noonedeadpunk | but we don't have any plans now for replacement | 15:57 |
| opendevreview | Merged openstack/openstack-ansible-os_swift master: Remove nobarrier mount option from docs https://review.opendev.org/c/openstack/openstack-ansible-os_swift/+/909233 | 16:01 |
| ThiagoCMC | Daammnn... lol - After a quick research, I see that Ubuntu Charms can deploy the latest Ceph (Charmed Ceph) on bare metal (MaaS). Perhaps there's a way! | 16:04 |
| jrosser | ceph-ansible does still work for reef | 16:07 |
| jrosser | regardless of the deprecation notice | 16:07 |
| jrosser | and the official upgrade path for a ceph installation is to use the package manager, and we proved thats completely OK here for Q->R | 16:08 |
| noonedeadpunk | and supposedly ubuntu will still package ceph in their UCA... | 16:10 |
| jrosser | what we did was an in-place upgrade from Q->R on 20.04 | 16:11 |
| jrosser | then we re-pxe each node in turn and re-deploy R on 22.04 with ceph-ansible | 16:11 |
| jrosser | all straightforward and no surprised | 16:11 |
| jrosser | *surprises | 16:11 |
| ThiagoCMC | But Ceph is packaged back in Debian... I'm seeing Debian dropping that work. | 16:14 |
| ThiagoCMC | *I'm NOT seeing* | 16:14 |
| noonedeadpunk | https://wiki.ubuntu.com/OpenStack/CloudArchive#Ceph_and_the_UCA | 16:16 |
| noonedeadpunk | but yes, Debian is packaging as well for sure | 16:16 |
| ThiagoCMC | BTW, I do have Ceph OSDs running in LXD containers: https://discuss.linuxcontainers.org/t/ceph-osd-fails-to-start-in-lxd-container-after-upgrading-host-from-ubuntu-20-04-to-22-04/17290 - But as you guys can see here in my post, it's challenging. Each kernel upgrade can potentially break the thing, so I want to go metal only. Or LXD/Incus if it's stable across upgrades (but no Docker for me). | 16:19 |
| admin1 | so you want to do your own and face the same situation again vs running whats tested and supported | 16:29 |
| admin1 | if the community is moving towards docker and is supporting it, why not use it | 16:29 |
| admin1 | why complicate your life further ? | 16:29 |
| noonedeadpunk | it depends on the prespective I guess. As it could be simplifying your life in a long run migrating out of the docker afterwards | 16:42 |
| ThiagoCMC | That's a very good question, admin1! lol - I just don't want any CentOS/Docker in my pristine Deb-based environment. :-D | 16:43 |
| noonedeadpunk | I guess I've seen 3 or 4 changes of deployment tooling for Ceph specifically when one was superceeding another without really good migration path. Like cephadm is the first having it | 16:43 |
| ThiagoCMC | Back in 2019~2020, I thought LXD was quite cool, because the containers behave like VMs. | 16:43 |
| noonedeadpunk | But for me personally it feels slightly as a vendor lock in the future, when some blue giant will back of on community efforts | 16:44 |
| ThiagoCMC | Yeah... | 16:44 |
| ThiagoCMC | So, then, challenges related to LXD started to popup when upgrading the host... So, now, I want a new deployment from scratch, and copy the data, but Ceph Ansible was deprecated... hehe | 16:45 |
| ThiagoCMC | Anyway, sounds like time to learn it again! | 16:45 |
| ThiagoCMC | But, please, no Docker/CentOS garbage. :-P | 16:45 |
| noonedeadpunk | I actually also having same doubts for new deployment - if to use ceph-ansible and migrate later or get on cephadm which doesn't look super appealing... | 16:46 |
| noonedeadpunk | and yes, centos is very big factor against cephadm | 16:46 |
| ThiagoCMC | Same feelings! | 16:46 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_neutron master: Add variable to control distributed FIP choice https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/909470 | 17:04 |
| opendevreview | Merged openstack/openstack-ansible-os_neutron master: Fix permissions for rootwrap files https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/909034 | 17:56 |
| ThiagoCMC | BTW, the `ceph-ansible` `stable-8.0` branch is still being developed. | 18:12 |
| *** NeilHanlon is now known as nhanlon | 19:00 | |
| *** nhanlon is now known as NeilHanlon | 19:02 | |
| admin1 | i run ubuntu and cephadm .. not had any issues so far | 20:13 |
| admin1 | management, logging, automation, monitoring etc is all included | 20:13 |
| admin1 | nice gui .. it feels like running an appliance | 20:14 |
| ThiagoCMC | Meh, I want Debian packages, shared libraries. | 20:26 |
| ThiagoCMC | In the Debian pipeline we trust! :-P | 20:27 |
| ThiagoCMC | Check this out: https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/ | 20:28 |
| ThiagoCMC | I want a container with `systemd`, and `apt-get`. Not some weird CentOS blob (in my Ubuntu) which I can't upgrade when I need/want. | 20:30 |
| opendevreview | James Denton proposed openstack/openstack-ansible master: [Feature] Add skyline deployment capability https://review.opendev.org/c/openstack/openstack-ansible/+/859446 | 21:36 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!