| *** sapd1 has quit IRC | 00:07 | |
| *** zhanglong has joined #openstack-nova | 01:04 | |
| *** swp20 has joined #openstack-nova | 01:04 | |
| *** suryasingh has joined #openstack-nova | 01:14 | |
| *** Liang__ has joined #openstack-nova | 01:16 | |
| openstackgerrit | Keigo Noha proposed openstack/nova stable/ussuri: Change default num_retries for glance to 3 https://review.opendev.org/748936 | 01:18 |
|---|---|---|
| *** k_mouza has joined #openstack-nova | 01:19 | |
| *** k_mouza has quit IRC | 01:23 | |
| *** tony_su has joined #openstack-nova | 01:26 | |
| *** songwenping_ has joined #openstack-nova | 01:34 | |
| *** swp20 has quit IRC | 01:38 | |
| *** zhanglong has quit IRC | 01:46 | |
| *** sapd1 has joined #openstack-nova | 02:06 | |
| *** zhanglong has joined #openstack-nova | 02:06 | |
| openstackgerrit | Tony Su proposed openstack/nova master: Provider Config File: Coding style and test cases improvment https://review.opendev.org/748939 | 02:20 |
| openstackgerrit | Tony Su proposed openstack/nova master: Provider Config File: Coding style and test cases improvement https://review.opendev.org/748939 | 02:22 |
| *** rcernin has quit IRC | 02:58 | |
| *** rcernin has joined #openstack-nova | 03:19 | |
| *** ratailor has joined #openstack-nova | 03:48 | |
| *** zhanglong has quit IRC | 03:58 | |
| *** rcernin has quit IRC | 04:12 | |
| *** rcernin has joined #openstack-nova | 04:14 | |
| *** Liang__ has quit IRC | 04:20 | |
| *** evrardjp has quit IRC | 04:33 | |
| *** evrardjp has joined #openstack-nova | 04:33 | |
| *** vishalmanchanda has joined #openstack-nova | 04:35 | |
| *** sapd1 has quit IRC | 04:55 | |
| *** stephenfin has quit IRC | 05:35 | |
| *** sapd1 has joined #openstack-nova | 05:37 | |
| *** stephenfin has joined #openstack-nova | 05:42 | |
| *** stephenfin has quit IRC | 05:47 | |
| *** rcernin has quit IRC | 05:48 | |
| *** sapd1 has quit IRC | 05:54 | |
| *** stephenfin has joined #openstack-nova | 05:56 | |
| *** zhanglong has joined #openstack-nova | 05:59 | |
| *** stephenfin has quit IRC | 06:01 | |
| *** stephenfin has joined #openstack-nova | 06:02 | |
| *** rcernin has joined #openstack-nova | 06:03 | |
| *** stephenfin has quit IRC | 06:09 | |
| *** PrinzElvis has joined #openstack-nova | 06:10 | |
| *** sapd1 has joined #openstack-nova | 06:15 | |
| *** stephenfin has joined #openstack-nova | 06:16 | |
| *** jsuchome has joined #openstack-nova | 06:25 | |
| *** stephenfin has quit IRC | 06:27 | |
| *** sean-k-mooney1 has joined #openstack-nova | 06:27 | |
| *** stephenfin has joined #openstack-nova | 06:29 | |
| *** sean-k-mooney has quit IRC | 06:30 | |
| *** links has joined #openstack-nova | 06:44 | |
| *** PrinzElvis has quit IRC | 06:46 | |
| *** PrinzElvis has joined #openstack-nova | 06:46 | |
| *** stephenfin has quit IRC | 06:50 | |
| *** stephenfin has joined #openstack-nova | 06:57 | |
| *** ralonsoh has joined #openstack-nova | 07:01 | |
| *** PrinzElvis has quit IRC | 07:03 | |
| *** PrinzElvis has joined #openstack-nova | 07:03 | |
| *** stephenfin has quit IRC | 07:04 | |
| *** PrinzElvis has quit IRC | 07:07 | |
| *** PrinzElvis has joined #openstack-nova | 07:08 | |
| *** PrinzElvis has quit IRC | 07:10 | |
| *** PrinzElvis has joined #openstack-nova | 07:11 | |
| *** songwenping_ has quit IRC | 07:13 | |
| *** tesseract has joined #openstack-nova | 07:17 | |
| *** trident has quit IRC | 07:18 | |
| *** swp20 has joined #openstack-nova | 07:20 | |
| swp20 | gibi: hi gibi, morning. | 07:21 |
| swp20 | I have a question: As we donnot delete allocations when evacuate, so this case `nova.tests.functional.wsgi.test_services.TestServicesAPI.test_evacuate_then_delete_compute_service` is not reasonable, right? | 07:23 |
| *** sapd1 has quit IRC | 07:24 | |
| *** PrinzElvis has quit IRC | 07:30 | |
| *** PrinzElvis has joined #openstack-nova | 07:31 | |
| gibi | swp20: the source host allocation is not deleted during evacuation. It is left for the source host to delete it when it is recovered. If the source host is never recovered but deleted instead then we might need to delete the source side of the allocation of successfull evacuations | 07:35 |
| *** tosky has joined #openstack-nova | 07:39 | |
| gibi | swp20: alternatively we can reject the service delete if there is allocations against the RP due to finished evacuations | 07:40 |
| gibi | and ask the admin to clean that up manually before delete the service | 07:41 |
| swp20 | so how can we process the exception when we delete rp failed? we cannot raise the exception. | 07:41 |
| swp20 | please see the patch: https://review.opendev.org/#/c/748339/ | 07:42 |
| bauzas | good morning | 07:42 |
| gibi | swp20: I will check | 07:43 |
| gibi | bauzas: good morning | 07:43 |
| swp20 | gibi: thanks | 07:43 |
| *** zigo has joined #openstack-nova | 07:45 | |
| *** brinzhang has joined #openstack-nova | 07:49 | |
| *** rcernin has quit IRC | 07:51 | |
| suryasingh | @gibi hi... Sorry to address directly. Do you know if graceful shutdown of nova-compute is supported from nova side (For ex: like SIGTERM send to nova-compute to stopped in the middle of instance boot operation) | 07:54 |
| *** belmoreira has joined #openstack-nova | 07:57 | |
| *** PrinzElvis is now known as Prinz-Elvis | 07:58 | |
| gibi | suryasingh: hi! good questions. I'm not sure. | 07:59 |
| *** tosky has quit IRC | 08:00 | |
| *** jangutter has quit IRC | 08:00 | |
| *** purplerbot has quit IRC | 08:00 | |
| gibi | suryasingh: looking at the nova.service.Service impl, I don't see specific implementtin | 08:01 |
| gibi | nova.service.Service.stop just stops the RPC service and then calls manager.clean_up | 08:02 |
| *** irclogbot_0 has quit IRC | 08:02 | |
| *** ralonsoh_ has joined #openstack-nova | 08:02 | |
| gibi | we do cancel ongoing live migration though | 08:03 |
| gibi | via nova.compute.manager.ComputeManager._cleanup_live_migrations_in_pool | 08:03 |
| gibi | but I don't see any more gracefullness | 08:03 |
| *** ralonsoh has quit IRC | 08:03 | |
| *** ralonsoh_ has quit IRC | 08:03 | |
| *** Prinz-Elvis is now known as PrinzElvis | 08:04 | |
| *** tosky has joined #openstack-nova | 08:05 | |
| *** jangutter has joined #openstack-nova | 08:05 | |
| *** purplerbot has joined #openstack-nova | 08:05 | |
| *** PrinzElvis is now known as Prinz_Elvis | 08:05 | |
| suryasingh | I see gibi, Thanks for response though. | 08:05 |
| *** irclogbot_0 has joined #openstack-nova | 08:07 | |
| *** zhanglong has quit IRC | 08:08 | |
| *** zhanglong has joined #openstack-nova | 08:09 | |
| gibi | suryasingh: if you would need more gracefullness the I suggest to describe you use case in a mail on the mailing list or in a nova specification | 08:09 |
| *** avolkov has joined #openstack-nova | 08:09 | |
| suryasingh | gibi: thanks for info. I will do once feel require to mail. | 08:11 |
| bauzas | gibi: suryasingh: we just hook the SIGHUP signal | 08:12 |
| bauzas | hook up* | 08:12 |
| *** Prinz_Elvis is now known as PrinzElvis | 08:12 | |
| bauzas | we don't indeed have any other signal for a graceful restart | 08:12 |
| bauzas | but operators just disable the service before they restart | 08:13 |
| bauzas | so they don't need to wait | 08:13 |
| bauzas | gibi: IIRC, oslo.service also waits gracefully | 08:23 |
| brinzhang | gibi, stephenfin: Fixed stephenfin's comments inline in Cyborg evacuate patch, hope you can review again https://review.opendev.org/#/c/715326/ | 08:24 |
| bauzas | https://docs.openstack.org/oslo.service/ocata/history.html#id17 | 08:24 |
| bauzas | gibi: ^ | 08:24 |
| bauzas | suryasingh: ^ | 08:24 |
| frickler | bauzas: I have two question regarding https://bugs.launchpad.net/neutron/+bug/1861401: a) is "hostname is immutable" documented somewhere? nearest thing I found is https://bugs.launchpad.net/nova/+bug/1068154 | 08:25 |
| openstack | Launchpad bug 1861401 in OpenStack Compute (nova) "Renaming instance brokes DNS integration" [Low,Opinion] | 08:25 |
| openstack | Launchpad bug 1068154 in OpenStack Compute (nova) "Renaming Instance Name doesn't change hostname on a Rebuild" [Wishlist,Opinion] | 08:25 |
| frickler | and b: is it possible to retrieve the original hostname via the API? | 08:25 |
| bauzas | suryasingh: gibi: https://docs.openstack.org/oslo.service/latest/reference/service.html#oslo_service.service.Service.stop | 08:26 |
| bauzas | frickler: looking | 08:26 |
| suryasingh | bauzas: thanks for heads up, sorry i couldn't get much. How disabling benefits in graceful shutdown ? >> so they don't need to wait ? | 08:27 |
| bauzas | suryasingh: by disabling the service, you avoid having instances be going to it | 08:28 |
| suryasingh | bauzas: yes that's correct | 08:28 |
| bauzas | suryasingh: so, then, when restarting the compute service, the instances are not restarted | 08:28 |
| frickler | bauzas: ah, for b) I found OS-EXT-SRV-ATTR:hostname, though it's admin-only by default, which kind of restricts it's usefulness | 08:29 |
| bauzas | frickler: corrrect, but you can change the policy | 08:30 |
| bauzas | frickler: I mean, it's a cloud API, right ? :) | 08:30 |
| bauzas | so that's why it's defaulted to No | 08:30 |
| suryasingh | bauzas: what about on going instance booting process, suppose i disabled the nova-compute even before nova-compute gets net-id, or requested volume or object from other openstack services (neutron, cinder, swift) | 08:31 |
| bauzas | frickler: for the first question, it's because we have persisted objects that use the name for knowing which compute they are related | 08:31 |
| bauzas | so, changing it would mean that you should also have to change the objects too | 08:32 |
| *** derekh has joined #openstack-nova | 08:32 | |
| bauzas | frickler: it's possible I think, and maybe some operators have some tools for it | 08:33 |
| frickler | bauzas: I don't question why it is immutable, I'd just like to see that clearly documented, so I can point people to it | 08:33 |
| frickler | bauzas: for the API I do question why the default is admin-only, though, because that data seems to be readily available via metadata | 08:34 |
| bauzas | frickler: ahah good point | 08:34 |
| gibi | bauzas: would that service stop wait for every eventlet thread to finish too? that would mean a sort-of gracefull shutdown then | 08:34 |
| bauzas | frickler: you get the hostname thru the metadata API, really ? | 08:34 |
| gibi | bauzas: I guess suryasingh or me could try in devstack to see what happens with on the fly spawns | 08:35 |
| bauzas | gibi: I'm not an oslo.service expert, but I'd think it does | 08:35 |
| bauzas | gibi: that's what I'd expect at least | 08:35 |
| bauzas | (the service wait) | 08:35 |
| frickler | bauzas: http://169.254.169.254/latest/meta-data/hostname gives me the original hostname, not the changed (display_)name, yes | 08:36 |
| bauzas | eeek | 08:38 |
| frickler | oh, wait, is that an even different hostname? | 08:38 |
| * bauzas goes looking at the metadata API ref | 08:38 | |
| bauzas | frickler: wait | 08:40 |
| bauzas | frickler: hostname will give you the display_name of the instance VM I'd say | 08:40 |
| bauzas | that's what I'd expect | 08:40 |
| bauzas | at least it's what EC2 Metadata format will give you https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html | 08:41 |
| bauzas | https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-categories.html => | 08:42 |
| bauzas | hostname The private IPv4 DNS hostname of the instance. In cases where multiple network interfaces are present, this refers to the eth0 device (the device for which the device number is 0). | 08:42 |
| bauzas | 08:42 | |
| frickler | bauzas: nope, those data seem immutable in my test, too (rocky). the openstack meta_data.json gives "hostname": "oldname.novalocal", "name": "newname" | 08:44 |
| frickler | which is consistent with how neutron seems to handle dns at least | 08:45 |
| bauzas | frickler: lemme rephrase, this hostname value matches the original instance name, not the compute service hostname | 08:52 |
| openstackgerrit | Mamduh proposed openstack/os-vif master: Refactor code of linux_net to more cleaner and increase performace https://review.opendev.org/746673 | 08:55 |
| *** sapd1 has joined #openstack-nova | 08:59 | |
| frickler | bauzas: not sure what you mean by "compute service hostname". the metadata matches the original instance name and OS-EXT-SRV-ATTR:hostname, not the new instance name | 09:06 |
| *** trident has joined #openstack-nova | 09:08 | |
| openstackgerrit | Akhil Gudise proposed openstack/nova master: Moved all calls from _ENFORCER.authorize to a separate _authorize method https://review.opendev.org/739460 | 09:08 |
| bauzas | frickler: okay, my bad, I see the confusion | 09:08 |
| gibi | swp20: left comment in https://review.opendev.org/#/c/748339 | 09:09 |
| bauzas | frickler: I thought you were asking whether the compute service hostame was immutable | 09:09 |
| bauzas | I'm tired | 09:09 |
| bauzas | you asked about the instance hostname | 09:09 |
| bauzas | and yeah, this is immutable, users can only change the display_name field | 09:10 |
| bauzas | frickler: I apologize | 09:10 |
| bauzas | which is consistent with what you get from the metadata API | 09:10 |
| bauzas | now, back to your original question, where it is documented, I'm doublechecking things | 09:10 |
| *** dtantsur|afk is now known as dtantsur | 09:11 | |
| *** sapd1 has quit IRC | 09:11 | |
| bauzas | frickler: first, the API fields are documented here https://docs.openstack.org/api-ref/compute/?expanded=list-servers-detailed-detail#id21 | 09:12 |
| bauzas | and the "name" field is actually the display_name fiedl | 09:12 |
| *** brinzhang has quit IRC | 09:16 | |
| -openstackstatus- NOTICE: due to a new release of setuptools (50.0.0), a lot of jobs are currently broken, please do not recheck blindly. see http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016905.html | 09:17 | |
| *** brinzhang has joined #openstack-nova | 09:19 | |
| frickler | bauzas: "The hostname set on the instance when it is booted." if one interprets "booted" as "created", that would almost do it, I guess | 09:28 |
| swp20 | gibi: thanks for review. | 09:29 |
| bauzas | frickler: agreed, fancy fixing the api ref ? | 09:29 |
| frickler | bauzas: related strangeness: while the API seems to allow to filter the server list based on instance hostname, "openstack server list --host $hostname" actually seems to filter on hypervisor_hostname | 09:29 |
| bauzas | frickler: hence my confusion | 09:29 |
| bauzas | in nova, host generally refers to the compute service hostname | 09:29 |
| frickler | bauzas: ah, I see. I can do a patch for the api-ref, yes | 09:30 |
| bauzas | frickler: and fwiw, we have OS-EXT-SRV-ATTR:host which gives you the compute service hostname | 09:31 |
| bauzas | see the problem ? :) | 09:31 |
| frickler | bauzas: yeah, nice semantic overload, "name of the host" vs. "(DNS) hostname of the instance" | 09:32 |
| bauzas | that's what happens when you're bugged on a Monday morning :) | 09:32 |
| *** brinzhang_ has joined #openstack-nova | 09:37 | |
| *** brinzhang has quit IRC | 09:40 | |
| *** swp20 has quit IRC | 09:43 | |
| *** swp20 has joined #openstack-nova | 09:43 | |
| *** ralonsoh has joined #openstack-nova | 09:43 | |
| *** brinzhang_ has quit IRC | 09:52 | |
| bauzas | sean-k-mooney1: gibi: you're more experts than me on the network side, but I'm facing a small issue with the routed networks implementation | 10:00 |
| bauzas | sean-k-mooney1: gibi: I only get the list of physnets from the requestspec when I'm in a prefilter, so instead of querying the list of segments from the network id or the port id, I was about to query neutron to give me the list of segments related to the physnets I got | 10:01 |
| bauzas | sean-k-mooney1: gibi: do you think it's valid ? IMHO, it is. | 10:01 |
| bauzas | sean-k-mooney1: gibi: this would even allow us to not care whether we were passed a port or a network like mriedem implemented in his WIP https://review.opendev.org/#/c/656885/7/nova/scheduler/utils.py@1379 | 10:03 |
| *** jangutter has quit IRC | 10:04 | |
| *** jangutter has joined #openstack-nova | 10:05 | |
| *** ralonsoh has quit IRC | 10:10 | |
| *** ralonsoh has joined #openstack-nova | 10:10 | |
| *** tosky has quit IRC | 10:13 | |
| *** tosky has joined #openstack-nova | 10:13 | |
| *** stephenfin has joined #openstack-nova | 10:20 | |
| *** zhanglong has quit IRC | 10:22 | |
| *** Luzi has joined #openstack-nova | 10:35 | |
| * bauzas goes off for lunch | 10:37 | |
| *** jangutter_ has joined #openstack-nova | 10:41 | |
| sean-k-mooney1 | bauzas: one sec | 10:42 |
| sean-k-mooney1 | bauzas: need to read that a couple of times :) | 10:42 |
| sean-k-mooney1 | still drinking moring coffee | 10:43 |
| *** brinzhang has joined #openstack-nova | 10:43 | |
| sean-k-mooney1 | not sure the request spec is correct | 10:43 |
| *** jangutter has quit IRC | 10:44 | |
| sean-k-mooney1 | i need to look at where the request spec gets its physnet info | 10:44 |
| sean-k-mooney1 | if its getting it for the nova vif objects then that is not correct | 10:45 |
| sean-k-mooney1 | the nova vif object just use the first physnet form a network not the physnet corresponding to the segment | 10:45 |
| brinzhang | stephenfin: https://review.opendev.org/#/c/715326/27/api-guide/source/accelerator-support.rst@56 | 10:46 |
| *** sean-k-mooney1 is now known as sean-k-mooney | 10:47 | |
| brinzhang | stephenfin: In https://releases.openstack.org/victoria/ we are not update the nova version for Victoria, do you need to keep use ussuri version 21.1.0? | 10:47 |
| stephenfin | brinzhang: You mean there's no 22.0.0 release yet? | 10:48 |
| stephenfin | That makes sense. It hasn't been released. You're writing these docs for when it *is* released | 10:48 |
| brinzhang | stephenfin: yes | 10:48 |
| brinzhang | aha, I think yes, it make sense | 10:49 |
| sean-k-mooney | brinzhang: we only ever use the major version in the release notes | 10:49 |
| stephenfin | Yeah, when writing things like the 'versionchanged' directive, you give the first version the change is *included* in | 10:50 |
| stephenfin | Leaving aside the major/minor thing, 21.1.0 has been released and it clearly wasn't included there :) | 10:50 |
| sean-k-mooney | if we were fixing a bug caused by a backport i guess that could be an excpetion | 10:50 |
| brinzhang | sean-k-mooney: yeah, ack. We were marked this, and it is reasonable in the docs, when the use to use this feature, it's belong to the 22.0.0 | 10:51 |
| sean-k-mooney | but i dont think we have used a minor verion in the past | 10:51 |
| stephenfin | sean-k-mooney: yeah, sure. I don't think we have used it though | 10:51 |
| stephenfin | yeah | 10:51 |
| brinzhang | sean-k-mooney, stephenfin: do we need to backport this to Ussuri? | 10:52 |
| stephenfin | you can't | 10:53 |
| stephenfin | there's a service version bump | 10:53 |
| stephenfin | not backportable | 10:53 |
| brinzhang | ack ^ | 10:53 |
| brinzhang | stepheinfin, gibi, sean-k-mooney: will udpate this patch later, thanks for your review, it's getting closer and closer to closing | 10:55 |
| stephenfin | yup, we'll have this landed by end of the week, for sure | 10:55 |
| gibi | ^^ +1 | 10:56 |
| sean-k-mooney | stephenfin: oslo lib freeze was on thursday its one week before the non-client lib freeze which is this thursday | 10:57 |
| stephenfin | gibi, bauzas: We discussed dropping support for the untested libvirt hypervisors at the PTG. Any chance you could review these patches at some point this week since I don't think we can merge after M3? https://review.opendev.org/#/q/topic:bp/remove-deprecated-libvirt-virt-types+status:open | 10:58 |
| sean-k-mooney | i try to have a potential "release candiate" on the oslo freeze if i can but we havnt this time | 10:58 |
| sean-k-mooney | so we still have till thrusday for os-vif | 10:58 |
| stephenfin | sean-k-mooney: okay, good to hear | 10:58 |
| gibi | stephenfin: add those to my queue now | 10:58 |
| stephenfin | \o/ Great, thanks :) | 10:59 |
| sean-k-mooney | i normally like to have that week to see if neutron or nova shake out something and still have time to fix it before the non-client lib freeze | 10:59 |
| sean-k-mooney | anyway updating the os-vif patch now | 10:59 |
| *** eharney has quit IRC | 10:59 | |
| *** jangutter has joined #openstack-nova | 11:00 | |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Update references to image properties https://review.opendev.org/744198 | 11:02 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Drop support for UML https://review.opendev.org/743230 | 11:02 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Drop support for Xen https://review.opendev.org/743231 | 11:02 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Remove 'hypervisor_version' from 'libvirt_info' https://review.opendev.org/744199 | 11:02 |
| sean-k-mooney | stephenfin: i do remember i was ment to create a ci for libvirt lxc but have not :( | 11:02 |
| sean-k-mooney | oh your droping uml and xen | 11:02 |
| sean-k-mooney | im ok with that | 11:02 |
| stephenfin | Yeah, I've left dropping that one for another cycle at least | 11:03 |
| *** jangutter_ has quit IRC | 11:03 | |
| sean-k-mooney | ill see if i can create the ci between m3 and rc1 | 11:03 |
| sean-k-mooney | if not ill submit a deprecation patch for it. | 11:04 |
| sean-k-mooney | oh speaking of which | 11:04 |
| sean-k-mooney | if i fix https://review.opendev.org/#/c/745605/ today/tomorrow to deprecate the compute an az filter can we still merge that this release | 11:05 |
| stephenfin | I don't see why not | 11:05 |
| sean-k-mooney | ok it would be nice to be able to remove those next cycle or at least have the option too | 11:06 |
| *** eharney has joined #openstack-nova | 11:12 | |
| *** jangutter has quit IRC | 11:15 | |
| *** jangutter has joined #openstack-nova | 11:16 | |
| *** elod has quit IRC | 11:27 | |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: Further usage of new server helpers https://review.opendev.org/743204 | 11:32 |
| openstackgerrit | Stephen Finucane proposed openstack/nova stable/ussuri: Add a lock to prevent race during detach/attach of interface https://review.opendev.org/749033 | 11:32 |
| openstackgerrit | yatin proposed openstack/nova master: Revert "Rebase qcow2 images when unshelving an instance" https://review.opendev.org/749035 | 11:36 |
| gibi | bauzas: based on https://review.opendev.org/#/c/656885/7/nova/scheduler/utils.py@1322 I think your observation is valid. We know the requested network (or port but then that is translated back to network) and then we can query neutron for a list of segments in that network | 11:37 |
| sean-k-mooney | gibi: right we have to query neutron | 11:37 |
| sean-k-mooney | gibi: i think bauzas was suggesting we woudl have physnets in the request spec | 11:37 |
| sean-k-mooney | but those would be incorrect if present | 11:38 |
| sean-k-mooney | if you have multiple phsynets associated with a network nova only stores the frist in the vif object | 11:38 |
| gibi | yeah, I don't think we have physnets there. But somewhere we have physnets | 11:38 |
| gibi | yes, I remember now that we only check for the first physnet when walking the segments | 11:39 |
| sean-k-mooney | right but they are only correct if the network has only one physnet | 11:39 |
| sean-k-mooney | gibi: yep its a hack that we never fixed | 11:39 |
| sean-k-mooney | fixing it is non trivial for the sriov case | 11:40 |
| sean-k-mooney | the pci tracker cant currently take a list of physnets | 11:40 |
| gibi | yes, agreee | 11:40 |
| sean-k-mooney | so we cant say find a vf with any of these phsnets currently | 11:40 |
| sean-k-mooney | i think the same would apply for bandwith requests | 11:41 |
| sean-k-mooney | so i think looping over the requested netwroks is valid | 11:41 |
| gibi | agree too | 11:42 |
| sean-k-mooney | but we still need to ask neuton for the list of segments | 11:42 |
| sean-k-mooney | we could maybe cache that if we considered it to be expensive with a time based cache | 11:42 |
| sean-k-mooney | e.g. cache it with a hard time out of say 5 minutes | 11:43 |
| sean-k-mooney | its something we expect to change very seldomly | 11:43 |
| sean-k-mooney | but that can be done later if needed | 11:44 |
| gibi | yeah, that could be an optimization. Still this is a single http request per network. | 11:45 |
| gibi | so should not be that expensive | 11:45 |
| swp20 | stephenin: hi, what do you means by https://review.opendev.org/#/c/715326/22..27/nova/compute/manager.py@3281 | 11:45 |
| sean-k-mooney | well not quite | 11:45 |
| sean-k-mooney | we have to get teh list of segments form the network | 11:45 |
| *** links has quit IRC | 11:45 | |
| sean-k-mooney | then we need to get the phsynets form the segments in a different part of the code | 11:45 |
| sean-k-mooney | so its 1 call for the segments and a second per segment for the segment details | 11:46 |
| gibi | yeah you are right there are two different places where we query segments | 11:47 |
| gibi | there the cache make more sense | 11:47 |
| sean-k-mooney | the segment details are what i think could be cached | 11:47 |
| sean-k-mooney | the segments per network im not sure needs to be | 11:48 |
| brinzhang | stephenfin: hi, what do you means by https://review.opendev.org/#/c/715326/27/nova/compute/manager.py@3281 | 11:48 |
| sean-k-mooney | gibi: anyway we can cross that bridge later | 11:48 |
| gibi | yepp, totally agree | 11:49 |
| *** elod has joined #openstack-nova | 11:52 | |
| bauzas | sean-k-mooney: gibi: I'm just back, looking above | 12:01 |
| bauzas | sean-k-mooney: gibi: okay, lemme provide the implementation today, you'll see my question | 12:02 |
| gibi | sure | 12:03 |
| * bauzas just wonders how to use a Neutron API instance in the scheduler request filter method | 12:03 | |
| bauzas | (I mean the client) | 12:03 |
| gibi | bauzas: I guess the previous patch did not try to call neutron from the request filter, but did the data collection earlier and stored the requested aggregate info in request_spec.request_level_params.member_of.append | 12:06 |
| gibi | neutron was queried in conductor https://review.opendev.org/#/c/656885/7/nova/conductor/manager.py | 12:07 |
| bauzas | gibi: yep, but you'll see I don't use it | 12:07 |
| bauzas | instead, I use a new request filter method and I use the requested destination object for passing the aggregates | 12:08 |
| bauzas | but meh, you'll see | 12:08 |
| gibi | OK, I will check | 12:10 |
| *** raildo has joined #openstack-nova | 12:12 | |
| openstackgerrit | Merged openstack/nova master: doc: Update references to image properties https://review.opendev.org/744198 | 12:15 |
| gibi | stephenfin: do we actively reject img_hv_type=uml after https://review.opendev.org/#/c/743230/4 ? | 12:28 |
| *** lbragstad_ has joined #openstack-nova | 12:32 | |
| sean-k-mooney | gibi: stephenfin did not update teh nova object | 12:33 |
| sean-k-mooney | so the image property wont reject it | 12:33 |
| *** redrobot has joined #openstack-nova | 12:34 | |
| gibi | sean-k-mooney: but then what will happen? NoValidHost? | 12:34 |
| sean-k-mooney | its still here https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/fields.py#L405 | 12:35 |
| sean-k-mooney | well you cant set the uml virt type anymore since the config is updated | 12:36 |
| sean-k-mooney | it looks like this was only used in https://opendev.org/openstack/nova/src/branch/master/nova/scheduler/filters/image_props_filter.py#L55 | 12:38 |
| sean-k-mooney | so since there are no hosts with that hypervior type | 12:39 |
| gibi | as this is an image property UML still can be requested from the image. But then I guess it will simply result in a NoValidHost | 12:39 |
| *** lbragstad_ has quit IRC | 12:39 | |
| sean-k-mooney | then ya | 12:39 |
| gibi | OK cool | 12:39 |
| sean-k-mooney | you will get a novalid host | 12:39 |
| sean-k-mooney | we proably should also update the field definiton to make that invalid | 12:39 |
| sean-k-mooney | which requires a slightly differnt approch where we raise an excption in obj_make_compatiable instead of just droping it | 12:41 |
| sean-k-mooney | like this https://opendev.org/openstack/nova/src/branch/master/nova/objects/image_meta.py#L191-L197 | 12:41 |
| gibi | yeah, that could be done as a follow up cleanup I guess | 12:41 |
| sean-k-mooney | ya its not strictly required i guess. but the valuse wont be vaild anymore | 12:42 |
| sean-k-mooney | it might make sense to have only one object bump for both | 12:42 |
| sean-k-mooney | although i can see a counter argument to be made that you might continue to support uml with an out of tree driver or something | 12:43 |
| gibi | agree on a single bump for multiple removals | 12:43 |
| sean-k-mooney | uml is unlikly to do that | 12:43 |
| sean-k-mooney | xen might be more likely | 12:43 |
| sean-k-mooney | although we are keeping libvirt-xen right | 12:43 |
| sean-k-mooney | and jut removing xex server | 12:43 |
| sean-k-mooney | *xen-server | 12:44 |
| sean-k-mooney | the standalone xen driver or are we removing both | 12:44 |
| gibi | we are removing libvirt+xen not the standalone xenserver | 12:44 |
| *** mgariepy has quit IRC | 12:45 | |
| sean-k-mooney | isnt the standalone xenapi the one we wanted to remove | 12:45 |
| sean-k-mooney | libvit xen proably still works | 12:45 |
| sean-k-mooney | xenapi was the one with issues | 12:45 |
| sean-k-mooney | given it still needed pyton 2.6 like a year ago | 12:45 |
| sean-k-mooney | oh the xen server side | 12:46 |
| sean-k-mooney | oh we are doing both | 12:47 |
| gibi | sean-k-mooney: you are right. that is a big -1 for stephenfin :) | 12:47 |
| sean-k-mooney | https://etherpad.opendev.org/p/nova-victoria-ptg | 12:47 |
| sean-k-mooney | lines 377 is the libvirt support | 12:47 |
| sean-k-mooney | and 386 is xenapi | 12:47 |
| sean-k-mooney | so we are ment to be deleteing xenapi | 12:47 |
| sean-k-mooney | and deprecating xen an uml | 12:48 |
| *** mgariepy has joined #openstack-nova | 12:48 | |
| sean-k-mooney | not deleting them | 12:48 |
| sean-k-mooney | gibi: so stephen is jumping the gun with the deletions | 12:48 |
| sean-k-mooney | victoria is deprecation | 12:49 |
| sean-k-mooney | for the libvirt backends and deletion for xenapi | 12:49 |
| sean-k-mooney | stephenfin: ^ | 12:49 |
| *** ratailor has quit IRC | 12:49 | |
| gibi | I added the necessary -1s now. Thanks for catching this Sean | 12:50 |
| openstackgerrit | Brin Zhang proposed openstack/nova master: Cyborg evacuate support https://review.opendev.org/715326 | 12:51 |
| *** raildo has quit IRC | 12:51 | |
| sean-k-mooney | so did i :) | 12:52 |
| *** lpetrut has joined #openstack-nova | 12:52 | |
| sean-k-mooney | gibi: on the plus side since stephenfin has written the patches those are easy to merge in early wallaby | 12:53 |
| gibi | yeah, but first we have to merge some deprecation patches for these | 12:53 |
| sean-k-mooney | yep | 12:53 |
| sean-k-mooney | while i have your attention there is a revert of one of aarents patches proposed https://review.opendev.org/#/c/749035/1 | 12:54 |
| sean-k-mooney | i dont see how we can be getting None also the ci really does not like the revert for some reason | 12:54 |
| *** lbragstad has joined #openstack-nova | 12:55 | |
| sean-k-mooney | but apprenlty this is failing in rdo | 12:55 |
| sean-k-mooney | im not sure if it was a one off failure or if its blocking there gate | 12:55 |
| sean-k-mooney | https://bugs.launchpad.net/tripleo/+bug/1893618 | 12:55 |
| openstack | Launchpad bug 1893618 in tripleo "periodic-tripleo-ci-centos-8-scenario000-multinode-oooq-container-updates-ussuri tempest test_shelve_unshelve_server failing in component-pipeline " [Critical,Triaged] | 12:55 |
| gibi | looking... | 12:55 |
| *** maciejjozefczyk has joined #openstack-nova | 12:55 | |
| sean-k-mooney | for some reason instance.system_metadata.get('image_base_image_ref') is retruning none | 12:57 |
| sean-k-mooney | but we set that in exactly one place and i dont really see how it can be none as that implies the instace has no image | 12:57 |
| sean-k-mooney | which makes no sense for a qcow backed vm | 12:57 |
| *** links has joined #openstack-nova | 12:58 | |
| sean-k-mooney | actully from the pre shelve xml i can see <nova:root type="image" uuid="5cc451d5-7abe-478a-9f4f-1a804f49a3f3"/> | 13:00 |
| *** raildo has joined #openstack-nova | 13:00 | |
| sean-k-mooney | so its implying that the system_metadata table is populated incorrectly or instance.system_metadata does not have all the info at this point | 13:01 |
| sean-k-mooney | its really strange because i would have expected this to work | 13:01 |
| stephenfin | gibi, sean-k-mooney: I think those notes are wrong. Have we not already in-effect deprecated them? https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L606-L614 | 13:02 |
| sean-k-mooney | no | 13:03 |
| sean-k-mooney | testing is differnt | 13:03 |
| sean-k-mooney | they are not deprecated yet | 13:03 |
| sean-k-mooney | unless you can point to a release note | 13:03 |
| sean-k-mooney | for what its worth i did not think we planned on removing support for any libvirt backends this cycle just deprecations the only removals were going to be xenapi and vmware | 13:05 |
| sean-k-mooney | vmware have now fixed the ci | 13:05 |
| *** maciejjozefczyk has quit IRC | 13:05 | |
| sean-k-mooney | so they have been undeprecated? | 13:06 |
| sean-k-mooney | i know gibi has a patch for that at least | 13:06 |
| sean-k-mooney | stephenfin: if we just use that waring as a depercation warning then all of libvirt arm and power support would be deprecated and its not | 13:07 |
| *** bnemec has joined #openstack-nova | 13:07 | |
| gibi | that warning was added 7 years ago https://review.opendev.org/#/c/69919/ | 13:08 |
| gibi | I agree with sean-k-mooney here to state the deprecation explicitly for these first | 13:09 |
| stephenfin | Okay, fair. I'll do that now and -W what's there for another few months | 13:09 |
| stephenfin | Thanks for the reviews :) | 13:09 |
| sean-k-mooney | :) | 13:09 |
| gibi | sean-k-mooney: vmware undeprecation is still open https://review.opendev.org/#/c/742407/ but I think we have a good chance to merge that | 13:10 |
| gibi | dansmith: could you check back to the vmware undeprecation patch ^^ ? | 13:12 |
| openstackgerrit | Brin Zhang proposed openstack/nova master: Refactor check and exception https://review.opendev.org/749052 | 13:13 |
| openstackgerrit | Jiri Suchomel proposed openstack/nova master: Add ability to download Glance images into the libvirt image cache via RBD https://review.opendev.org/574301 | 13:16 |
| *** artom has joined #openstack-nova | 13:17 | |
| gibi | sean-k-mooney: I have no idea how image_base_image_ref can be None for a qcow2 instance | 13:19 |
| gibi | sean-k-mooney: we should make a reproduction of the tripleo test case | 13:19 |
| *** jangutter has quit IRC | 13:20 | |
| *** jangutter has joined #openstack-nova | 13:20 | |
| openstackgerrit | Brin Zhang proposed openstack/nova master: Refactor check and exception https://review.opendev.org/749052 | 13:22 |
| sean-k-mooney | gibi: it failed on one of your patches too | 13:24 |
| sean-k-mooney | https://review.opendev.org/#/c/739246/ | 13:24 |
| sean-k-mooney | http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22_finalize_unshelve_qcow2_image%5C%22&from=30d | 13:24 |
| sean-k-mooney | there are only 2 hits in logstach so far in the last month | 13:25 |
| openstackgerrit | Wenping Song proposed openstack/nova master: Reject resize operation for accelerator https://review.opendev.org/748560 | 13:25 |
| *** jangutter has quit IRC | 13:26 | |
| *** jangutter has joined #openstack-nova | 13:26 | |
| *** jangutter has quit IRC | 13:27 | |
| *** jangutter has joined #openstack-nova | 13:28 | |
| sean-k-mooney | gibi: so apparently the filed is not set in the system metadata | 13:29 |
| *** jangutter has quit IRC | 13:29 | |
| *** jangutter has joined #openstack-nova | 13:29 | |
| gibi | so we have a tempes test that can reproduce the problem but it only does it really infrequently | 13:32 |
| *** lemko has quit IRC | 13:33 | |
| gibi | sean-k-mooney: nope, the error that was in my patch has a different stack trace https://zuul.opendev.org/t/openstack/build/de80ec8f00204a92b5e667bdf7a72cee/log/controller/logs/screen-n-cpu.txt#24116 | 13:37 |
| *** lemko has joined #openstack-nova | 13:38 | |
| gibi | also the another nova hit in kibana is different too https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_990/739246/3/check/tempest-integrated-compute/990dace/controller/logs/screen-n-cpu.txt | 13:38 |
| sean-k-mooney | gibi: kibana found that error too however | 13:39 |
| sean-k-mooney | on patchset 3 and 4 | 13:39 |
| gibi | the two error I see in kibana on review 739246 have different stack traces | 13:40 |
| sean-k-mooney | oh they do | 13:40 |
| gibi | it does hit _finalize_unshelve_qcow2_image but different way | 13:41 |
| sean-k-mooney | just the same function | 13:41 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Drop support for UML https://review.opendev.org/743230 | 13:41 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Drop support for Xen https://review.opendev.org/743231 | 13:41 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Remove 'hypervisor_version' from 'libvirt_info' https://review.opendev.org/744199 | 13:41 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Deprecate support for non-QEMU/KVM backends https://review.opendev.org/749055 | 13:41 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Remove '[vnc] keymap', '[spice] keymap' options https://review.opendev.org/749056 | 13:41 |
| gibi | one of the errors I even recognize as a rebase issue from my patch | 13:41 |
| stephenfin | sean-k-mooney: gibi: There you go. I'll mark the actual removal patch as -W for six months or so, heh | 13:41 |
| gibi | stephenfin: thanks | 13:42 |
| gibi | stephenfin: if you are itcign for a real removal then the xenserver driver can be removed I tihnk :) | 13:43 |
| stephenfin | Sure, if you're happy to review it, I'm happy to do it :) | 13:43 |
| dansmith | gibi: the ciwatch page shows more red than green for vmware lately, but I'm not sure how to figure out what is failing because the log dump isn't complete | 13:44 |
| gibi | stephenfin: sure, why not | 13:44 |
| dansmith | gibi: oh actually, I guess I'm missing a bunch of green to the right | 13:44 |
| gibi | dansmith: looking.. | 13:45 |
| dansmith | but I'm not sure what to make of the fails that have no logs, maybe those are aborts due to a new patch rev going up or something? | 13:45 |
| dansmith | okay, I found a fail that looks like a real fail, so I dunno what those other ones are, if not aborts | 13:46 |
| dansmith | I just wanted to find something that looks like a real failure to contrast it to a passing run, and also to make sure it's actually reporting failures | 13:47 |
| gibi | yeah, me neither | 13:47 |
| gibi | I'm trying to figure out if Yingji Sun or jhui@vmware.com is on IRC or not | 13:48 |
| gibi | so we can ask them | 13:48 |
| *** Luzi has quit IRC | 13:51 | |
| *** ratailor has joined #openstack-nova | 13:52 | |
| sean-k-mooney | dansmith: they might be hitting the same keystone error that is breaking the first party ci | 13:53 |
| dansmith | sean-k-mooney: and reporting empty logs? seems weird, but okay | 13:54 |
| sean-k-mooney | well no that is likely another issue | 13:55 |
| sean-k-mooney | i just noticed they started failing when the upstream jobs also started failng | 13:55 |
| *** jangutter has quit IRC | 13:56 | |
| *** nweinber has joined #openstack-nova | 13:56 | |
| *** jangutter has joined #openstack-nova | 13:56 | |
| *** Liang__ has joined #openstack-nova | 13:57 | |
| *** kevinz has quit IRC | 13:59 | |
| sean-k-mooney | hum the hyperv ci also seams to be broken | 14:00 |
| sean-k-mooney | its been red for at least the last 7 days | 14:00 |
| *** brinzhang has quit IRC | 14:05 | |
| *** eharney has quit IRC | 14:14 | |
| *** sapd1 has joined #openstack-nova | 14:24 | |
| *** eharney has joined #openstack-nova | 14:27 | |
| *** belmoreira has quit IRC | 14:30 | |
| *** Liang__ has quit IRC | 14:31 | |
| openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Add a routed networks scheduler pre-filter https://review.opendev.org/749068 | 14:33 |
| bauzas | gibi: sean-k-mooney: there it is ^ | 14:33 |
| *** dklyle has joined #openstack-nova | 14:35 | |
| *** jangutter_ has joined #openstack-nova | 14:35 | |
| bauzas | gibi: sean-k-mooney: I now use a pre-filter that looks at the existing physnets that were provided by https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2082 | 14:36 |
| *** openstackgerrit has quit IRC | 14:37 | |
| *** gibi has quit IRC | 14:37 | |
| *** gibi has joined #openstack-nova | 14:37 | |
| *** jangutter has quit IRC | 14:39 | |
| bauzas | I mean the network metadata that isn't persisted in the spec object but reused by every move operation | 14:39 |
| *** ratailor has quit IRC | 14:40 | |
| *** dklyle has quit IRC | 14:45 | |
| *** links has quit IRC | 14:50 | |
| *** spatel has joined #openstack-nova | 14:53 | |
| *** jangutter_ has quit IRC | 15:02 | |
| *** jangutter has joined #openstack-nova | 15:02 | |
| *** mriedem has joined #openstack-nova | 15:04 | |
| gibi | bauzas: then I think you have to resolve TODO in the codepath that gather the physnets https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/network/neutron.py#L2020 | 15:08 |
| gibi | as today it only get one physnet per network, even if there are multiple | 15:09 |
| bauzas | holy shit. | 15:09 |
| *** lpetrut has quit IRC | 15:11 | |
| bauzas | gibi: in a meeting | 15:14 |
| *** belmoreira has joined #openstack-nova | 15:14 | |
| *** lpetrut has joined #openstack-nova | 15:20 | |
| bauzas | gibi: actually, looking at vladik's comment, I'm not expert, but do we really support multiple networks per vlans? | 15:25 |
| bauzas | multiple physnets* | 15:25 |
| gibi | as far as I know in neutron nothing prevents you to create two vlan segments with different physnets in the same network | 15:27 |
| *** spatel has quit IRC | 15:29 | |
| bauzas | gibi: okay, then I don't feel enough expert to fix this TODO | 15:47 |
| bauzas | gibi: the other way would be to find a way to pass requested networks down in the request spedc | 15:48 |
| bauzas | spec* | 15:48 |
| bauzas | which is something we don't do | 15:48 |
| gibi | the way the pervious patches did it was to pass the aggregates via request_spec.request_level_params.member_of | 15:49 |
| gibi | and do the network segment -> host aggregate translation in an upper layer (conductor) | 15:50 |
| bauzas | gibi: I know | 15:50 |
| bauzas | but a pre-filter is better, right? | 15:50 |
| bauzas | and we don't need to pass the aggregates by a new field | 15:50 |
| bauzas | the destination object already contains what we need | 15:51 |
| gibi | this is still a pre-filter as the aggregate filterin happens in the a_c query | 15:51 |
| gibi | also I don't think request_spec.request_level_params.member_of is a new field at all | 15:51 |
| bauzas | gibi: matt added it | 15:52 |
| gibi | the member_of parts? | 15:52 |
| gibi | that could be | 15:52 |
| gibi | but the request_level_params object should be on master I think | 15:52 |
| bauzas | gibi: we already have pre-filters that add specific aggregates to verify | 15:52 |
| bauzas | so, the problem is not how to ask placement | 15:52 |
| bauzas | but rather, how to pass the networks to the pre-filter | 15:52 |
| *** belmoreira has quit IRC | 15:53 | |
| gibi | you have to pass in new information so you have to extend an passed object or pass a new object | 15:53 |
| bauzas | gibi: see, https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/scheduler/request_filter.py#L121 | 15:53 |
| bauzas | gibi: this way, from the pre-filter, you can pass the list of aggregates to require | 15:54 |
| bauzas | so this is a solved problem | 15:54 |
| bauzas | but since we only have the request spec object that is passed down to the pre-filter, we need to get the networks from it | 15:54 |
| bauzas | my proposal was to use the network metadata info | 15:54 |
| bauzas | but we only provide a list of physnets | 15:55 |
| gibi | so you can extend the NetworkMetadata if you wish, or you can extend the RequestLevelParams of the RequestSpec | 15:55 |
| bauzas | or I could get the info like this https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/request_spec.py#L547 | 15:56 |
| bauzas | (from the vif) | 15:56 |
| *** efried has quit IRC | 15:56 | |
| gibi | do we have the instance info cache populated before reaching the compute? | 15:56 |
| bauzas | no, that's only for a move op | 15:57 |
| bauzas | AFAIK | 15:57 |
| bauzas | anyway, I need to think about the problem more | 15:57 |
| gibi | yeah, for the move you can reach into the info cache | 15:57 |
| bauzas | gibi: I need to balance all the options | 15:58 |
| bauzas | I don't want a pre-filter that would behave different between operations | 15:58 |
| bauzas | so I literrally need to find a way to provide the required information into the request spec object directly | 15:59 |
| bauzas | which would prevent us backports, which is a bit sad unfortunately for my company :/ | 15:59 |
| gibi | ohh, so the motivation is backportability | 16:00 |
| bauzas | gibi: not really, I'd say the easier be the better | 16:03 |
| bauzas | I was thinking the physnets be a clean way to do this, but given this TODO, I'm stuck | 16:04 |
| bauzas | so, I'll just provide the networks the best way, and good bye backportability | 16:04 |
| gibi | fixing that TODO would need also an object change I guess, so you would not gain much | 16:04 |
| sean-k-mooney | hi so i was not following due to downstream call | 16:05 |
| sean-k-mooney | bauzas: we cant trust the phsynets in the networking info cache if the network has multiple phsynets | 16:05 |
| sean-k-mooney | unless we fix how we currently do the phsynet lookup | 16:06 |
| sean-k-mooney | so that that is segment aware | 16:06 |
| bauzas | sean-k-mooney: that was gibi's point | 16:06 |
| bauzas | (17:08:49) gibi: bauzas: then I think you have to resolve TODO in the codepath that gather the physnets https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/network/neutron.py#L2020 | 16:06 |
| sean-k-mooney | bauzas: the physnet in the nova vif object are only correct when you have 1 phsynet and transitivly 1 segment on the network | 16:07 |
| bauzas | sean-k-mooney: I was just looking up the network metadata | 16:07 |
| sean-k-mooney | bauzas: right so if we resolve that todo we need also consider the inpact on sriov | 16:07 |
| sean-k-mooney | by the way this is the issue i pointed out before. actully supporting the multi_provider_physnet extension | 16:08 |
| bauzas | sean-k-mooney: https://review.opendev.org/#/c/749068/1/nova/scheduler/request_filter.py@286 | 16:08 |
| bauzas | sean-k-mooney: but I used the physnets because that was the quickiest path | 16:08 |
| bauzas | since we don't pass the list of networks | 16:08 |
| bauzas | in the request spec | 16:08 |
| sean-k-mooney | ya so that set of phsynets is not correct for routed networks if you have more then 1 segment | 16:08 |
| bauzas | sure | 16:09 |
| bauzas | so | 16:09 |
| bauzas | what I want is just a way to get a list of networks et voila | 16:09 |
| bauzas | which means I have to augment the RequestSpec object or one of its nested children | 16:09 |
| sean-k-mooney | the pshnets are in the segments not in the networks so you need to list the network then query neutron for the segment to get the phsynet | 16:09 |
| bauzas | again, I don't care of the physnets | 16:10 |
| *** hamalq has joined #openstack-nova | 16:10 | |
| *** priteau has joined #openstack-nova | 16:10 | |
| bauzas | I want to get the segments | 16:10 |
| *** artom has quit IRC | 16:10 | |
| sean-k-mooney | yes but neutron uses physnets to map host to segments | 16:10 |
| sean-k-mooney | but yes you want the segment | 16:10 |
| bauzas | sean-k-mooney: we have a neutron API for getting the segments that are related to either a network or a physnet | 16:11 |
| bauzas | the original proposal from matt was to get the networks and ask neutron to give the segments | 16:11 |
| sean-k-mooney | yes | 16:11 |
| bauzas | this was easy since he wrote that in the conductor | 16:11 |
| bauzas | and then we directly have the requested networks (or ports) | 16:11 |
| bauzas | but here, we want to make it more generic in a pre-filter | 16:12 |
| bauzas | and in my case, I only have the requestspec object this is passed as argument | 16:12 |
| bauzas | good bye networks and ports | 16:12 |
| *** sapd1 has quit IRC | 16:12 | |
| bauzas | sean-k-mooney: see my problem and why I went using the physnets ? | 16:12 |
| sean-k-mooney | bauzas: yep i know but just to be clear this will only work for existing vms | 16:13 |
| sean-k-mooney | you cant use phsynets for booting new vms | 16:13 |
| bauzas | sean-k-mooney: well, I can see us populating the network metadata object when creating the instance | 16:13 |
| bauzas | https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/network/neutron.py#L2082 | 16:14 |
| bauzas | but either way | 16:14 |
| sean-k-mooney | when we create teh port with ip allocation policy deffer it wont be bound to a segment or phsynet yet | 16:14 |
| bauzas | I need a way to pass down the requested networks | 16:14 |
| sean-k-mooney | yes | 16:15 |
| sean-k-mooney | so you eighter need to add the requested networks to the resquest spec or to the network_metadta or just add the instnace object but i know we have said no to the instance in the past | 16:16 |
| sean-k-mooney | or jsut pass the instance to the prefilter | 16:16 |
| sean-k-mooney | we dont actully have the instance object where this is called https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/scheduler/manager.py#L150 | 16:18 |
| bauzas | sean-k-mooney: right, because that's in the scheduler | 16:19 |
| bauzas | sean-k-mooney: a simple approach would be to mention the requested networks on the main request spec object | 16:19 |
| sean-k-mooney | sure but the fact we are in schduling means the object exists | 16:19 |
| sean-k-mooney | bauzas: yes | 16:19 |
| bauzas | sean-k-mooney: do you think we would persist those ? | 16:19 |
| bauzas | or should we guess them for a move operation ? | 16:20 |
| sean-k-mooney | the requested networks | 16:20 |
| bauzas | yes | 16:20 |
| bauzas | this is risky | 16:20 |
| sean-k-mooney | if we add them to the request spec and use them we need to update them when we add or remove interfaces | 16:20 |
| sean-k-mooney | oh | 16:21 |
| bauzas | only when you want a scheduling decision | 16:21 |
| bauzas | so, yeah we need to recalculate them | 16:21 |
| sean-k-mooney | is the network info cache populated yet | 16:21 |
| sean-k-mooney | we have the instance uuid right | 16:21 |
| bauzas | no, I don't think | 16:21 |
| sean-k-mooney | damb | 16:21 |
| bauzas | sean-k-mooney: only for the first instance | 16:21 |
| bauzas | sean-k-mooney: but I'd say, just populate this field at boot time based on the base options | 16:22 |
| sean-k-mooney | well select destinations has instance_uuids | 16:22 |
| bauzas | sean-k-mooney: and for a move, just try to get them from the info cach | 16:22 |
| bauzas | sean-k-mooney: I don't want to add a new arg to the filter | 16:23 |
| bauzas | sean-k-mooney: all of this needs to be in the request spec | 16:23 |
| bauzas | but I get your point | 16:23 |
| sean-k-mooney | well we can update the request_spec.instance_uuid field | 16:23 |
| bauzas | we could get the requested networks from the info cache in the scheduler, add them on the fly before calling the pre-filter and wipe them after | 16:23 |
| bauzas | oh please no | 16:23 |
| sean-k-mooney | for i think we already do in once case for multicreate | 16:24 |
| sean-k-mooney | we had to fix someting related to this | 16:24 |
| sean-k-mooney | i think it was the numa toplogy | 16:24 |
| sean-k-mooney | bauzas: yes | 16:25 |
| sean-k-mooney | so if you were to do that | 16:25 |
| sean-k-mooney | i would not add a new fiedl | 16:25 |
| sean-k-mooney | jsut set the info on the object directly | 16:26 |
| sean-k-mooney | that way it wont persist | 16:26 |
| sean-k-mooney | we do that in some places today | 16:26 |
| sean-k-mooney | e.g. request_spec.temp_var = my thing | 16:26 |
| sean-k-mooney | im not sure its the request spec object we do that for but its why we dont error if you set a filed on an ovo that does not exist | 16:27 |
| sean-k-mooney | because nova ocationally stores info in them that is never serialised | 16:27 |
| gibi | you can add a proper ovo field that is not persisted | 16:28 |
| gibi | that would be a bit more readable | 16:28 |
| sean-k-mooney | can you? i did not know that | 16:28 |
| bauzas | surely you can | 16:28 |
| sean-k-mooney | well i was not aware we were already doing that | 16:28 |
| bauzas | the network metadata field, for example :D | 16:28 |
| bauzas | this one is lazy loaded | 16:29 |
| sean-k-mooney | is that contoled by https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/request_spec.py#L36? | 16:30 |
| gibi | requested_resourceshttps://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/request_spec.py#L566-L573 | 16:30 |
| *** belmoreira has joined #openstack-nova | 16:30 | |
| bauzas | sean-k-mooney: not really controlled, just we know what to look up from DB with this list | 16:30 |
| sean-k-mooney | https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/request_spec.py#L538-L556 | 16:31 |
| sean-k-mooney | so that is built form the info cache | 16:31 |
| bauzas | https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/request_spec.py#L137 | 16:31 |
| bauzas | sean-k-mooney: only for all ops but create | 16:31 |
| sean-k-mooney | this is where its filtered out | 16:33 |
| sean-k-mooney | https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/request_spec.py#L655-L657 | 16:33 |
| sean-k-mooney | which we call in create before we create it in the db | 16:34 |
| sean-k-mooney | then we load back from the db object | 16:34 |
| bauzas | sean-k-mooney: that's the standard way of providing a ovo field that's not persisted | 16:35 |
| sean-k-mooney | "standard" i was expecting to have a flag in the field deffintion | 16:36 |
| sean-k-mooney | like nullable=false | 16:36 |
| sean-k-mooney | but persit=false instead | 16:36 |
| bauzas | ie. you explicitely provide a lazy-loading mechanism for getting it, but you also delete its primitive before persisting to the DB | 16:36 |
| bauzas | sean-k-mooney: oh no, that's made thru code patterns :) | 16:36 |
| bauzas | so, I could technically add a new field | 16:37 |
| bauzas | make it lazy-loadable | 16:37 |
| sean-k-mooney | ya this is proably less readable then just doing object.whatever=somethign | 16:37 |
| sean-k-mooney | its certenly more complicated and eaiser to mess up | 16:37 |
| bauzas | and make sure we populate it from the info cache when we can | 16:37 |
| bauzas | sean-k-mooney: well, I know our objects before they were called o.vo :) | 16:38 |
| bauzas | that certainly helps :) | 16:38 |
| sean-k-mooney | yep but that does not mean we should keep doing it this way | 16:38 |
| *** belmoreira has quit IRC | 16:38 | |
| sean-k-mooney | its rather archane | 16:38 |
| sean-k-mooney | i can follow it but its not obvious and its not a clean approch | 16:38 |
| sean-k-mooney | it certenly works | 16:38 |
| sean-k-mooney | but this is definetly techdebth | 16:39 |
| sean-k-mooney | addign a property to the class and using it would be cleaner | 16:39 |
| sean-k-mooney | or addign it as a flag on the field and doing it in ovo | 16:39 |
| sean-k-mooney | i guess its not really ovo but the db code | 16:40 |
| bauzas | sean-k-mooney: I'll make a proposal tomorrow morning | 16:48 |
| sean-k-mooney | we shoudl put the segment info in the nova.network.vifobject | 16:50 |
| sean-k-mooney | then get those form the cache | 16:50 |
| sean-k-mooney | https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/network/model.py#L380-L404 | 16:50 |
| sean-k-mooney | well nova.network.model.Vif | 16:50 |
| sean-k-mooney | or nova.network.model.VIF i guess is the corerct capitalisation | 16:51 |
| *** efried has joined #openstack-nova | 16:52 | |
| sean-k-mooney | we can add a new segment filed to that object | 16:52 |
| sean-k-mooney | these are not ovos | 16:52 |
| *** ralonsoh has quit IRC | 16:53 | |
| sean-k-mooney | but those are what is stored in the info cache | 16:53 |
| sean-k-mooney | they are constucted here https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/network/neutron.py#L3026-L3076 | 16:54 |
| *** stephenfin has quit IRC | 16:56 | |
| sean-k-mooney | this is called via allocate_for_instance which is also what populates the info cache | 16:58 |
| sean-k-mooney | oh... | 17:02 |
| sean-k-mooney | that is called first on the compute host. because we only auto allocate networks on compute host if we are passed network ids | 17:02 |
| bauzas | sean-k-mooney: again, I won't modify the vif object | 17:09 |
| bauzas | I think I have everything I need | 17:09 |
| bauzas | we have the requested networks at boot time, so we can directly pass them thru the spec object | 17:09 |
| bauzas | for the move operations, we can recalculate the requested networks from the vifs | 17:10 |
| bauzas | that's it | 17:10 |
| bauzas | hopefully, tomorrow I should be able to provide a new re | 17:10 |
| sean-k-mooney | yes although im suggestign we should have the segments in the vif object anyway | 17:10 |
| bauzas | rev | 17:10 |
| sean-k-mooney | i.e. we should add them | 17:10 |
| bauzas | sean-k-mooney: I'm more in favor of what gibi suggested in the spec review, ie. getting the aggregates directly from neutron as an a-c query | 17:11 |
| bauzas | like we do for bw-aware instances | 17:11 |
| sean-k-mooney | bauzas: yes that is what i orginally suggested | 17:11 |
| bauzas | but that's next release | 17:11 |
| sean-k-mooney | but that not going to happen this release | 17:11 |
| bauzas | yup | 17:11 |
| sean-k-mooney | but even if we get them form neutron | 17:11 |
| sean-k-mooney | we will need to store them in the vif object | 17:12 |
| sean-k-mooney | that is why i was suggestign adding them there | 17:12 |
| bauzas | either way, kids go back to school tomorrow morning, stopping now | 17:12 |
| sean-k-mooney | anyway ill take a look at your patch tomorrow | 17:12 |
| bauzas | sean-k-mooney: bye and thanks for all the fish | 17:13 |
| *** dtantsur is now known as dtantsur|afk | 17:13 | |
| *** tosky has quit IRC | 17:14 | |
| *** derekh has quit IRC | 17:20 | |
| sean-k-mooney | yum fish.... i was ment to get sushi yesterday but resturant nice resturant was not delivering. i think they are still offline today but someday this week ill will order some and it will be awsome. for now im just oging to go make dinner o/ | 17:27 |
| * sean-k-mooney has beer battered cod in the freezer but its not the same | 17:28 | |
| *** priteau has quit IRC | 17:29 | |
| *** gyee has joined #openstack-nova | 17:43 | |
| *** tesseract has quit IRC | 17:43 | |
| *** JamesBenson has joined #openstack-nova | 17:43 | |
| *** jamesden_ has quit IRC | 17:47 | |
| *** artom has joined #openstack-nova | 17:49 | |
| *** jamesdenton has joined #openstack-nova | 17:49 | |
| *** jsuchome has quit IRC | 17:56 | |
| sean-k-mooney | gibi: ill try to test your sriov series tomorrow but feel free to remind me to if i forget. | 18:05 |
| *** lpetrut has quit IRC | 18:20 | |
| sean-k-mooney | artom: added a few more details to https://review.opendev.org/#/c/747451/4 but im +1 on the patch | 18:27 |
| sean-k-mooney | basically i just noted the binding point for the singel port binding workflow to show that that is also valid | 18:27 |
| sean-k-mooney | and responded to lee's question regarding asserting the host | 18:28 |
| sean-k-mooney | melwitt: ^ if you want me to expand on anything in particalar let me know but it looks correct. | 18:28 |
| artom | sean-k-mooney, so when I tested this I didn't have any of the binding stuff in the vifs | 18:31 |
| artom | Though in retrospect maybe I was running without the extension? | 18:31 |
| sean-k-mooney | how do you mean | 18:32 |
| sean-k-mooney | when you tested this with devstack or unit/functional tests | 18:33 |
| artom | sean-k-mooney, devstack | 18:33 |
| sean-k-mooney | which vifs did you check | 18:33 |
| artom | sean-k-mooney, all of them :P | 18:33 |
| artom | sean-k-mooney, even the network_info from the Neutron API didn't have them | 18:34 |
| sean-k-mooney | which binding info are you looking for | 18:34 |
| *** zzzeek has quit IRC | 18:34 | |
| sean-k-mooney | the host id is not in the nova.network.model.VIF object | 18:34 |
| sean-k-mooney | which is what is in the network info | 18:34 |
| artom | sean-k-mooney, I guess it converts | 18:35 |
| artom | Err, dad taxi time | 18:35 |
| artom | Back in a bit | 18:35 |
| sean-k-mooney | do you mean the migrating_to fields were not in the binding profile | 18:35 |
| sean-k-mooney | sure | 18:35 |
| artom | sean-k-mooney, that was there | 18:35 |
| artom | http://paste.openstack.org/ | 18:35 |
| artom | Err | 18:35 |
| artom | http://paste.openstack.org/show/797304/ | 18:36 |
| artom | I actually saved it at the time | 18:36 |
| *** zzzeek has joined #openstack-nova | 18:36 | |
| artom | To compare the nw_info from the API vs the one from the cache | 18:36 |
| artom | That link is the one from the API | 18:36 |
| artom | It has migrating_to | 18:36 |
| artom | But that's it | 18:36 |
| artom | The one in the cache didn't have it | 18:36 |
| sean-k-mooney | ah ok | 18:36 |
| sean-k-mooney | then ya i guess you could assert that | 18:36 |
| artom | http://paste.openstack.org/show/797305/ is from the cache | 18:37 |
| sean-k-mooney | the one in the cache has not been update at all then | 18:37 |
| artom | OK, really have to bounce | 18:37 |
| sean-k-mooney | artom: cool but just so you know you just showed there is something you can test in a follow up patch :P | 18:37 |
| sean-k-mooney | you also showed that its doint the right thing | 18:38 |
| artom | sean-k-mooney, checking that "migrating_to" is *not* in the VIF? | 18:38 |
| sean-k-mooney | since the cache does not have any of the chagne done during migration | 18:38 |
| sean-k-mooney | yep | 18:38 |
| artom | Ah, yeah true :) | 18:38 |
| * artom is looking for his shades | 18:38 | |
| sean-k-mooney | go do dad taxi :) | 18:39 |
| *** k_mouza has joined #openstack-nova | 18:39 | |
| *** k_mouza has quit IRC | 18:40 | |
| *** k_mouza has joined #openstack-nova | 18:41 | |
| *** k_mouza has quit IRC | 18:44 | |
| *** belmoreira has joined #openstack-nova | 18:47 | |
| *** k_mouza has joined #openstack-nova | 18:51 | |
| *** zzzeek has quit IRC | 18:54 | |
| *** zzzeek has joined #openstack-nova | 18:56 | |
| *** belmoreira has quit IRC | 19:20 | |
| *** k_mouza has quit IRC | 19:34 | |
| *** tbachman has joined #openstack-nova | 20:05 | |
| *** tosky has joined #openstack-nova | 20:15 | |
| *** nweinber has quit IRC | 20:17 | |
| mnaser | is there a 'pre-release' checklist for nova | 20:27 |
| mnaser | it'd be nice if some migrations that hit the same table were combined, s=>t includes adding vpmem and resources to instance_extra | 20:28 |
| mnaser | so going through that painful migration once might be nicer/easier | 20:28 |
| mriedem | mnaser: closest is probably here now https://docs.openstack.org/nova/latest/contributor/ptl-guide.html | 20:33 |
| mriedem | https://wiki.openstack.org/wiki/Nova/ReleaseChecklist is older | 20:33 |
| mriedem | with what your asking for there it's probably hard to do when you're working on separate features, db schema migrations aren't rolled together at the end of the release, they happen as features land | 20:34 |
| mriedem | *you're | 20:35 |
| mnaser | mriedem: yeah i guess going on the 'every commit is releasable' makes this a little impossible | 20:35 |
| mriedem | those didn't actually migrate data did they? just alter table to add the column on a big table? | 20:36 |
| mnaser | mriedem: yeah alter table on a big table indeed | 20:36 |
| *** andrewbogott has left #openstack-nova | 20:37 | |
| mnaser | in this case two migrations on instance_extra | 20:38 |
| *** vishalmanchanda has quit IRC | 21:15 | |
| *** raildo has quit IRC | 21:41 | |
| *** mriedem has left #openstack-nova | 21:57 | |
| *** slaweq has quit IRC | 22:15 | |
| *** artom has quit IRC | 22:30 | |
| *** artom has joined #openstack-nova | 22:31 | |
| *** READ10 has joined #openstack-nova | 22:35 | |
| *** stephenfin has joined #openstack-nova | 22:37 | |
| *** rcernin has joined #openstack-nova | 22:51 | |
| *** tosky has quit IRC | 23:03 | |
| *** avolkov has quit IRC | 23:29 | |
| *** hamalq has quit IRC | 23:33 | |
| *** READ10 has quit IRC | 23:49 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!