March 2024 - openstack-discuss - lists.openstack.org

pdb in uwsgi
by Gk Gk 30 Mar '24

30 Mar '24

Hi, I am trying to insert pdb.set_trace() in the file " https://opendev.org/openstack/placement/src/branch/master/placement/objects…" for debugging purposes. But when I manually start the placement service using this command "/openstack/venvs/uwsgi-27.3.0-python3/bin/uwsgi --autoload --ini /etc/uwsgi/placement-api.ini --honour-stdin", it is running as normal but not giving the pdb prompt when launching a nova boot command elsewhere. Is this a uwsgi pdb bug ? Thanks Y.G

2 2

Re: Please Help To Setup Bumblebee VDI project based on DevStack
by Matthew Swigart 29 Mar '24

29 Mar '24

Hi Manuel, Thank you for your kind response. And yes, I fixed my previous issue and was able to access the Django Admin site like you shared a screenshot. Thank you for sharing that.🥰 Also, I contacted Andy and I'm in the same boat with him in the Matrix Element chat app. I've been contacting your former Freibug Univerisity colleagues from several months ago through Matrix Element room, Dirk, Michael Scherle, etc. They are really supportive. 👍 I'm also planning to collaborate on the project: https://github.com/OpenSourceVDI/osvdi . So this is the pre-development step for me So at least I want to try to test this bumblebee VDI based on DevStack on my local first, but Andy has also never tested the bumblebee on Devstack yet. I'm a bit sorry to Freiburg colleagues since they are already experienced in this step and they are forwarding to develop VDI that can support 3D rendering so I don't want to take time from them and want to support them as soon as possible after I pass through this step. For now, I stuck the one issue to create VDI. The issue is when I creating VDI, I got this issue. [image: image.png] I guess there is a problem with setting up the security group. I ran the *setup-openstack.sh* script by setting *CIDR=192.168.174.0/24 <http://192.168.174.0/24>* and setting the *OS_SECGROUPS=bumblebee_desktops* . I'm not sure I did correctly. Could you please let me know *what the would be CIDR value in the setup-openstack.sh and OS_SECGROUPS in the env file*? Let me attach some of my current configuration screenshots for references. Networks: [image: image.png] Security Groups: [image: image.png] bumblebee-desktops security group detail: [image: image.png] Security Group and keypair values: [image: image.png] bumblebee-desktop Security Group detail: [image: image.png] Env file: [image: image.png] I'd appreciate it if you could kindly reply to my email again. Please keep in touch. Much appreciated. Matthew On Thu, Mar 28, 2024 at 5:58 AM Manuel Bentele < development(a)manuel-bentele.de> wrote: > Hi Matthew, > > I fixed the above issue. The issue was happening because when trying to > create an instance through the nova client, input > parameters(security_groups and key_name) were empty. > > Nice to hear that you were able to solve the problem. At some code > locations, Bumblebee could still have better error handling ;) > > I quickly set up a fresh instance of Bumblebee and can't reproduce your > Django admin site access problem. If I use the default settings from the > Docker compose .env file and log in with the admin account, an 'Admin' > button appears in the menu bar: > > If you then click on the 'Admin' button, the Django admin site will load: > > There you can then graphically edit the corresponding objects from the > Bumblebee data model. For example, here is the mask for changing the > Ubuntu Jammy desktop type if you click on 'Desktop types' and then 'jammy': > > You can now do the same for the volumes or other objects. Why access to > the Django admin site doesn't work for you is a mystery to me. The same > also applies to the security groups. So far I have only ever assigned one > security group. Perhaps there is still an error due to a bug in the > Bumblebee logic if several security groups are specified. > > Anyway, I am also fully available on the weekends. I joined in OpenStack > VDI room Matrix element. (https://matrix.to/#/#opensource-vdi:matrix.org) > So hopefully we can discuss more detail through that room. > > Interesting, I haven't heard of that yet. Oh I see that my former > colleagues are also active there. I started this project back then: > https://github.com/OpenSourceVDI/osvdi. And now it seems that the project > is making visible progress. > > In the meantime, I no longer have anything to do with the VDI topic due to > another job. I just saw your question on the mailing list and thought I > could help. I have dealt with Bumblebee in the past and was also in > contact with Andy Botting. He is one of the main developers of Bumblebee and > reads the OpenStack mailing list from time to time. He is always happy to > receive further support for Bumblebee from the community and their > feedback. If you have specific questions, you can also contact him > directly: Andy Botting <andy(a)andybotting.com>. Nevertheless, you can also > ask my former colleagues from the University of Freiburg in the Matrix > room. I put their email addresses in the CC. They can help you too. > > Regards, > Manuel > > On 26.03.24 07:37, Matthew Swigart wrote: > > Hi Manuel, > > I fixed the above issue. The issue was happening because when trying to > create an instance through the nova client, input > parameters(security_groups and key_name) were empty. So I created a new > keypair and added keyname to env, And then I got the security group list by > running the "openstack security group list" command. > [image: image.png] > So I set "bumblebee-desktops" to OS_SECGROUPS in the env file, but I got > this issue -Unable to find security_group with name or id > 'bumblebee-desktops' > [image: image.png] > Here is my current env file screenshot: > [image: image.png] > Do you have any idea how to set the correct OS_SECGROUPS value in the env > file? If you already have the correct env file, then please let me know. > > Thank you, > Matthew > > On Mon, Mar 25, 2024 at 9:45 PM Matthew Swigart < > matthew.swigart35(a)gmail.com> wrote: > >> Hello Manuel, >> >> Appreciate your kind response. To fix the bad UUID, I updated the flavor >> field type from UUID to String instead in the Volume class from model.py. >> Also I created migration for this. So I was able to fix the above issue but >> after that changes, I got the new error. >> Let me attach the screenshot. >> >> Anyway, I am also fully available on the weekends. I joined in OpenStack >> VDI room Matrix element. (https://matrix.to/#/#opensource-vdi:matrix.org >> ) >> So hopefully we can discuss more detail through that room. >> >> Regards, >> Matthew >> >> On Mon, Mar 25, 2024 at 6:00 PM Manuel Bentele < >> development(a)manuel-bentele.de> wrote: >> >>> Hi Matthew, >>> >>> I'm glad that my mail was helpful to you. >>> >>> [...] I tried debugging the value and desktop_type.default_flavor.id >>> value is 2 [...] >>> >>> This seems to be where the error lies. A decimal value is set, but it >>> is not a valid UUID. >>> >>> [...] I tried checking the admin URL (/rcsadmin) but I can't see any >>> link to access DB records.) [...] >>> >>> You are already on the right track. It might be the case that the user >>> does not yet have the appropriate flags in Keycloak to be able to access >>> it. You can double check whether the required attribute "is_staff" is >>> set as stated in the Django documentation (see [3]). This attribute is >>> automatically set in Bumblebee if a user is already assigned the "staff" >>> role in Keycloak. Maybe there is something wrong in the initial setup? >>> >>> Please let me know your discoveries. I don't have much time at the >>> moment, but towards the end of the week I can set up a fresh instance >>> myself and see if access to the Django admin page still works. >>> >>> [3] https://docs.djangoproject.com/en/5.0/ref/contrib/admin/#overview >>> >>> Regards, >>> Manuel >>> >>> On 3/25/24 04:36, Matthew Swigart wrote: >>> >>> Hi Manuel, thank you for your helpful email. >>> >>> Yes, you are correct, so there is an issue when creating a record in DB >>> from vm_manager>vm_functions>create_vm.py>create_volume>Line 122 [1] (I >>> tried debugging the value and desktop_type.default_flavor.id value is >>> 2) and vm_manager>models.py>Volume class Line 138 [2] >>> >>> Could you please let me know how to fix the issue in more detail? >>> >>> And you said, I can access DB records through the Django admin site, >>> could you please let me know how to do it? (I tried checking the admin URL >>> (/rcsadmin) but I can't see any link to access DB records.) >>> >>> [1] >>> https://github.com/NeCTAR-RC/bumblebee/blob/2201540ba50af98838d9285d4659b93… >>> [2] >>> https://github.com/NeCTAR-RC/bumblebee/blob/2201540ba50af98838d9285d4659b93… >>> >>> Regards, >>> Matthew >>> >>> >>> >>> On Sun, Mar 24, 2024 at 2:34 PM Manuel Bentele < >>> development(a)manuel-bentele.de> wrote: >>> >>>> Hi Matthew, >>>> >>>> It looks like a UUID is missing or corrupted in the Django data model >>>> of Bumblebee while creating a volume record for a new VM. >>>> >>>> If we take a look at the model of a Bumblebee volume, we notice that a >>>> valid UUID for the flavor field is required (see [1]). During the VM >>>> creation, a new volume record is created where the volume's flavor field is >>>> set to the resolved UUID of the default flavor from a desktop type (see >>>> [2]). Setting an invalid flavor UUID could be the cause here. >>>> >>>> When setting up bumblebee, did you specify valid flavor names (existing >>>> ones from OpenStack) for all desktop types? >>>> >>>> To check the volume records in the database and adjust them if >>>> necessary, you can simply use the Django admin site. There you can view the >>>> entire data model of Bumblebee and all stored records graphically. >>>> >>>> [1] >>>> https://github.com/NeCTAR-RC/bumblebee/blob/2201540ba50af98838d9285d4659b93… >>>> [2] >>>> https://github.com/NeCTAR-RC/bumblebee/blob/2201540ba50af98838d9285d4659b93… >>>> >>>> Best regards, >>>> Manuel >>>> >>>> On 3/24/24 04:29, Matthew Swigart wrote: >>>> >>>> Hello, >>>> >>>> I'm trying to install the VDI project on my Ubuntu 22.04 LTS Desktop >>>> VMware workstation. >>>> So I chose Bumblebee(https://github.com/NeCTAR-RC/bumblebee) and went >>>> through several steps like configuring the devstack, installing docker, and >>>> Bumblebee project. >>>> >>>> And then, I tried to create a virtual desktop from Bumblebee and I got >>>> the below error: >>>> >>>> ValueError: badly formed hexadecimal UUID string >>>> >>>> Attached error screenshot: >>>> >>>> [image: image.png] >>>> >>>> Anybody has already experienced a similar issue or does anybody have >>>> any idea to solve this problem? Then please help me. >>>> >>>> Looking forward to hearing from you. >>>> >>>> Much appreciated. >>>> Matthew >>>> >>>>

