| opendevreview | melanie witt proposed openstack/nova master: Log the exception returned from a cell during API.get() https://review.opendev.org/c/openstack/nova/+/840260 | 02:02 |
|---|---|---|
| opendevreview | melanie witt proposed openstack/nova master: Log the exception returned from a cell during API.get() https://review.opendev.org/c/openstack/nova/+/840260 | 02:07 |
| *** dasm|ruck|bbl is now known as dasm|ruck|off | 03:11 | |
| gibi | o/ | 07:04 |
| *** ministry is now known as __ministry | 07:44 | |
| Uggla | o/ | 07:46 |
| bauzas | \o | 07:50 |
| opendevreview | Balazs Gibizer proposed openstack/nova-specs master: PCI device tracking in Placement https://review.opendev.org/c/openstack/nova-specs/+/791047 | 07:52 |
| Uggla | gibi, bauzas if you have time, can you have a look at https://review.opendev.org/c/openstack/nova-specs/+/833669 and especially the proposed states. We discuss that with Artom and we thought that this naming is clearer. | 07:52 |
| gibi | Uggla: added to my review list | 07:53 |
| Uggla | thx, it will be interesting to have your thoughts, by the way I have out what we discussed regarding notifications. I hope that's clear enough. | 07:55 |
| gibi | bauzas: btw, your feedback forum session got accepted too | 07:58 |
| bauzas | gibi: ah ok, haven't seen the results yet | 07:58 |
| gibi | you got a mail from the organizers askig for confirming the timing of the session | 07:58 |
| bauzas | shit | 07:59 |
| bauzas | can't see in my free.fr inbox | 07:59 |
| gibi | you got it from Sarah Krawiecki | 08:00 |
| gibi | with subject: OpenInfra Summit Berlin - Forum Session Accepted! | 08:00 |
| bauzas | damn shit, neither in the spam folder | 08:00 |
| bauzas | I know my free.fr ISP is having some problems | 08:00 |
| gibi | I can forward it. should I try it to free.fr or your work mail address? | 08:01 |
| bauzas | saw your reply to Sarah | 08:01 |
| bauzas | confirmed, nothing got received. | 08:02 |
| bauzas | I should ask Sarah whether she got a bot reply | 08:03 |
| bauzas | thanks gibi for the notice | 08:03 |
| gibi | OK, cool | 08:03 |
| chayan | Hi everyone I recently joined the project and am looking for some beginner friendly issues to contribute to can you please help me ? | 08:09 |
| kashyap | chayan: Hi, have you come acros this document yet? - https://docs.openstack.org/nova/latest/contributor/index.html | 08:10 |
| kashyap | chayan: Are you familiar with Gerrit workflow? If not, you might want to check out the sandbox: https://docs.opendev.org/opendev/infra-manual/latest/sandbox.html | 08:11 |
| bauzas | chayan: welcome | 08:11 |
| bauzas | chayan: what kashyap said is a good starting point | 08:12 |
| kashyap | And also this URL: https://docs.opendev.org/opendev/infra-manual/latest/gettingstarted.html | 08:12 |
| bauzas | you would also want to familiarize with our code repository and all the managed services before going further | 08:12 |
| chayan | sure, thanks kashyap and bauzas :) let me have a look | 08:13 |
| bauzas | chayan: do you have any experience of OpenStack as an operator or player of its APIs, maybe ? | 08:14 |
| chayan | no I do not have experience | 08:15 |
| chayan | I have preliminary knowledge of python and was searching for python projects to contribute to ..... and came accross open stack | 08:16 |
| bauzas | this then will be a challenging but interesting experience :) | 08:18 |
| chayan | sure :) ..... Is there any design document which tells what openstack is ..... I was not able to understand much about it | 08:19 |
| bauzas | chayan: as a starting point, I can't just but emphasize again the need for you to understand our tenets, including the different OpenStack service projects, and then within each of them, their distributed model | 08:20 |
| bauzas | chayan: Nova is one of the many projects that OpenStack has | 08:20 |
| bauzas | chayan: general onboarding docs are better if you directy look at our main OpenStack documentation and not the Nova project itself | 08:20 |
| bauzas | sec, finding you some links | 08:21 |
| chayan | sure | 08:21 |
| bauzas | chayan: Upstream Institute is a good entrypoint https://docs.openstack.org/upstream-training/ | 08:22 |
| bauzas | but this won't really dig into the architecture details | 08:23 |
| bauzas | we also have a slidedeck named OpenStack 101 https://object-storage-ca-ymq-1.vexxhost.net/swift/v1/6e4619c416ff4bd19e1c087f27a43eea/www-assets-prod/marketing/OpenStack-101-Modular-Deck-1.pptx | 08:24 |
| bauzas | and we also had a book which becomes a bit stale (last update is 2017) but can still be relevant for getting the overall idea https://docs.openstack.org/operations-guide/ | 08:25 |
| bauzas | HTH | 08:27 |
| chayan | yeah I went through the slides | 08:29 |
| chayan | I think the links will be helpful... thanks | 08:30 |
| songwenping_ | gibi: shall we put the pre-filter of owner_nova trait request to flavor? | 08:48 |
| gibi | songwenping_: hi! sorry I don't understand the question. do you have a patch or other context I can look at? | 08:50 |
| songwenping_ | oh, i'm sorry. the question is for the owner_nova trait usage spec:https://review.opendev.org/c/openstack/nova-specs/+/819510 | 08:52 |
| songwenping_ | about the work item 3:Add pre-filter the trait for every Nova request group. | 08:53 |
| gibi | songwenping_: ohh I see now. | 08:53 |
| gibi | songwenping_: so what we really want is to add it to every request group that was create due to the flavor yes | 08:54 |
| gibi | including the unnamed group containing the CPU and memory request, and including the group requesting GPU due to GPU was requested via the flavor | 08:55 |
| gibi | but not including the group that was created from a neutron port, or from a cyborg resource request | 08:55 |
| songwenping_ | so we should add 'owner_trait=nova' with pci_passthrough for the flavor property? | 08:58 |
| gibi | I don't think the admin should add the trait manually to the flavor. I think nova should automatically add the trait to the request groups it creates | 09:08 |
| songwenping_ | gibi: if flavor doesnot have the property, how do we check the compute minimum version? | 09:10 |
| gibi | songwenping_: you can call service_obj.get_minimum_version_all_cells( context, ["nova-compute"]) | 09:13 |
| gibi | to determine the global minimum of compute service versions | 09:13 |
| gibi | but probably the current prefilter interface is not good to determine where the add the traits | 09:14 |
| songwenping_ | yes, i'm wondering where to add the traits and check the version | 09:15 |
| gibi | so prefilter runs on RequestSpec objects, but some of the flavor induced placement RequestGroups are create after the prefilters were run in the call of nova.scheduler.utils.ResourceRequest.from_request_spec | 09:17 |
| gibi | songwenping_: you can try to think about changing ResourceRequest.from_request_spec and make RequestGroup creation explicit there | 09:20 |
| songwenping_ | gibi: ok, thanks. | 09:21 |
| gibi | songwenping_: currently nova.scheduler.utils.ResourceRequest._add_resource implicitly creates a new group if it is not exists | 09:22 |
| gibi | songwenping_: feel free to propose a WIP patch playing with this idea and we can involve others to look at the problem and offer ideas | 09:24 |
| gibi | I do thing that a pure prefilter will wont work due to some code structural challenges | 09:25 |
| gibi | *think | 09:25 |
| songwenping_ | ok thanks. i'll try to research. | 09:25 |
| gibi | cool | 09:25 |
| zigo | Hi there! I have a problem with live migrations: | 11:17 |
| zigo | Live Migration failure: operation failed: Failed to connect to remote libvirt URI qemu+tls://192.168.103.4/system: authentication failed: Failed to verify peer's certificate: libvirt.libvirtError: operation failed: Failed to connect to remote libvirt URI qemu+tls://192.168.103.4/system: authentication failed: Failed to verify peer's certificate | 11:17 |
| zigo | How comes libvirt / qemu tries to connect using the *IP ADDRESS* rather than the *HOSTNAME* which makes my PKI fail? | 11:17 |
| zigo | Is there a way to fix that? | 11:17 |
| sean-k-mooney | there is a config option for this i think | 11:18 |
| zigo | sean-k-mooney: In where? In Nova ? | 11:18 |
| sean-k-mooney | yes | 11:19 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_inbound_addr and https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_uri | 11:19 |
| sean-k-mooney | zigo: im guessing you have live_migration_inbound_addr set | 11:20 |
| zigo | I already have live_migration_uri=qemu+tls://%s/system ... | 11:20 |
| zigo | Oh, I do... | 11:20 |
| sean-k-mooney | right but if you have live_migration_inbound_addr it will result in the ip | 11:20 |
| zigo | sean-k-mooney: So I should remove that? | 11:21 |
| zigo | Or set this as hostname instead ? | 11:21 |
| sean-k-mooney | if you remove it it will use the hostname by default | 11:21 |
| sean-k-mooney | it depens on if you are setting live_migration_inbound_addr to choose which interface is used to copy the vm data or not | 11:21 |
| zigo | It's more complicated for me, maybe puppet is doing this by default, let's see if I can convince it to use hostnames instead. Thanks a lot ! | 11:21 |
| sean-k-mooney | live_migration_inbound_addr is normally used to baically for which interface is used but you can do that via dns also | 11:22 |
| zigo | I have all of my cluster defined in /etc/hosts ! :) | 11:23 |
| sean-k-mooney | hehe ya i like to do that too | 11:24 |
| zigo | Production experience showed me that my colleague's DNS service sometimes fail ... :P | 11:24 |
| zigo | This fixed the problem, though now I get: | 11:29 |
| zigo | Live Migration failure: internal error: unable to execute QEMU command 'object-add': Unable to access credentials /etc/pki/qemu/ca-cert.pem: No such file or directory: libvirt.libvirtError: internal error: unable to execute QEMU command 'object-add': Unable to access credentials /etc/pki/qemu/ca-cert.pem: No such file or directory | 11:29 |
| zigo | Weird, I didn't use to have this before ... :/ | 11:29 |
| zigo | Is this the same as /etc/pki/CA/cacert.pem ? | 11:30 |
| sean-k-mooney | i dont think so. i do know that more recent versions of libvirt/qemu change the behaivor slightly no you need both a clien tan dserver cert or something like that | 11:31 |
| sean-k-mooney | in ooo we just symlinked the server fiels to the client folder | 11:32 |
| zigo | Yeah, that I know. Client + server cert. | 11:32 |
| zigo | That's what I'm trying to do. | 11:32 |
| sean-k-mooney | https://bugzilla.redhat.com/show_bug.cgi?id=1957152 i think this was the downstream bug | 11:33 |
| sean-k-mooney | it looks like they just hardcoded the path to /etc/ipa/ca.crt | 11:36 |
| sean-k-mooney | https://review.opendev.org/c/openstack/tripleo-heat-templates/+/796673/1/deployment/nova/nova-libvirt-container-puppet.yaml | 11:36 |
| zigo | It's full of red hat - ism ... The /etc/pki folder should have been renamed to something else in Debian based systems, like /etc/ssl/<something> or /etc/libvirt ... | 11:38 |
| zigo | I don't think I have the /etc/ipa yet though. | 11:39 |
| sean-k-mooney | thats not surprising | 11:40 |
| *** dasm|ruck|off is now known as dasm|ruck | 12:17 | |
| *** artom__ is now known as artom | 13:21 | |
| artom | zigo, sean-k-mooney, yeah, we currently have 2 trackers open for something very similar | 13:21 |
| artom | https://bugs.launchpad.net/tripleo/+bug/1959328 in upstream TripleO | 13:22 |
| artom | And https://bugzilla.redhat.com/show_bug.cgi?id=2079767 for our downstream product | 13:22 |
| artom | What's weird is that those are very TripleO-specific | 13:23 |
| artom | So I wouldn't think they affect any other deployment means | 13:23 |
| sean-k-mooney | artom: i think its because of the reuse of puppet | 13:27 |
| opendevreview | Rico Lin proposed openstack/nova-specs master: Add IOMMU device support for libvirt driver https://review.opendev.org/c/openstack/nova-specs/+/840310 | 13:38 |
| kashyap | gibi: artom: Can you re-look at this, pls - https://review.opendev.org/c/openstack/nova/+/838926 (Add a workaround to skip compareCPU() on destination) | 13:40 |
| kashyap | (When you get a moment, i.e.) | 13:41 |
| gibi | kashyap: will look | 13:41 |
| sean-k-mooney | artom: in principal the openstack pupet modules are ment to be multi distro and also not ooo specific but because of redhats in vovlement in them that is not always the case | 13:42 |
| kashyap | No one is stopping other distros to add support for it | 13:46 |
| kashyap | sean-k-mooney: On the flip side, sometimes RHT folks do plenty work for other distros too. (All in good faith) | 13:46 |
| kashyap | My general point is, we should not expect any one distro vendor to do the enablement work for other distros | 13:47 |
| kashyap | (Modulo exceptions) | 13:47 |
| artom | kashyap, done | 13:47 |
| kashyap | Thx; will look | 13:49 |
| kashyap | artom: On double-negation, I agree in general. But in this case, IMO the "skip" wording is more explicit. And it isn't _that_ big of a cognitive burden :) | 13:50 |
| gibi | kashyap: done too, I have no blocking issue just a question about deprecation of the config option | 13:51 |
| artom | kashyap, yeah, it's not a hill I'm going to die on, but I wanted to raise the point | 13:51 |
| kashyap | artom: Yeah, fair point for sure | 13:51 |
| kashyap | gibi: Yeah, good point on deprecation. I'll think a bit more on it | 13:52 |
| kashyap | Will answer there. Thx, both | 13:52 |
| chayan | Hi everyone, I have python knowledge but do not have a cs background .....can you give me an idea of which cs topics/subject or others may be pre requisites for understanding the openstack-nova project? thanks | 13:56 |
| opendevreview | ribaudr proposed openstack/nova-specs master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova-specs/+/831506 | 13:59 |
| opendevreview | Artom Lifshitz proposed openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/833669 | 14:13 |
| kashyap | chayan: One area coulbe to to understand how virtual machines are configured (particularly KVM, QEMU, or even other "hypervisors" like Xen, etc) | 14:21 |
| kashyap | chayan: Also please look at the links we (including bauzas) have posted already earlier in the day. (The contributor, getting started, etc docs) | 14:25 |
| chayan | sure thanks a lot for the help ... I am already going through the links you guys gave me ... thanks again | 14:25 |
| opendevreview | Kashyap Chamarthy proposed openstack/nova master: libvirt: Add a workaround to skip compareCPU() on destination https://review.opendev.org/c/openstack/nova/+/838926 | 14:35 |
| kashyap | artom: gibi: Fixed --^ | 14:35 |
| gibi | Uggla: commented on the Manial spec. thanks for the state diagram, it helped me to ask more questions :) | 14:41 |
| Uggla | gibi, not sure this is a good news for me. :) | 14:42 |
| artom | Questions are good :) | 14:42 |
| opendevreview | ribaudr proposed openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/833669 | 14:44 |
| Uggla | gibi, btw I have just done a slight update. | 14:45 |
| gibi | ack | 14:58 |
| bauzas | reminder : nova meeting in 45 mins here at #openstack-nova | 15:14 |
| * bauzas needs to paperwork the agenda :) | 15:14 | |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue May 3 16:00:12 2022 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| gibi | o/ | 16:01 |
| elodilles | o/ | 16:01 |
| gmann | o/ | 16:01 |
| sean-k-mooney | o/ | 16:01 |
| bauzas | hello | 16:01 |
| melwitt | o/ | 16:01 |
| bauzas | sorry I'm over the phone but let's start | 16:01 |
| bauzas | #topic Bugs (stuck/critical) | 16:01 |
| bauzas | #info No Critical bug | 16:01 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 22 new untriaged bugs (-2 since the last meeting) | 16:01 |
| bauzas | #link https://storyboard.openstack.org/#!/project/openstack/placement 26 open stories (0 since the last meeting) in Storyboard for Placement | 16:02 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:02 |
| bauzas | artom: around ? | 16:02 |
| artom | 'sup? | 16:02 |
| bauzas | artom: can I pass you the next bug triage baton ? | 16:03 |
| artom | I'm getting baton'ed, aren't I? | 16:03 |
| melwitt | I thought we had 28 new bugs last meeting :( https://meetings.opendev.org/meetings/nova/2022/nova.2022-04-26-16.00.log.html#l-16 | 16:03 |
| melwitt | -2 makes it look like I didn't do anything 😂 | 16:03 |
| gibi | melwitt: thank you for the triage! | 16:03 |
| gibi | I also remember 28 or 29 from last week | 16:04 |
| melwitt | I copied gibi's doc https://etherpad.opendev.org/p/nova-bug-triage-20220426, there were a couple more where I added comments but didn't change from New bc not enough info yet afaict | 16:04 |
| melwitt | (and didn't add to doc either) | 16:05 |
| bauzas | yeah, thanks melwitt ! | 16:05 |
| artom | Should we maybe have a single etherpad? | 16:05 |
| artom | So new batoners can refers to existing work/patterns/templates? | 16:05 |
| bauzas | melwitt: no worries, I had some weeks the same situation | 16:05 |
| Uggla | o/ | 16:05 |
| bauzas | I was triaged like 10 bugs but given 12 were new, I was only having a -2 value :) | 16:05 |
| bauzas | or the other way, sorry :) | 16:05 |
| melwitt | I think one etherpad would quickly become a megapad. but the pads are linked here so far https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:06 |
| artom | melwitt, aha OK that works, as long as we have a single... something | 16:06 |
| bauzas | yeah, we can have a new etherpad per week, it's fine | 16:06 |
| gibi | artom: I created the etherpad just to note for the meeting if there are valid but unassigned bugs | 16:06 |
| bauzas | it's not actually really needed to create a etherpad | 16:06 |
| gibi | not at all mandatory :) | 16:06 |
| bauzas | like gibi said, he did it for him | 16:06 |
| melwitt | yeah. and I liked it so I copied it | 16:07 |
| gibi | (it is also good for looking back after the week and justify the time spent on launchpad :) | 16:08 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Record SRIOV PF MAC in the binding profile https://review.opendev.org/c/openstack/nova/+/829248 | 16:08 |
| melwitt | gibi: +1 :) | 16:09 |
| gibi | bauzas: I think we can move on | 16:11 |
| bauzas | ok, next topic | 16:11 |
| bauzas | #topic Gate status | 16:12 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:12 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly Placement periodic job status | 16:12 |
| bauzas | #link https://zuul.opendev.org/t/openstack/builds?job_name=nova-emulation&pipeline=periodic-weekly&skip=0 Emulation periodic job runs | 16:12 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:12 |
| bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | 16:12 |
| gibi | melwitt: thanks for the triage on the gate bug https://bugs.launchpad.net/nova/+bug/1970642 I will try to get back to that | 16:13 |
| bauzas | nothing to tell from me | 16:13 |
| melwitt | this gate bug has shown back up on stable/ussuri fyi https://bugs.launchpad.net/nova/+bug/1901739 but it doesn't show up in the gate-failure tag bc it's on ussuri only | 16:13 |
| melwitt | gibi: np! | 16:13 |
| bauzas | cool | 16:14 |
| melwitt | we're on our second recheck trying to merge one of the gate unblocking patch on stable/ussuri https://review.opendev.org/c/openstack/nova/+/838033 :\ | 16:14 |
| melwitt | for bug 1901739 | 16:15 |
| gibi | and the original fix was to switch to zuul v3 :/ | 16:15 |
| elodilles | yepp, it seems ussuri is not that healthy as it should be :S | 16:15 |
| elodilles | gibi: and as far as i remember we did not need that for ussuri | 16:16 |
| elodilles | so this is something "new" | 16:16 |
| gibi | hm we do merged the ussuri backport https://review.opendev.org/c/openstack/nova/+/795432 | 16:17 |
| gibi | that should have fixed 1901739 but appreantly it did not | 16:18 |
| elodilles | oh. hmmm, yes, we did not backport it to *train*... | 16:19 |
| elodilles | then this is definitely something "new" | 16:19 |
| gibi | that is all I can add to this right now :/ | 16:19 |
| bauzas | could we discuss about the stable branch gate issues during the stable topic, maybe ? | 16:21 |
| elodilles | ++ :) | 16:21 |
| elodilles | (i planned to note this there) | 16:21 |
| bauzas | ok, then next topic | 16:22 |
| elodilles | (otherwise i don't have much to add for now) | 16:22 |
| bauzas | #topic Release Planning | 16:22 |
| bauzas | #link https://releases.openstack.org/zed/schedule.html | 16:22 |
| bauzas | #info Zed-1 is due in 2 weeks | 16:22 |
| bauzas | #info Spec review day planned on May 10th | 16:22 |
| bauzas | ... which is next week | 16:22 |
| bauzas | I've seen some new specs | 16:23 |
| melwitt | sorry, I thought stable gate status was part of gate status | 16:23 |
| bauzas | I'll try to review some of them tomorrow | 16:23 |
| bauzas | melwitt: no worries at all | 16:23 |
| bauzas | but I'd prefer to do this after all the other topics | 16:23 |
| bauzas | so we'll have all the left time for it :) | 16:23 |
| bauzas | anything to say about release planning ? | 16:24 |
| bauzas | keep in mind to upload/update your last specs before next tuesday :) | 16:24 |
| bauzas | looks not | 16:26 |
| bauzas | #topic Review priorities | 16:26 |
| bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+label:Review-Priority%252B1 | 16:26 |
| bauzas | nothing to tell here | 16:26 |
| bauzas | ok, moving on then | 16:30 |
| bauzas | #topic Stable Branches | 16:31 |
| bauzas | elodilles: you can continue the discussion here :) | 16:31 |
| elodilles | well, let's start with the basics :) | 16:31 |
| elodilles | #info ussuri and older branches are blocked until 'l-c drop' patches merge - https://review.opendev.org/q/I514f6b337ffefef90a0ce9ab0b4afd083caa277e | 16:31 |
| elodilles | and as we said something else problematic is there on ussuri it seems :( | 16:31 |
| elodilles | #info other branches should be OK | 16:32 |
| elodilles | EOM | 16:32 |
| elodilles | I don't have other info for the ussuri failures for now :( | 16:32 |
| bauzas | cool | 16:35 |
| bauzas | melwitt: wanting to add something ? | 16:35 |
| melwitt | nothing additional, thanks | 16:36 |
| bauzas | cool | 16:36 |
| bauzas | then we're done with this topic | 16:36 |
| bauzas | #topic Open discussion | 16:36 |
| bauzas | ... and we have nothing about this in the wiki | 16:36 |
| bauzas | soooo, any item to raise before we end the meeting ? | 16:36 |
| gibi | <crickets? | 16:37 |
| gibi | > | 16:37 |
| bauzas | okidoki | 16:38 |
| bauzas | thanks all | 16:38 |
| bauzas | #endmeeting | 16:38 |
| opendevmeet | Meeting ended Tue May 3 16:38:13 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:38 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-03-16.00.html | 16:38 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-03-16.00.txt | 16:38 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-03-16.00.log.html | 16:38 |
| * bauzas needs to call again his company travel agency to sort some mess it created | 16:38 | |
| elodilles | thanks o/ | 16:38 |
| gibi | o/ | 16:38 |
| opendevreview | ribaudr proposed openstack/nova-specs master: Allow to use graphviz into specifications https://review.opendev.org/c/openstack/nova-specs/+/840167 | 16:40 |
| opendevreview | ribaudr proposed openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/833669 | 16:40 |
| melwitt | dansmith: I wanted to get your opinion on whether copying exception objects is necessary when referring to them in a new dict or other wrapper https://review.opendev.org/c/openstack/nova/+/840260/2/nova/context.py if you could spare a moment. no rush | 16:45 |
| dansmith | hmm, yeah I thought there was something about it being semi-global in nature, but that might be a py2 thing | 16:47 |
| dansmith | ah your comment is interesting though.. straight up block scoping being more strict in python, but that's not really what is changing here, | 16:49 |
| dansmith | as we're already storing it in the different name, it's the copying part that is in question | 16:49 |
| *** dasm|ruck is now known as dasm|ruck|bbl | 16:50 | |
| melwitt | yeah exactly | 16:50 |
| sean-k-mooney | excpetion objects nolonger keep the stack frame alive right via the traceback object | 16:50 |
| sean-k-mooney | so we dont have to worry about it "leaking" memory like it did on python 2 | 16:51 |
| dansmith | https://stackoverflow.com/questions/44681681/what-could-prevent-a-traceback-from-being-garbage-collected | 16:51 |
| dansmith | melwitt: see the last comment in there about py3 | 16:51 |
| dansmith | sean-k-mooney: yeah, that's what I was thinking... the old py2 stuff about things being special there | 16:52 |
| melwitt | oh interesting | 16:53 |
| sean-k-mooney | ya so no i think the traceback is generated at the time its raised with a weakref to the stack fram to avoid that issue on py3 | 16:53 |
| sean-k-mooney | melwitt: we had a case where we were returning raided excations if i rememebr correctly in nova that caused issue in the past | 16:53 |
| sean-k-mooney | possible in relation to the scater gather implementions | 16:53 |
| sean-k-mooney | its been a while | 16:53 |
| melwitt | hrm... yeah that is where the code in question is | 16:54 |
| dansmith | well, it's really anywhere we're persisting the exception outside the handler, | 16:54 |
| melwitt | if we need it I definitely want to put a code comment there explaining why it's needed | 16:54 |
| dansmith | so there might be a thing related to handling in rpc too, but yeah | 16:54 |
| sean-k-mooney | dansmith: righ tbut in that case we wanted to do that to allow the other request ot proceed and deal with it at the end | 16:55 |
| dansmith | in the scatter/gather case yeah | 16:55 |
| sean-k-mooney | we normally dont have a good usecase to persist the object | 16:55 |
| dansmith | right, in the rpc case we do end up raising out of there, you're right | 16:56 |
| dansmith | I hedged with "might" so.. :P | 16:56 |
| sean-k-mooney | :) | 16:56 |
| sean-k-mooney | so back to https://review.opendev.org/c/openstack/nova/+/840260/2/nova/context.py | 16:57 |
| sean-k-mooney | im not sure if a copy actuly breaks the reference ot the stack frame | 16:57 |
| sean-k-mooney | oh its not a copy | 16:57 |
| sean-k-mooney | we are constucting a new instace of the excpetion class | 16:57 |
| sean-k-mooney | wiht the arges for the orgianl excption | 16:58 |
| sean-k-mooney | so ya that would have broken the reference | 16:58 |
| melwitt | yeah I used the word "copy" to mean a new object with the same stuff. sorry if that made it confusing | 16:58 |
| sean-k-mooney | no your fine i just assumed you ment copy.deepcopy just reading the patch now | 16:59 |
| melwitt | sean-k-mooney: so what does that mean, that constructing the new instance is actually bad? I wanted to remove it to make my unit test easier so I was trying to find the inverse, whether it is ok to not construct the new instance | 16:59 |
| sean-k-mooney | i dont have a link to back this up but i belive we dont have to worry about this on python 3 | 16:59 |
| bauzas | looks like a contextmanager question | 17:00 |
| sean-k-mooney | no constucting a new instance is fine | 17:00 |
| sean-k-mooney | and should not by needed on python3 i belive | 17:00 |
| sean-k-mooney | it was there only for py27 | 17:00 |
| sean-k-mooney | to break the internal refernce to the stack frame | 17:00 |
| melwitt | ok I see | 17:01 |
| sean-k-mooney | melwitt: so https://peps.python.org/pep-0344/#open-issue-garbage-collection i think is solved by https://peps.python.org/pep-3110/#semantic-changes as proposed in https://mail.python.org/pipermail/python-3000/2007-January/005363.html | 17:16 |
| sean-k-mooney | i was hoping to find a "this is fix in python 3.x" statement somewhere but didnt see it it fixed before 3.5 as far as i know but not sure what version exactly | 17:19 |
| melwitt | sean-k-mooney++ thanks for those docs, love seeing the details. I had been looking at this that was linked off the earlier stackoverflow question https://stackoverflow.com/questions/1658293/why-is-there-a-need-to-explicitly-delete-the-sys-exc-info-traceback and it mentions python 3.3 using lack of a documentation warning as a hint of it being fixed | 17:20 |
| sean-k-mooney | that would algin with https://stackoverflow.com/questions/11414894/extract-traceback-info-from-an-exception-object/14564261#14564261 which say the traceback atribute was added in 3.2 | 17:23 |
| sean-k-mooney | .*3.2.3 | 17:23 |
| melwitt | ah | 17:24 |
| sean-k-mooney | i really like c++ because i like knowing how the features work and the pros and cons to use them. im always a little sad the the same content is much less avaibale for how does python work under the hood | 17:26 |
| melwitt | ++ | 17:27 |
| sean-k-mooney | there are some good talks form Raymond Hettinger like https://www.youtube.com/watch?v=npw4s1QTmPg | 17:28 |
| sean-k-mooney | on python dicts | 17:28 |
| sean-k-mooney | and datacless but python could do with more of those | 17:28 |
| melwitt | thanks sean-k-mooney | 17:56 |
| *** dasm|ruck|bbl is now known as dasm|ruck | 18:01 | |
| opendevreview | Rico Lin proposed openstack/nova-specs master: Add IOMMU device support for libvirt driver https://review.opendev.org/c/openstack/nova-specs/+/840310 | 18:10 |
| opendevreview | melanie witt proposed openstack/nova-specs master: Amend unified limits spec to explain "API limit" enforcement https://review.opendev.org/c/openstack/nova-specs/+/829413 | 21:05 |
| sean-k-mooney | melwitt: thanks for fixign the merge conflict i ment to ping you about that last week | 21:10 |
| melwitt | sean-k-mooney: np, thanks for looking | 21:11 |
| sean-k-mooney | i was not aware that ye had provided unified_limits_count_pcpu_as_vcpu to bridge that gap | 21:12 |
| sean-k-mooney | melwitt: have you tought about giving a presentation on this and perhaps provider.yaml to show how unified limists can now be used to provide quota for arbitry resouces | 21:13 |
| sean-k-mooney | you could also use network bandwith as a tie in to neutron qos as another example | 21:14 |
| sean-k-mooney | to demonstrate the new capablity | 21:14 |
| sean-k-mooney | from a downstrema docs poing of view i think we will want ot have several such examples but i think it would be nice to have upstream docs examples or a presentaiton on the topic at some point | 21:15 |
| melwitt | sean-k-mooney: yes, I have thought it would be useful to present or otherwise put together a doc/slides about it | 21:15 |
| melwitt | yeah +1 | 21:16 |
| opendevreview | sean mooney proposed openstack/nova master: enable blocked VDPA move operations https://review.opendev.org/c/openstack/nova/+/832330 | 21:43 |
| gmann | bauzas: do you want me to use the BP old name for this or is it ok to change the BP name in LP (which match with the spec file), I think I did update name in LP too but you reverted - https://review.opendev.org/c/openstack/nova-specs/+/833165/1/specs/zed/approved/server-boot-on-specific-hypervisor-with-new-rbac.rst#b10 | 23:15 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!