| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-01-26 | |||
| 15:28:20 | lowercase | It wasn't this environment... | |
| 15:28:22 | lowercase | or was it? | |
| 15:28:42 | kevko | lowercase: but i still don't udenrstand why it's saying that can't connect to DB | |
| 15:28:49 | kevko | do you see mysql attempt ? | |
| 15:28:51 | lowercase | idk, I don't see Moody online | |
| 15:29:15 | kevko | what about your nova.conf ..can u share ? | |
| 15:30:00 | lowercase | Oh, you are looking that the lines from the db manage command that ask to ensure the db connection is good? | |
| 15:30:09 | lowercase | yeah sorry, that's a strong red herring | |
| 15:32:19 | lowercase | So each version of openstack is associated with a structure or schema of the database. The database scheme changes based on the needs of the devs and what information needs to be stored. To ensure the code knows which version the database is on, they use a database version number. In this case, "960aac0e09ea" denotes the last version the nova-api database is on. Zed's | |
| 15:32:22 | lowercase | nova-manage db sync, goes in, inspects the version number. And returns an error stating that it doesn't know which SCHEME the database is on and thus cannot upgrade it. | |
| 15:33:34 | lowercase | What normally happens is nova-manage db sync looks at the previous version number, modifies the schema of the database, and replaces the arambic (sp?) version number to be the new database schema. | |
| 15:38:37 | lowercase | I think this is what I'm looking for: https://github.com/openstack/nova/tree/master/nova/db/api/migrations/versions | |
| 15:39:46 | lowercase | At the top of the code it mentions: Revision ID: cdeec0c85668 Is the version of the database schema is GOING TO, and the Revises: b30f573d3377 says what the database schema is COMING FROM | |
| 15:40:19 | lowercase | i swear to god, kevko if your a dev and you're just letting me ramble on while you know this shit and didn't tell me I will feel like a fool. | |
| 16:14:04 | kevko | lowercase: I am ops .. | |
| 16:14:17 | kevko | lowercase: didn't know ..i wanted to just help .. | |
| 16:14:22 | kevko | or devops | |
| 18:44:50 | opendevreview | sean mooney proposed openstack/nova master: [WIP] add iniital health check to compute agent https://review.opendev.org/c/openstack/nova/+/906911 | |
| #openstack-nova - 2024-01-27 | |||
| 04:34:12 | opendevreview | Ghanshyam proposed openstack/nova master: HyperV: Remove RDP console API https://review.opendev.org/c/openstack/nova/+/906809 | |
| 08:03:53 | opendevreview | melanie witt proposed openstack/nova master: libvirt: Configure and teardown ephemeral encryption secrets https://review.opendev.org/c/openstack/nova/+/826754 | |
| 08:03:53 | opendevreview | melanie witt proposed openstack/nova master: imagebackend: Add support to libvirt_info for LUKS based encryption https://review.opendev.org/c/openstack/nova/+/826755 | |
| 08:03:54 | opendevreview | melanie witt proposed openstack/nova master: Add encryption support to convert_image https://review.opendev.org/c/openstack/nova/+/870934 | |
| 08:03:54 | opendevreview | melanie witt proposed openstack/nova master: Support create with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/870932 | |
| 08:03:55 | opendevreview | melanie witt proposed openstack/nova master: Support resize with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/870933 | |
| 08:03:55 | opendevreview | melanie witt proposed openstack/nova master: Add hw_ephemeral_encryption_secret_uuid image property https://review.opendev.org/c/openstack/nova/+/870935 | |
| 08:03:56 | opendevreview | melanie witt proposed openstack/nova master: Add encryption support to qemu-img rebase https://review.opendev.org/c/openstack/nova/+/870936 | |
| 08:03:57 | opendevreview | melanie witt proposed openstack/nova master: Support snapshot with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/870937 | |
| 08:03:57 | opendevreview | melanie witt proposed openstack/nova master: Support rebuild and unshelve with ephemeral encryption https://review.opendev.org/c/openstack/nova/+/870939 | |
| 08:03:59 | opendevreview | melanie witt proposed openstack/nova master: Support rescue with ephemeral encryption https://review.opendev.org/c/openstack/nova/+/873675 | |
| 08:03:59 | opendevreview | melanie witt proposed openstack/nova master: libvirt: make |
|
| 08:04:01 | opendevreview | melanie witt proposed openstack/nova master: WIP Support migration with ephemeral encryption https://review.opendev.org/c/openstack/nova/+/905512 | |
| 08:04:01 | opendevreview | melanie witt proposed openstack/nova master: Reject (resize|rebuild) API requests with conflicting encryption https://review.opendev.org/c/openstack/nova/+/904240 | |
| 08:04:03 | opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for qcow2 with LUKS https://review.opendev.org/c/openstack/nova/+/772273 | |
| 08:04:03 | opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for raw with LUKS https://review.opendev.org/c/openstack/nova/+/884313 | |
| 08:04:05 | opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for rbd with LUKS https://review.opendev.org/c/openstack/nova/+/889912 | |
| 08:04:44 | opendevreview | melanie witt proposed openstack/nova master: DNM test ephemeral encryption + resize: qcow2, raw, rbd https://review.opendev.org/c/openstack/nova/+/862416 | |
| 14:03:34 | opendevreview | Takashi Kajinami proposed openstack/python-novaclient master: Update hacking version in pre commit config https://review.opendev.org/c/openstack/python-novaclient/+/906964 | |
| 23:20:20 | opendevreview | Ghanshyam proposed openstack/nova master: HyperV: Remove RDP console connection information API https://review.opendev.org/c/openstack/nova/+/906991 | |
| 23:28:52 | opendevreview | Ghanshyam proposed openstack/nova master: HyperV: Remove RDP console connection information API https://review.opendev.org/c/openstack/nova/+/906991 | |
| #openstack-nova - 2024-01-28 | |||
| 01:12:43 | opendevreview | Ghanshyam proposed openstack/nova master: HyperV: Remove RDP console API https://review.opendev.org/c/openstack/nova/+/906809 | |
| 02:15:17 | opendevreview | Ghanshyam proposed openstack/nova master: HyperV: Remove extra specs of HyperV driver https://review.opendev.org/c/openstack/nova/+/906992 | |
| #openstack-nova - 2024-01-29 | |||
| 02:23:48 | gmann | bauzas: sean-k-mooney:dansmith: removing HyperV driver/APIs are up for review, please check https://review.opendev.org/q/topic:%22bp/remove-hyperv-driver%22 | |
| 06:45:55 | opendevreview | Amit Uniyal proposed openstack/nova master: Allow swap resize from non-zero to zero https://review.opendev.org/c/openstack/nova/+/857339 | |
| 08:40:32 | gibi | elodilles: when you have time could you take a look https://review.opendev.org/q/topic:%22power-mgmt-fixups%22+branch:stable/2023.2 ? | |
| 08:41:25 | gibi | hold on, I was naively thought the master rever landed | |
| 08:50:51 | elodilles | gibi: i'll have a look soon | |
| 08:51:10 | elodilles | i mean just after master poatch has landed :D | |
| 08:52:28 | gibi | I know the rules :) | |
| 10:49:21 | opendevreview | Merged openstack/python-novaclient master: Update hacking version in pre commit config https://review.opendev.org/c/openstack/python-novaclient/+/906964 | |
| 11:16:58 | sean-k-mooney | gmann: thanks ill try and make my way through that series this week | |
| 11:17:31 | sean-k-mooney | skimming over it, the patches make sense | |
| 13:31:49 | gibi | bauzas: did you deploy the manila series in devstack? if so which backend you used nfs, or ceph? | |
| 13:32:06 | bauzas | nope I just reviewed the code for the moment | |
| 13:32:30 | bauzas | until we merge the API change, it's not a problem if we don't test it | |
| 13:33:04 | gibi | bauzas: I just tested it with nfs backend and it worked for me | |
| 13:33:22 | gibi | bauzas: so if you test it you can start with ceph to increase manual coverage :) | |
| 13:33:35 | gibi | I'm reviewing the code now | |
| 13:34:11 | bauzas | OK | |
| 13:34:26 | bauzas | I needed to work last week on a lot of changes, but I can start | |
| 13:34:54 | bauzas | I also need to test my own mdev live-migration series :) | |
| 15:43:18 | opendevreview | Merged openstack/nova master: Attach Manila shares via virtiofs (objects) https://review.opendev.org/c/openstack/nova/+/839401 | |
| 16:34:25 | bauzas | Uggla: now that patch is merged, a gentle reminder that I asked you a follow-up patch for https://review.opendev.org/c/openstack/nova/+/839401/36/nova/objects/share_mapping.py#93 | |
| 16:35:15 | Uggla | @bauzas, I'll do it no pb. | |
| 16:46:15 | opendevreview | zhouzhong proposed openstack/nova master: Validate flavor image min ram when resizing a volume-backend instance https://review.opendev.org/c/openstack/nova/+/906813 | |
| 17:43:05 | gibi | Uggla: I see a discrepancy between the spec and the impl | |
| 17:43:07 | gibi | The spec says | |
| 17:43:09 | gibi | Share attachment/detachment can only be done if the VM state is ``STOPPED`` | |
| 17:43:12 | gibi | or ``ERROR``. | |
| 17:43:15 | gibi | These are operations only on the database, and no RPC calls will be required | |
| 17:43:18 | gibi | to the compute API. This is an intentional design for this spec. | |
| 17:43:20 | gibi | As a result, this could lead to situation where the VM start operation fails | |
| 17:43:23 | gibi | as an underlying share attach fails. | |
| 17:43:26 | gibi | -- | |
| 17:43:37 | gibi | But I see that the actauly host attachment happens during the attach API call in my devstack | |
| 17:43:53 | gibi | is it intentional? | |
| 17:45:30 | Uggla | @gibi, if I'm not wrong this case is handled or I misunderstand something. If the share is in error it is "discarded" from the list and the VM should start. | |
| 17:45:42 | Uggla | If think it is in get_share_info | |
| 17:46:58 | gibi | my point is the spec states that attaching a share via the REST API is a DB only operation. But in my devstack the host attachment happens during the attach REST API call. | |
| 17:52:20 | gibi | I guess the original plan was to do the share attachment to the host during the VM start, but for some reason it is moved to the share attach call. | |
| 17:54:13 | Uggla | yes we discussed that, we moved from that because it made it more complex and causes some issue. But I do not remember well what were the issues. | |
| 17:54:54 | gibi | The current design means that all the share mounting logic and the retry loop waiting for the share access setup from manial is in a syncronous RPC call that holds up the share attach REST API response. | |
| 17:55:33 | Uggla | yes. It was the intention to have it syncronous. | |
| 17:57:05 | gibi | OK. If bauzas is OK with this then I can accept it, but we need to document for the share_apply_policy_timeout that it cannot be set over our RPC timeout as that will lead to strange errors. | |
| 17:57:13 | Uggla | I remembered discussing that with @bauzas too. | |
| 17:57:17 | bauzas | I quickly looked | |
| 17:57:22 | gibi | and we need to amend the spec | |
| 17:57:24 | bauzas | I need to leave by now | |
| 17:58:00 | bauzas | I obvisouly need to reload that context in my mind | |
| 17:58:41 | bauzas | oh I remember | |
| 17:58:44 | Uggla | @bauzas, I'm sure we discussed that synchronous etc stuff. But this is old discussion I don't remember well. | |
| 17:59:09 | bauzas | the fact is that you start making it asynchronous (which is OK with me) then you need to manage the states somewhere | |
| 17:59:41 | gibi | bauzas: the spec said that the share attach REST API is DB only so I assume the state is managed in the DB :) | |
| 18:00:40 | gibi | also I understood from the spec that the host mount happens during the start_instance RPC | |
| 18:00:58 | bauzas | because the instance has to be in stopped state, right? | |
| 18:01:03 | bauzas | (as a precondition) | |
| 18:01:05 | gibi | yes | |
| 18:01:41 | bauzas | I'm a bit afraid of a blocking call, I may have missed it | |
| 18:02:11 | Uggla | If I remember well, doing it at power_on led to "large" change in the error handling of power_on / power_off and other actions. | |
| 18:02:13 | bauzas | gibi: you only saw that behaviour by testing, right? I'm saying that because I haven't yet reviewed the API change | |
| 18:02:32 | bauzas | and I guess the blocking call to the compute RPC API is made there | |