2 1

keystone-manage db_sync problem
by aldavx＠gmail.com 29 Mar '24

29 Mar '24

Hi I'm trying migrate a keystone installation from stein to train and when I'm running : keystone-manage db_sync --check I see the following errors : 2024-03-29 10:48:08.193 469 WARNING py.warnings [-] /usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/reflection.py:62: SAWarning: Unknown schema content: ' "repository_id" varchar(250) NOT NULL,' util.warn("Unknown schema content: %r" % line) 2024-03-29 10:48:08.194 469 WARNING py.warnings [-] /usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/reflection.py:62: SAWarning: Unknown schema content: ' "repository_path" text DEFAULT NULL,' util.warn("Unknown schema content: %r" % line) 2024-03-29 10:48:08.194 469 WARNING py.warnings [-] /usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/reflection.py:62: SAWarning: Unknown schema content: ' "version" int(11) DEFAULT NULL,' util.warn("Unknown schema content: %r" % line) 2024-03-29 10:48:08.197 469 WARNING py.warnings [-] /usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/reflection.py:62: SAWarning: Unknown schema content: ' "id" int(11) NOT NULL AUTO_INCREMENT,' util.warn("Unknown schema content: %r" % line) : migrate.exceptions.DatabaseNotControlledError: migrate_version 2024-03-29 10:48:08.199 469 WARNING py.warnings [-] /usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/reflection.py:62: SAWarning: Unknown schema content: ' "service" varchar(64) DEFAULT NULL,' util.warn("Unknown schema content: %r" % line) : migrate.exceptions.DatabaseNotControlledError: migrate_version 2024-03-29 10:48:08.199 469 WARNING py.warnings [-] /usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/reflection.py:62: SAWarning: Unknown schema content: ' "path" varchar(128) DEFAULT NULL,' util.warn("Unknown schema content: %r" % line) : migrate.exceptions.DatabaseNotControlledError: migrate_version 2024-03-29 10:48:08.200 469 WARNING py.warnings [-] /usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/reflection.py:62: SAWarning: Unknown schema content: ' "method" varchar(16) DEFAULT NULL,' util.warn("Unknown schema content: %r" % line) : migrate.exceptions.DatabaseNotControlledError: migrate_version 2024-03-29 10:48:08.201 469 CRITICAL keystone [-] Unhandled error: sqlalchemy.exc.NoSuchTableError: access_rule 2024-03-29 10:48:08.201 469 ERROR keystone Traceback (most recent call last): 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/migrate/versioning/schema.py", line 45, in load 2024-03-29 10:48:08.201 469 ERROR keystone self.table = Table(tname, self.meta, autoload=True) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 469, in __new__ 2024-03-29 10:48:08.201 469 ERROR keystone metadata._remove_table(name, schema) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/util/langhelpers.py", line 67, in __exit__ 2024-03-29 10:48:08.201 469 ERROR keystone compat.reraise(exc_type, exc_value, exc_tb) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 277, in reraise 2024-03-29 10:48:08.201 469 ERROR keystone raise value 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 464, in __new__ 2024-03-29 10:48:08.201 469 ERROR keystone table._init(name, metadata, *args, **kw) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 552, in _init 2024-03-29 10:48:08.201 469 ERROR keystone metadata, autoload_with, include_columns, _extend_on=_extend_on 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 590, in _autoload 2024-03-29 10:48:08.201 469 ERROR keystone _extend_on=_extend_on, 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 2125, in run_callable 2024-03-29 10:48:08.201 469 ERROR keystone return conn.run_callable(callable_, *args, **kwargs) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1596, in run_callable 2024-03-29 10:48:08.201 469 ERROR keystone return callable_(self, *args, **kwargs) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 415, in reflecttable 2024-03-29 10:48:08.201 469 ERROR keystone table, include_columns, exclude_columns, **opts 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/reflection.py", line 639, in reflecttable 2024-03-29 10:48:08.201 469 ERROR keystone raise exc.NoSuchTableError(table.name) 2024-03-29 10:48:08.201 469 ERROR keystone sqlalchemy.exc.NoSuchTableError: migrate_version 2024-03-29 10:48:08.201 469 ERROR keystone 2024-03-29 10:48:08.201 469 ERROR keystone During handling of the above exception, another exception occurred: 2024-03-29 10:48:08.201 469 ERROR keystone 2024-03-29 10:48:08.201 469 ERROR keystone Traceback (most recent call last): 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/oslo_db/sqlalchemy/migration.py", line 128, in db_version 2024-03-29 10:48:08.201 469 ERROR keystone return versioning_api.db_version(engine, repository) 2024-03-29 10:48:08.201 469 ERROR keystone File "<decorator-gen-6>", line 2, in db_version 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/migrate/versioning/util/__init__.py", line 167, in with_engine 2024-03-29 10:48:08.201 469 ERROR keystone return f(*a, **kw) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/migrate/versioning/api.py", line 148, in db_version 2024-03-29 10:48:08.201 469 ERROR keystone schema = ControlledSchema(engine, repository) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/migrate/versioning/schema.py", line 33, in __init__ 2024-03-29 10:48:08.201 469 ERROR keystone self.load() 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/migrate/versioning/schema.py", line 54, in load 2024-03-29 10:48:08.201 469 ERROR keystone exceptions.DatabaseNotControlledError(str(exc)), tb) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/six.py", line 692, in reraise 2024-03-29 10:48:08.201 469 ERROR keystone raise value.with_traceback(tb) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/migrate/versioning/schema.py", line 45, in load 2024-03-29 10:48:08.201 469 ERROR keystone self.table = Table(tname, self.meta, autoload=True) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 469, in __new__ 2024-03-29 10:48:08.201 469 ERROR keystone metadata._remove_table(name, schema) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/util/langhelpers.py", line 67, in __exit__ 2024-03-29 10:48:08.201 469 ERROR keystone compat.reraise(exc_type, exc_value, exc_tb) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 277, in reraise 2024-03-29 10:48:08.201 469 ERROR keystone raise value 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 464, in __new__ 2024-03-29 10:48:08.201 469 ERROR keystone table._init(name, metadata, *args, **kw) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 552, in _init 2024-03-29 10:48:08.201 469 ERROR keystone metadata, autoload_with, include_columns, _extend_on=_extend_on 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 590, in _autoload 2024-03-29 10:48:08.201 469 ERROR keystone _extend_on=_extend_on, 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 2125, in run_callable 2024-03-29 10:48:08.201 469 ERROR keystone return conn.run_callable(callable_, *args, **kwargs) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1596, in run_callable 2024-03-29 10:48:08.201 469 ERROR keystone return callable_(self, *args, **kwargs) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 415, in reflecttable 2024-03-29 10:48:08.201 469 ERROR keystone table, include_columns, exclude_columns, **opts 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/reflection.py", line 639, in reflecttable 2024-03-29 10:48:08.201 469 ERROR keystone raise exc.NoSuchTableError(table.name) 2024-03-29 10:48:08.201 469 ERROR keystone migrate.exceptions.DatabaseNotControlledError: migrate_version 2024-03-29 10:48:08.201 469 ERROR keystone 2024-03-29 10:48:08.201 469 ERROR keystone During handling of the above exception, another exception occurred: 2024-03-29 10:48:08.201 469 ERROR keystone 2024-03-29 10:48:08.201 469 ERROR keystone Traceback (most recent call last): 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/bin/keystone-manage", line 10, in <module> 2024-03-29 10:48:08.201 469 ERROR keystone sys.exit(main()) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/keystone/cmd/manage.py", line 41, in main 2024-03-29 10:48:08.201 469 ERROR keystone cli.main(argv=sys.argv, developer_config_file=developer_config) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/keystone/cmd/cli.py", line 1370, in main 2024-03-29 10:48:08.201 469 ERROR keystone CONF.command.cmd_class.main() 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/keystone/cmd/cli.py", line 327, in main 2024-03-29 10:48:08.201 469 ERROR keystone sys.exit(DbSync.check_db_sync_status()) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/keystone/cmd/cli.py", line 269, in check_db_sync_status 2024-03-29 10:48:08.201 469 ERROR keystone expand_version = upgrades.get_db_version(repo='expand_repo') 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/keystone/common/sql/upgrades.py", line 236, in get_db_version 2024-03-29 10:48:08.201 469 ERROR keystone session.get_bind(), repo, get_init_version(repo)) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/oslo_db/sqlalchemy/migration.py", line 131, in db_version 2024-03-29 10:48:08.201 469 ERROR keystone meta.reflect(bind=engine) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 4159, in reflect 2024-03-29 10:48:08.201 469 ERROR keystone Table(name, self, **reflect_opts) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 469, in __new__ 2024-03-29 10:48:08.201 469 ERROR keystone metadata._remove_table(name, schema) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/util/langhelpers.py", line 67, in __exit__ 2024-03-29 10:48:08.201 469 ERROR keystone compat.reraise(exc_type, exc_value, exc_tb) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 277, in reraise 2024-03-29 10:48:08.201 469 ERROR keystone raise value 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 464, in __new__ 2024-03-29 10:48:08.201 469 ERROR keystone table._init(name, metadata, *args, **kw) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 552, in _init 2024-03-29 10:48:08.201 469 ERROR keystone metadata, autoload_with, include_columns, _extend_on=_extend_on 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 574, in _autoload 2024-03-29 10:48:08.201 469 ERROR keystone _extend_on=_extend_on, 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1596, in run_callable 2024-03-29 10:48:08.201 469 ERROR keystone return callable_(self, *args, **kwargs) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 415, in reflecttable 2024-03-29 10:48:08.201 469 ERROR keystone table, include_columns, exclude_columns, **opts 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/reflection.py", line 639, in reflecttable 2024-03-29 10:48:08.201 469 ERROR keystone raise exc.NoSuchTableError(table.name) 2024-03-29 10:48:08.201 469 ERROR keystone sqlalchemy.exc.NoSuchTableError: access_rule 2024-03-29 10:48:08.201 469 ERROR keystone I've checked the DB and both tables are there (access_rule and migrate_version). Do you know what could be wrong ? Best Alex

