| *** mhen_ is now known as mhen | 01:57 | |
| mijou | Hi. I just upgraded to Magnum Antelope (from Yoga). The upgrade was successful but since then Magnum reports a keystone client error with every attempt to update status of existing clusters or to create a new one (resulting in a failure to generate cluster certificate). Any trivial reason for this? | 10:47 |
|---|---|---|
| int33h | Morning with keystone 25.0.0 i seem to have some issues doing db_sync , sqlalchemy.exc.ProgrammingError: (pymysql.err.ProgrammingError) (1146, "Table 'keystone.project' doesn't exist") | 11:42 |
| int33h | after script is run the table is there but it feels like something is done in the wrong order | 11:43 |
| frickler | int33h: is that with a fresh installation or after an upgrade? if the latter, what was the previous and the initial version of keystone? | 12:06 |
| int33h | frickler: its a fresh install of ubuntu 24.04 so its the ubuntu packages | 12:09 |
| int33h | completly fresh lab cluster so i can tear it up and down | 12:10 |
| int33h | was stuck for a day trying to get ceph running before that (seems noone realy have tested those parts of 24.04 seems a little strange for a lts :P ) | 12:11 |
| frickler | int33h: oh, so that's with python 3.12 which is also mostly untested upstream. ubuntu has been pretty optimistic with this I think. I suggest to open a bug report at https://bugs.launchpad.net/ubuntu/+source/keystone | 12:16 |
| frickler | int33h: also, yes, faking a non-existing ceph release is even more optimistic IMHO | 12:16 |
| int33h | frickler: yea i had to grab source packets from ceph and recompile cephadmlib and manualy put it in place before i got ceph running (and disable apparmour) | 12:42 |
| int33h | frickler: i put in a bug report, i suspect noone has even tried to install openstack on this before they launced 24.04 | 12:51 |
| int33h | feels rushed | 12:51 |
| frickler | int33h: just being curious, why are you rushing to use 24.04? I mean, there's a reason LTS upgrades aren't enabled until roughly 24.04.1 is out | 12:55 |
| int33h | im in the middle of evaluating openstack to change from vmware and i was in the middle so i figured might as well test | 12:56 |
| int33h | not worried about stability at this stage and evaluation is going to take months anyway | 12:57 |
| int33h | didnt expect it to be this broken though :P | 12:57 |
| int33h | I created all my deployment scripts for 22.04 before 24.04 was released | 12:57 |
| frickler | so you are creating your own deployment tooling? | 12:58 |
| int33h | yea at this stage at least, need to understand all components before i run stuff like this in production | 12:58 |
| int33h | and all the automated deployments was to much black magic | 12:58 |
| int33h | and since im probably going to tear this setup down multiple times i created bash scripts to automate it all | 12:59 |
| int33h | its a mess atm but just about functional :P https://github.com/int0x21/openstack-generator/tree/master | 13:00 |
| frickler | hmm, some may call it black magic, others call it concentrated experience from doing years of deployments. so even if you don't use it in the end, I'd suggest to at least look at what kolla and openstack-ansible do and learn from it | 13:00 |
| int33h | yea i used openstack-ansible before | 13:01 |
| int33h | but when i ran into trouble i was to lost | 13:01 |
| int33h | So im just doing this to understand everything atm | 13:01 |
| int33h | and when i do that i might use openstack-ansible | 13:01 |
| int33h | im undecided though how il run it if it gets good enough for production, having comeplete control over tooling has its benefits for production | 13:03 |
| int33h | my setup is pretty small, i have just a bit over 500 vm:s and some few kubernetes clusters | 13:05 |
| jrosser_ | int33h: if you run into difficulty with openstack-ansible please ask in the #openstack-ansible IRC | 18:05 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!