| *** fungi is now known as Guest9249 | 01:33 | |
| *** kinrui is now known as fungi | 01:41 | |
| opendevreview | Artem Goncharov proposed openstack/nova master: Fix add/remove SecurityGroup action json schemas https://review.opendev.org/c/openstack/nova/+/934823 | 08:24 |
|---|---|---|
| opendevreview | Max proposed openstack/nova master: fix: leftover BDM after instance delete https://review.opendev.org/c/openstack/nova/+/934984 | 15:28 |
| dansmith | sean-k-mooney: can you look at the osvif failure here? https://review.opendev.org/c/openstack/requirements/+/934176 | 15:44 |
| dansmith | cc frickler ^ | 15:44 |
| tkajinam | dansmith, we need https://review.opendev.org/c/openstack/os-vif/+/932436 and a new release of os-vif. | 15:53 |
| tkajinam | but that change is blocked due to broken openstack-tox-functional-ovs-with-sudo | 15:53 |
| dansmith | ah I didn't see a comment on that requirements patch so I didn't know | 15:54 |
| dansmith | that requirements thing is holding up another nova fix, among other things | 15:54 |
| s3rj1k | sean-k-mooney: Hi, was able to repro that live-migration issue with broken DNS, please see details here https://bugs.launchpad.net/nova/+bug/2086867/comments/3 | 16:10 |
| opendevreview | Merged openstack/nova-specs master: Update and Re-propose "Allow Manila shares to be directly attached to an instance when using libvirt" for Epoxy https://review.opendev.org/c/openstack/nova-specs/+/930471 | 16:12 |
| sean-k-mooney | s3rj1k: ok that not a nova bug :) | 16:15 |
| sean-k-mooney | dansmith: i cna take a look but the the last time i looked at it a few months ago it work for me locally and i coudl not repoduce the failure | 16:16 |
| sean-k-mooney | dansmith: so ill see if it repodcues localy now | 16:16 |
| sean-k-mooney | s3rj1k: oh this was in relation to using the ip adress | 16:16 |
| sean-k-mooney | s3rj1k: so have you defiend the two nova config option i noted to use the ip? | 16:17 |
| sean-k-mooney | oh this is failing on config drive | 16:18 |
| sean-k-mooney | this i shiti som old fallback cod ethat is not needed anymore i think | 16:19 |
| sean-k-mooney | we used to have a workaround for old libvirt version that we have not supproted for many many years | 16:21 |
| sean-k-mooney | where we copy the config drive in nova instead of leaving libvirt do it | 16:21 |
| sean-k-mooney | ya this https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L11456-L11468 | 16:22 |
| sean-k-mooney | s3rj1k: so that cod ethat we can delete now, there is a patch somewhere to fix that | 16:22 |
| sean-k-mooney | as a workaround you could use vfat config drives but we shoudl just delete that code. | 16:23 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/909122 | 16:24 |
| sean-k-mooney | s3rj1k: ^ thats the fix for your issue | 16:24 |
| opendevreview | Doug Szumski proposed openstack/nova master: Revert "[libvirt] Live migration fails when config_drive_format=iso9660" https://review.opendev.org/c/openstack/nova/+/909122 | 16:24 |
| s3rj1k | sean-k-mooney: yea both options on both computes with corresponding IPs | 16:24 |
| s3rj1k | hmm, https://review.opendev.org/c/openstack/nova/+/909122 will remove support for config-drive? | 16:26 |
| sean-k-mooney | no | 16:26 |
| sean-k-mooney | libvirt and qemu can automatically copy the iso file as part fo the live migration | 16:27 |
| sean-k-mooney | but libvirt had a bug 8-9 years ago | 16:27 |
| s3rj1k | ok, let me try that, I'll report back | 16:27 |
| sean-k-mooney | and that was a tempory workaround until it could be fixed and we never reverted it | 16:27 |
| sean-k-mooney | i think this stopped being a thing we needed to care about when we dropped ubuntu 12.04 or 14.04 support | 16:28 |
| sean-k-mooney | s3rj1k: ah someone else already reported a similar issue to yours https://bugs.launchpad.net/nova/+bug/1939869 | 16:31 |
| s3rj1k | similar yes, fails on "Host key verification failed" | 16:37 |
| pas-ha[m] | hi folks, today we faced what seems another fallout of those qcow-related CVE fixes. After update to latest Antelope code, some of our previously working (windows) images no longer boot (and volume can not be created). Upon closer inspection, those happened to be qcow v1 images uploaded to glance with disk_format=qcow2. This is clearly not right, yet it was working before and I wonder who else might get bitten.. | 16:44 |
| dansmith | pas-ha[m]: it was working before because glance does absolutely no inspection of images | 16:46 |
| pas-ha[m] | from the comment in oslo.utils image format inspector, I get that this was intentional, yet I do not see that in release notes or smth. | 16:47 |
| pas-ha[m] | yeah, I know that š | 16:47 |
| dansmith | also I suspect your images are not qcow1, but qcow2v1 | 16:47 |
| dansmith | pas-ha[m]: https://review.opendev.org/c/openstack/nova/+/928937 | 16:48 |
| pas-ha[m] | Just wanted to highlight that may be it worth mentioning that in release notes, even retro-actively | 16:48 |
| dansmith | I wasn't planning to merge that, I mostly did it just so it was available | 16:48 |
| dansmith | pas-ha[m]: ack, it wasn't mentioned in the release notes because most of us had assumed people had long since moved off of unsupported formats like that.. not sure we'd go back and put in a retroactive reno like that or not | 16:49 |
| pas-ha[m] | this is tricky semantic š qemu-img calls it 'qcow' (not qcow2), calling 'file' shows 'QEMU QCOW Image (v1)'. | 16:53 |
| pas-ha[m] | in my understanding it is really qcow == qcow v1. then came qcow v2 == qcow2 which is very different internally, and then came qcow v3 which is an extension of v2 and is backward compatible, so it is still called qcow2 file format. | 16:53 |
| pas-ha[m] | when I tried to repro such an image, this is what you get with 'qemu-img convert -O qcow' | 16:54 |
| pas-ha[m] | and there was QED which is even older than QCOW | 16:55 |
| dansmith | pas-ha[m]: I'm quite sure you don't have any *actual* qcowv1 files | 16:57 |
| dansmith | if it really is, I think we can safely say we don't intend to support your use of those | 16:58 |
| dansmith | I know some *cough* distributions of qemu disable write support for the actual v1 format | 16:58 |
| pas-ha[m] | as I said, this is what 'file' and 'qemu-img info' showed once I fetched files locally. I personally think someone fat fingered -O qcow2 š still, came as a surprise once it broke and stopped working | 16:59 |
| dansmith | yeah, if qemu-img is showing "file format: qcow" then you're using the ancient version that uses totally different code in qemu (as opposed to 2 and 2v3) | 17:03 |
| dansmith | and we have never intended to support that, so I wouldn't even say we broke it.. I'd say that fits into another category of issues where you can fool nova into booting images on libvirt we intend to disallow by lying in glance | 17:04 |
| dansmith | so this is that sort of thing, you claimed it was a v2, it's not, but we sent it to the compute node anyway and didn't notice that it's actually something other than what we expected | 17:04 |
| dansmith | the "unintended" inspector stuff was around breaking qcow2 (vs qcow2v3) *not* about breaking the old-old format we didn't intend to support anyway | 17:05 |
| s3rj1k | sean-k-mooney: with https://review.opendev.org/c/openstack/nova/+/909122 the actual stack trace error is gone but I still see migration failure, "Live Migration failure: Cannot recv data: ssh: Could not resolve hostname" | 17:20 |
| sean-k-mooney | s3rj1k: ok so the revert is not enough to fix https://bugs.launchpad.net/nova/+bug/1939869 then its just part of it | 17:23 |
| sean-k-mooney | s3rj1k: you tested that with both options set to the ip yes adn the revert applied to the dest node | 17:24 |
| sean-k-mooney | (it shoudl be on both but i think it actully runs on the dest node) | 17:24 |
| s3rj1k | both options set yea, also checked with and without config-drive after applying patch | 17:26 |
| s3rj1k | revert is on both computes | 17:26 |
| sean-k-mooney | ok you got the same issue without config drive | 17:26 |
| sean-k-mooney | what are you using for the live migration url | 17:27 |
| sean-k-mooney | are you using the default | 17:27 |
| s3rj1k | yea, I think before revert without config drive migration was working | 17:27 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_uri | 17:27 |
| s3rj1k | default migration url | 17:27 |
| sean-k-mooney | ok so plain text over tcp qemu+tcp://%s/system | 17:28 |
| sean-k-mooney | unless you have tls enabled | 17:28 |
| s3rj1k | ok no so default then, I have live_migration_uri = qemu+ssh://stack@%s/system | 17:28 |
| sean-k-mooney | ah you using ssh. its what most do when not using tls | 17:29 |
| sean-k-mooney | so %s is replaced with the hostname | 17:29 |
| sean-k-mooney | well | 17:29 |
| sean-k-mooney | the docs say | 17:29 |
| sean-k-mooney | Any included ā%sā is replaced with the migration target hostname, or live_migration_inbound_addr if set. | 17:29 |
| sean-k-mooney | so that shoudl use the ip | 17:30 |
| s3rj1k | live_migration_inbound_addr is set to IP | 17:30 |
| sean-k-mooney | do you have a trace fo the error youc an share with the revert applied | 17:30 |
| sean-k-mooney | s3rj1k: basically im wondering if there is another scp somewhere | 17:30 |
| s3rj1k | actually no trace where in logs, let me check again | 17:30 |
| s3rj1k | actually no trace where in logs, let me check again | 17:30 |
| s3rj1k | yea, see it, I'll update launchpad in a moment | 17:32 |
| sean-k-mooney | ack. my gues is we just missed using the config option somewhere and hardcoded the hypervisor_hostname, the other possibleity is it is using the ip now and that is not in the ssh know hosts | 17:32 |
| sean-k-mooney | oh its might be that change this https://review.opendev.org/c/openstack/nova/+/906053/4/nova/virt/libvirt/driver.py | 17:34 |
| sean-k-mooney | you not tryign to migrate an isntance that uses an image that was deleted in glance are you | 17:34 |
| sean-k-mooney | at the moment we are passign instance.host as the fallback host but that is likely not correct in this case | 17:35 |
| s3rj1k | updated https://bugs.launchpad.net/nova/+bug/2086867/comments/4 | 17:36 |
| sean-k-mooney | oh its comming form migrateToURI3 | 17:36 |
| s3rj1k | using cirros for debug | 17:37 |
| sean-k-mooney | that does not make sense based on what you said was set on the config | 17:37 |
| sean-k-mooney | ya the guest iamge should not factor in here other then if its deleted in glance | 17:37 |
| s3rj1k | it's definitely in config, let me restart services just in case and retry | 17:38 |
| sean-k-mooney | we might just need to set up this evn and debug it | 17:38 |
| sean-k-mooney | this is basiclly just a normal multi node devstack but instead of regestierign the host in dns, mdns or /etchost you have set the ips | 17:39 |
| sean-k-mooney | which on master shoudl work | 17:39 |
| sean-k-mooney | you coudl also set [DEFAULT]host=<ip> i guess | 17:39 |
| sean-k-mooney | you should not have too | 17:40 |
| sean-k-mooney | but im pretty sure that would fix this and break neutorn unless you did the same there.... | 17:40 |
| sean-k-mooney | im debating how easy it would be to repoduce this in the ci | 17:41 |
| sean-k-mooney | vs the hour it woudl take me to set this up by hand. that is proably quicker | 17:41 |
| sean-k-mooney | but you know lazy | 17:41 |
| s3rj1k | ok, so cold-migrate works fine, live-migrate is not | 17:47 |
| s3rj1k | I am pretty sure that this is one-shot repro, so CI is overkill | 17:48 |
| s3rj1k | idea is to have a fallback on IPs when DNS has issues, so directly using would work but UX is bad in this case | 17:49 |
| sean-k-mooney | s3rj1k: so yes an no | 17:52 |
| sean-k-mooney | nova does not genreally have ips to fall back too | 17:52 |
| sean-k-mooney | and in this case its failing in libvirt not nova | 17:52 |
| sean-k-mooney | so nova required that you either have dns for each of the compute nodes ro that you provie hostname resolution some ohter way like /etc/hosts | 17:53 |
| sean-k-mooney | now if you put the ips int eh config that is intended to work | 17:53 |
| sean-k-mooney | so there is a bug somewhere | 17:53 |
| sean-k-mooney | but we require the opertor to make the hostnames resouceabel or provide the ips | 17:53 |
| s3rj1k | so, should we start with merging revert and fixing edge after merge or we should fix-all-the-things :) ? | 17:57 |
| s3rj1k | * edge case | 17:57 |
| sean-k-mooney | s3rj1k: we proably should proceed with the revert if that does not regess anything then fix what is left in a follow up patch | 18:29 |
| sean-k-mooney | s3rj1k: what release are you trying to adress this in by the way | 18:30 |
| s3rj1k | sean-k-mooney: hopefully upcoming 2025.1 Epoxy | 18:33 |
| sean-k-mooney | oh ok you dont need this in older releases as well | 18:33 |
| sean-k-mooney | seperate form the revert im wondering if there was a bug in https://github.com/openstack/nova/commit/6bca37e904e9e56b250b123abde1901e951c8c9a | 18:33 |
| s3rj1k | well, probably some older releases could be potentially needed, but this is another story that I hope I could avoid :) | 18:34 |
| sean-k-mooney | no worries | 18:34 |
| sean-k-mooney | what im condiering is if we consider it a regresion intoduced by the "libvirt-migrate-with-hostname-instead-of-ip" which was not ment to change the default behaicvor then it would be a bug and backportable | 18:36 |
| s3rj1k | migration_inbound_addr is for none-live migration? if so, none-live migration worked for me when DNS is blocked | 18:36 |
| sean-k-mooney | otherwise this is kind of a mini featur and only fixable on master | 18:36 |
| sean-k-mooney | s3rj1k: it is but its also for some shared commdns that are used during live migration | 18:37 |
| sean-k-mooney | s3rj1k: im wondering if this https://github.com/openstack/nova/commit/6bca37e904e9e56b250b123abde1901e951c8c9a#diff-486ddc37ce8e7c105a51566dd2cffbda034f28fae7eaad2e74abf470ab296352R4514-R4523 | 18:37 |
| sean-k-mooney | impacted live migrtaion in a way we did not plan it too | 18:37 |
| sean-k-mooney | although you have set both to an ip | 18:38 |
| sean-k-mooney | so proably something else | 18:38 |
| sean-k-mooney | i need to set up a multi node devstack for somethign else | 18:38 |
| s3rj1k | sean-k-mooney: I can retested after revert gets merged, so no problem with that | 18:38 |
| s3rj1k | hmm, "if "%s" in addr:" | 18:38 |
| sean-k-mooney | ill see if i can repoduce this when i do | 18:39 |
| sean-k-mooney | oh | 18:39 |
| sean-k-mooney | ya that is the bug | 18:39 |
| sean-k-mooney | that code is assumeing that %s is always going to repalce with the hostname | 18:39 |
| sean-k-mooney | but if you set the livemigration config var to the ip we should not be using get_hostname there | 18:40 |
| sean-k-mooney | well hum | 18:40 |
| sean-k-mooney | i think that depned on where get_host_ip_addr is being called form at the time | 18:40 |
| s3rj1k | fix would be moving line 4520 below if I guess | 18:40 |
| s3rj1k | with some check if conf is set | 18:41 |
| sean-k-mooney | something along those lines maybe | 18:42 |
| sean-k-mooney | could you try regerting get_host_ip_addr to just return CONF.my_ip | 18:42 |
| sean-k-mooney | and see if that fixes it for you locally | 18:42 |
| sean-k-mooney | it will break the other fature so that not the correct fix but it will confirm if that is the souce of the regression | 18:43 |
| s3rj1k | yea, give me few minutes | 18:43 |
| sean-k-mooney | although you do not have "%s" in CONF.libvirt.migration_inbound_addr do you? | 18:45 |
| sean-k-mooney | you do in the migration uri but that is just an ip adress reight | 18:45 |
| sean-k-mooney | *right | 18:45 |
| s3rj1k | I have live_migration_uri = qemu+ssh://stack@%s/system and live_migration_inbound_addr, migration_inbound_addr set to IPs, nothing more related to migration in libvirt section | 18:54 |
| s3rj1k | so I've tried to return both CONF.my_ip and CONF.libvirt.migration_inbound_addr, migration still tries to resolve by dns | 18:55 |
| sean-k-mooney | s3rj1k: ok we are going to need ot look at exaclty what we are passing to the migrate too uri libvirt call | 19:35 |
| s3rj1k | sean-k-mooney: do you have some specific debug changes in mind? | 19:36 |
| sean-k-mooney | baiscally debugging this call https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L10854-L10859 | 19:40 |
| sean-k-mooney | we can do that by putting some debug logs or prints in https://github.com/openstack/nova/blob/master/nova/virt/libvirt/guest.py#L591 | 19:41 |
| sean-k-mooney | s3rj1k: in your config we would expect both destination and migrate_uri to have the ip | 19:42 |
| sean-k-mooney | but i suspect one or both of them have the hostname | 19:42 |
| sean-k-mooney | s3rj1k: the excption form libvirt is comming form this funciton call https://github.com/openstack/nova/blob/master/nova/virt/libvirt/guest.py#L647 | 19:42 |
| s3rj1k | hmm, destination has hostname as expected I guess, but migrate_uri is None for some reason | 19:51 |
| s3rj1k | smth wrong in here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L10781-L10786 ? | 19:54 |
| s3rj1k | "non tunneled migration" | 19:55 |
| sean-k-mooney | we do not want to use tunneled migration so i think that is fine | 20:09 |
| sean-k-mooney | so the quetion is where did destinaiton get set ot the host name | 20:09 |
| s3rj1k | migrate_uri is None, this is expected? | 20:10 |
| sean-k-mooney | i dont recall of the top of my head but we do not adivse using tunneld migration | 20:10 |
| sean-k-mooney | so that being none is proably ok | 20:10 |
| sean-k-mooney | dist i think is coming form (self._live_migration_uri(dest) | 20:11 |
| sean-k-mooney | ok that just ipv6 escapign the dest that past in | 20:11 |
| sean-k-mooney | so thats passed in to live_migrate in the driver and that invoked over rpc via the compute manager | 20:14 |
| s3rj1k | here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L10733 it is already a hostname | 20:16 |
| s3rj1k | (dest var) | 20:17 |
| sean-k-mooney | yep | 20:17 |
| sean-k-mooney | so in the conduction its a destation object i think it being converted to the host name in the compute manager but im trying to find that | 20:17 |
| sean-k-mooney | or not https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L9037 | 20:19 |
| sean-k-mooney | that looks like its alrady going to be the host name on the comptue manager side of the rpc | 20:19 |
| sean-k-mooney | s3rj1k: so https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L509-L562 is returning the host form the select_destinations call to the schduler | 20:21 |
| sean-k-mooney | selection.service_host | 20:22 |
| sean-k-mooney | is what self.destination has here https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L100 | 20:22 |
| sean-k-mooney | which we pass here https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L157 | 20:23 |
| s3rj1k | I assume that we want this hotfixed near live_migration_inbound_addr handling? | 20:24 |
| sean-k-mooney | so the porblem is the schduelr does not realy knwo about the ips of the comptue nodes so it just sleect the dstionation compute service to hanel the request | 20:26 |
| sean-k-mooney | which means that we need to transport the information form the dest comptue node back to the source eiver via the database or rpc | 20:27 |
| sean-k-mooney | to then pass it to libvirt on the souce node | 20:27 |
| sean-k-mooney | in other words the source compute node need the value of live_migration_inbound_addr form the destioantion host when it calls libvirt | 20:28 |
| s3rj1k | ahh, that makes sense, and makes fix more complicated :( | 20:28 |
| sean-k-mooney | we shoudl proably do that by adding it to the libvirtLiveMigrationData object https://github.com/openstack/nova/blob/master/nova/objects/migrate_data.py#L229 | 20:30 |
| sean-k-mooney | in pre live migrate | 20:30 |
| sean-k-mooney | so we need to add a new field "destiantion_address" | 20:31 |
| s3rj1k | target_connect_addr seems familiar | 20:31 |
| s3rj1k | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L10781-L10786 | 20:31 |
| sean-k-mooney | it deso but im not sure if that is related to the storage network | 20:32 |
| sean-k-mooney | hum | 20:32 |
| sean-k-mooney | can you pritn some of that locally and see what branch we are taking | 20:33 |
| s3rj1k | yea, few min | 20:33 |
| sean-k-mooney | if im readign that proprly then if target_connect_addr was set by the dest node to the ip then it would use it | 20:33 |
| sean-k-mooney | assuming tunneled migraiton is off which it is by default | 20:34 |
| sean-k-mooney | hum it should be uncondtionally set here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L11503-L11505 | 20:35 |
| s3rj1k | target_connect_addr in migrate_data but value is None and (migration_flags & libvirt.VIR_MIGRATE_TUNNELLED == 0) | 20:39 |
| sean-k-mooney | thats odd because its clearly bing set unconditionally on the dest so either we are loosign the value or there is a bug in how we are setting it form the config | 20:40 |
| s3rj1k | sean-k-mooney: ok, so just to verify, live_migration_inbound_addr is under libvirt in /etc/nova/nova.conf for devstack right? | 20:47 |
| sean-k-mooney | good question i think so | 20:48 |
| sean-k-mooney | yep https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_inbound_addr | 20:49 |
| s3rj1k | because I've just added log.debug in https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L11503-L11505 on target node and I see that value is None | 20:49 |
| sean-k-mooney | when the comptue start up in debug mode it dumps the config to the log | 20:50 |
| sean-k-mooney | is it set to the correct value there? | 20:50 |
| opendevreview | ribaudr proposed openstack/nova master: Amend ShareMappingStatus due to asynchronous call https://review.opendev.org/c/openstack/nova/+/908864 | 20:50 |
| opendevreview | ribaudr proposed openstack/nova master: Amend DB model add a unique constraint. https://review.opendev.org/c/openstack/nova/+/912518 | 20:50 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194 | 20:50 |
| opendevreview | ribaudr proposed openstack/nova master: Use client token when talking to manila https://review.opendev.org/c/openstack/nova/+/925277 | 20:50 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (drivers and compute manager part) https://review.opendev.org/c/openstack/nova/+/833090 | 20:50 |
| opendevreview | ribaudr proposed openstack/nova master: Mounting the shares as part of the initialization process https://review.opendev.org/c/openstack/nova/+/880075 | 20:50 |
| opendevreview | ribaudr proposed openstack/nova master: Deletion of associated share mappings on instance deletion https://review.opendev.org/c/openstack/nova/+/881472 | 20:50 |
| opendevreview | ribaudr proposed openstack/nova master: Add metadata for shares https://review.opendev.org/c/openstack/nova/+/850500 | 20:50 |
| opendevreview | ribaudr proposed openstack/nova master: Add share_info parameter to reboot method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/854823 | 20:50 |
| opendevreview | ribaudr proposed openstack/nova master: Support rebooting an instance with shares (compute manager part) https://review.opendev.org/c/openstack/nova/+/854824 | 20:50 |
| opendevreview | ribaudr proposed openstack/nova master: Add share_info parameter to resume method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/860284 | 20:50 |
| opendevreview | ribaudr proposed openstack/nova master: Support resuming an instance with shares (compute manager part) https://review.opendev.org/c/openstack/nova/+/860285 | 20:50 |
| opendevreview | ribaudr proposed openstack/nova master: Add helper methods to rescue/unrescue shares https://review.opendev.org/c/openstack/nova/+/860286 | 20:50 |
| opendevreview | ribaudr proposed openstack/nova master: Support rescuing an instance with shares https://review.opendev.org/c/openstack/nova/+/860287 | 20:51 |
| opendevreview | ribaudr proposed openstack/nova master: Allow to mount manila share using Cephfs protocol https://review.opendev.org/c/openstack/nova/+/883862 | 20:51 |
| opendevreview | ribaudr proposed openstack/nova master: Check shares support (compute manager) https://review.opendev.org/c/openstack/nova/+/885751 | 20:51 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (API) https://review.opendev.org/c/openstack/nova/+/836830 | 20:51 |
| opendevreview | ribaudr proposed openstack/nova master: Add helper methods to attach/detach shares https://review.opendev.org/c/openstack/nova/+/885753 | 20:51 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach notification https://review.opendev.org/c/openstack/nova/+/850501 | 20:51 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach notification https://review.opendev.org/c/openstack/nova/+/851028 | 20:51 |
| opendevreview | ribaudr proposed openstack/nova master: Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029 | 20:51 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach_error notification https://review.opendev.org/c/openstack/nova/+/860282 | 20:51 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach_error notification https://review.opendev.org/c/openstack/nova/+/860283 | 20:51 |
| opendevreview | ribaudr proposed openstack/nova master: Reports instance events to the DB regarding attaching and detaching a share https://review.opendev.org/c/openstack/nova/+/927088 | 20:51 |
| opendevreview | ribaudr proposed openstack/nova master: Add libvirt test to ensure metadata are working. https://review.opendev.org/c/openstack/nova/+/852086 | 20:51 |
| opendevreview | ribaudr proposed openstack/nova master: Add virt/libvirt error test cases https://review.opendev.org/c/openstack/nova/+/852087 | 20:51 |
| opendevreview | ribaudr proposed openstack/nova master: Manila shares admin guide documentation https://review.opendev.org/c/openstack/nova/+/871642 | 20:51 |
| sean-k-mooney | s3rj1k: its defiend as a HostDomainOpt type shich shoudl accpaate any ip, hostanem or fqdn | 20:51 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/conf/libvirt.py#L239-L254 | 20:51 |
| sean-k-mooney | https://github.com/openstack/oslo.config/blob/82552116f827030ce1e493506fe83ef71656e447/oslo_config/cfg.py#L1189 | 20:52 |
| s3rj1k | sean-k-mooney: yea, I see value in logs DEBUG nova.api.openstack.wsgi_app [-] libvirt.live_migration_inbound_addr = 10.42.71.101 {{(pid=205504)... | 20:54 |
| sean-k-mooney | wait where are you definign the values ? | 20:55 |
| sean-k-mooney | your putting them on the compute nodes nova.conf right | 20:55 |
| sean-k-mooney | for devstack this is called /etc/nova/nova-cpu.conf | 20:55 |
| s3rj1k | was putting it in nova.conf :( | 20:56 |
| s3rj1k | lemme check again | 20:56 |
| s3rj1k | ::facepalm | 20:58 |
| s3rj1k | well, in works | 20:59 |
| sean-k-mooney | with the revert rightt | 20:59 |
| s3rj1k | sean-k-mooney: sorry for that, yea, with revert | 20:59 |
| sean-k-mooney | so it woudl b einteresting if it fails if you drop the revert | 20:59 |
| sean-k-mooney | cause if so then that is the probelm and the fix | 20:59 |
| s3rj1k | hmm, lemme check | 21:00 |
| sean-k-mooney | no rush can you update the bug wiht your finding either way | 21:01 |
| sean-k-mooney | the revert is good to do anyway but i think im going to finish for today | 21:03 |
| s3rj1k | sean-k-mooney: yep, fails without revert | 21:06 |
| s3rj1k | i'll update bugreport | 21:06 |
| s3rj1k | done https://bugs.launchpad.net/nova/+bug/2086867/comments/5 | 21:10 |
| s3rj1k | thanks Sean! | 21:11 |
| sean-k-mooney | cool then lets proceed with the revert we can follow up with others to review tomrorow | 21:12 |
| s3rj1k | I'll also will revalidate that after merge on clean DevStack, just in case :) | 21:13 |
| sean-k-mooney | we may want to consider twakign ci to be able to test this but i think that is best left to a followup | 21:13 |
| *** tkajinam is now known as Guest9338 | 22:33 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!