1 0

[ironic][PTG] Ironic Dalmatian 2024.2 PTG schedule
by Riccardo Pittau 29 Mar '24

29 Mar '24

Hello ironicers! We've finalized the schedule for the Ironic Dalmatian (2024.2) virtual PTG happening from Tuesday April 9th to Thursday April 11th. You can find the list of topics and the detailed schedule as well as the link to connect to the event in the etherpad at https://etherpad.opendev.org/p/ironic-ptg-april-2024 See you all there! CIao Riccardo

1 0

[Bobcat][Ansible][AIO] how to inspect lxc logs
by tatsuro.makita.bp＠nttdata.com 29 Mar '24

29 Mar '24

Hi OpenStack Users Group, I am building a single instance of AWS EC2 using OpenStack Ansible AIO (Bobcat). We are trying to build an all-in-one environment and check the functions of Bobcat. Construction Steps: https://docs.openstack.org/openstack-ansible/latest/user/aio/quickstart.html * I could use VLAN on EC2 only one instance. it doesn't multi-instance. Anssible has been successful, and I can access and log in to the Horizon console with a browser. I have been able to register the image, but I get an error when I create a volume from the image. * Even if you create an empty volume, the same error will occur. Wording displayed in the volume creation message: Message Level: ERROR Event Id: VOLUME_VOLUME_001_003 User Message: "all schedulelocate volume:Could not find any available weighted backend." When I tried to refer to the lxc log to debug the environment, Under /var/log/lxc, there is only the log from the first startup, and there are no debug statements that are running during the actual inspection. The lxc-* command does not have a command like "Docker logs", so I am having trouble analyzing logs such as Cinder. When building with Ansible, it is built with "debug:True" defined in /etc/openstacl_deploy/user_variables.yml. Is there any other configuration that outputs Debug logs for each component? Any advice on things to look at when analyzing each component built with lxc would be fine. Furthermore, my environment is as follows. *Instance type: m5a.2xlarge *vCPU8, 32GiB, EBS storage 100GB(root) and 50GB(seccond) *OS:Ubuntu-jammy-22.04 *OpenStack Ansible: 28.0.1 (Bobcat) Thanks regards.

3 5

[barbican][requirements] incompatibility between cryptography and pykmip
by Takashi Kajinami 29 Mar '24

29 Mar '24

Hello, It was recently discovered that the latest pykmip release is not compatible[1][2] with cryptography>42.0.0, which is currently in upper constraints for master and 2024.1. The latest release of pykmip is incompatible with even cryptography >= 39.0.0, because no release has been created since the compatibility fix[2] was merged. The stable/2023.2 branch currently uses cryptography 40.0.2 so the pykmip library has been broken since 2023.2, it seems. I wonder what would be the appropriate step to mitigate the problem, and I would like to ask for opinions. Especially the first question is a bit urgent because we have quite a short period to make deprecation for 2024.1 . 1. (To the barbican team and the operators subscribing this list) Can we deprecate the kmip secret store plugin in 2024.1 so that we can drop it in 2024.2 ? Or does anyone have any concern with removing it in a future release ? 2. (To requirements team) In case the proposed fix[3] is merged and a new pykmip release is created, can we bump the version in 2024.1 u-c and 2023.2 u-c ? As far as I've checked, pykmip is used only by Barbican so bumping it would have quite limited impact. Thank you, Takashi [1] https://meetings.opendev.org/irclogs/%23openstack-barbican/%23openstack-bar… [2] https://github.com/OpenKMIP/PyKMIP/issues/713 [3] https://github.com/OpenKMIP/PyKMIP/commit/652d5cab [4] https://github.com/OpenKMIP/PyKMIP/pull/714 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 1

[release] Release countdown for week R+0, Apr 01-05
by Elõd Illés 28 Mar '24

28 Mar '24

Development Focus ----------------- We will be releasing the coordinated OpenStack 2024.1 Caracal release next week, on April 3rd, 2024. Thanks to everyone involved in the 2024.1 Caracal cycle! We are now in pre-release freeze, so no new deliverable will be created until final release, unless a release-critical regression is spotted. Otherwise, teams attending the virtual PTG should start to plan what they will be discussing there, by creating and filling team etherpads. You can access the list of PTG etherpads at: http://ptg.openstack.org/etherpads.html General Information ------------------- On release day, the release team will produce final versions of deliverables following the cycle-with-rc release model, by re-tagging the commit used for the last RC. A patch doing just that will be proposed. PTLs and release liaisons should watch for that final release patch from the release team. While not required, we would appreciate having an ack from each team before we approve it on the 3rd, so that their approval is included in the metadata that goes onto the signed tag. Upcoming Deadlines & Dates -------------------------- Final 2024.1 Caracal release: April 3rd, 2024 2024.2 Dalmatian Virtual PTG: April 8-12, 2024 Előd Illés irc: elodilles @ #openstack-release

1 0

[CloudKitty] Cancelling weekly meeting of 1st of April
by Rafael Weingärtner 28 Mar '24

28 Mar '24

April 1stt is a public holiday for most People who attend the CloudKitty bi-weekly meeting. Therefore, we will be cancelling If you need any assistance until the next meeting, you can reach me via e-mail. Best regards, -- Rafael Weingärtner

1 0

[tc] Resolution regarding 2024.2 Dalmatian election
by Jay Faulkner 28 Mar '24

28 Mar '24

Hi all, There was a difficult situation spawned by the results of the recent TC election; all members, as elected, could not be seated under the TC Charter's diversity of affiliation policy[0][1]. One of the tc-members-elect from Red Hat, Sylvain Bauza, resigned his candidacy to resolve the affiliation issue[2]. As a result, we have a TC resolution up for vote, https://review.opendev.org/c/openstack/governance/+/914024, which adjudicates the election by acknowledging Sylvain's decision and naming Artem Goncharov his replacement under the TC charter rules for filling vacant seats[3]. This email serves as the required notice to the community of this resolution. I'd like to personally thank the Red Hat TC members and members-elect for resolving this issue, with a special thanks to Sylvain for helping to preserve TC affiliation diversity. Thanks, Jay Faulkner OpenStack TC Chair 0: https://governance.openstack.org/tc/reference/charter.html#tc-diversity-req… 1: https://review.opendev.org/c/openstack/governance/+/913912/3#message-728e57… 2: https://review.opendev.org/c/openstack/governance/+/913912/3#message-bb14bf… 3: https://governance.openstack.org/tc/reference/charter.html#election-for-tc-…

4 3

Facing issues in accessing console of Openstack VM's in EDGE sites
by Swogat Pradhan 28 Mar '24

28 Mar '24

Hi, I have set up openstack wallaby using tripleo on 3 different locations using DCN. I have a central site and 2 EDGE sites, when accessing the console of central sites I do not face any issues, but when accessing the console for EDGE sites I face issues sometimes, and then the issue disappears automatically and then comes back again. Attaching screenshot for reference. Can you please suggest what to look at here to fix this issue? With regards, Swogat Pradhan

2 2