| *** mhen_ is now known as mhen | 02:49 | |
| takahashi-tsc | Hi tacker team | 08:00 |
|---|---|---|
| shivam | Hi | 08:01 |
| takahashi-tsc | #startmeeting tacker | 08:02 |
| opendevmeet | Meeting started Mon Jan 19 08:02:18 2026 UTC and is due to finish in 60 minutes. The chair is takahashi-tsc. Information about MeetBot at http://wiki.debian.org/MeetBot. | 08:02 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:02 |
| opendevmeet | The meeting name has been set to 'tacker' | 08:02 |
| takahashi-tsc | It seems that Yasufumi-san will not be able to join this meeting today, so I'll be leading the meeting. | 08:03 |
| takahashi-tsc | #link https://etherpad.opendev.org/p/tacker-meeting | 08:03 |
| takahashi-tsc | Today we have 2 topics. Review reminder and discussion on bug fix. | 08:03 |
| takahashi-tsc | Let's start from first topic. | 08:04 |
| takahashi-tsc | but... KDDI Koba-san is not attending? | 08:04 |
| takahashi-tsc | OK... I'll review the spec patch, and will ask Yasufumi-san to review it. | 08:06 |
| takahashi-tsc | If no other comments, let's move to next topic. | 08:07 |
| takahashi-tsc | Good | 08:08 |
| takahashi-tsc | Then, let's move on Shivam's topic. | 08:09 |
| takahashi-tsc | Shivam, could you please explain your topic? | 08:10 |
| shivam | Yes... The next topic "Shallow Copy of Instantiation Request Body Causing Tacker Compliance Test Failures" is related to a bug that causes failure during instantiate operation in compliance testcase | 08:10 |
| shivam | Tacker compliance tests are failing with "No flavour with id 'default'" errors because a shallow copy of the shared instantiation request body allows modifications from scale operations to persist across subsequent VNF lifecycle operations. | 08:11 |
| shivam | The issue occurs because each operation uses "body = INSTANTIATION_BODY" which only creates a reference to the same object rather than an independent copy, causing change to actual INSTANTIATE_BODY when scale operations change the flavour_id value. | 08:12 |
| shivam | Different lifecycle operations expect different flavour_id values (scale expects "default" while others expect "simple"), hence when scale operation updates flavor_id to "default", the INSTANTIATION_BODY also gets updated and when subsequent operation use that INSTANTIATION_BODY, it gets flavour_id as default which cause the issue. | 08:13 |
| shivam | The identified fix is to replace shallow copies with "copy.deepcopy(INSTANTIATION_BODY)" to ensure each operation works with an isolated request body that cannot be affected by other operations. | 08:14 |
| shivam | This solution requires importing the "copy" module. | 08:14 |
| shivam | Also, a separate discussion is needed to have clear policies and expectations around using flavour_id values in compliance testcases to avoid similar inconsistencies in future tests. | 08:15 |
| shivam | For example, use the same flavour_id for all tests, and only use a different one if there is a clear reason explained in a comment, which helps keep tests consistent and avoid confusion. | 08:16 |
| shivam | So, I would like to hear the community’s thoughts on the identified bug, root cause analysis, proposed fix and the approach regarding flavour_id policy. | 08:17 |
| shivam | Thank you. | 08:17 |
| takahashi-tsc | Thanks, First of all, I think your proposed fix is fine. Let's ask for comments on this during the review. | 08:18 |
| takahashi-tsc | On the other hand, do you know why only the Scale has a different ID? Was there a particular reason it needed to be different? | 08:18 |
| takahashi-tsc | It is related to your last proposal, need to discuss "clear policies and expectations around using flavour_id values in compliance testcases to avoid similar inconsistencies in future tests." | 08:20 |
| shivam | Hmm.... will need to check this point "why only the Scale has a different ID?" | 08:20 |
| takahashi-tsc | Yeah... Of course, it’s possible that the original intention is unclear at this point, but on the other hand, I’d like to check if we could unify the IDs instead. | 08:21 |
| takahashi-tsc | that is, if we can change ID for scale to simple. | 08:22 |
| shivam | ok | 08:23 |
| shivam | I will check this point that if it is possible to have same flavour_id (simple) for scale as well. | 08:25 |
| takahashi-tsc | OK, thanks. | 08:25 |
| takahashi-tsc | Then, I'd like Shivam to 1. Submit bug fix patch, and 2. "Check if we can change ID for scale to simple" | 08:27 |
| takahashi-tsc | Shivam, is it OK? | 08:28 |
| shivam | Yes | 08:28 |
| takahashi-tsc | Based on the result, the team can discuss "policies" | 08:28 |
| takahashi-tsc | OK, any comments on this topic? | 08:29 |
| takahashi-tsc | Good. and now Koba-san has joined this call. You have one topic, right? | 08:31 |
| hi-koba | Yes | 08:31 |
| hi-koba | I upload the spec for VNFD multi-tenancy. I would like reviews. | 08:32 |
| hi-koba | I just added Yasufumi-san and Takahashi-san to the reviewers list. | 08:33 |
| hi-koba | on gerrit. | 08:33 |
| hi-koba | We apologize for not being able to meet the initial spec freeze (12/31). | 08:34 |
| hi-koba | Please check if possible. That's all I have to say. | 08:36 |
| takahashi-tsc | Thanks. Considering the New Year holidays, I don't think there is much delay. | 08:37 |
| takahashi-tsc | I'll review it asap. If anyone else is interested in this spec, please feel free to review it as well. | 08:38 |
| takahashi-tsc | #link https://review.opendev.org/c/openstack/tacker-specs/+/972517 | 08:38 |
| takahashi-tsc | any comments? | 08:38 |
| hi-koba | This is very helpful. Thank you so much. | 08:38 |
| takahashi-tsc | OK, then we’ve covered all the topics today. | 08:41 |
| takahashi-tsc | Any others? | 08:41 |
| YuyaKuno | One question to KDDI's spec. Is scope of the tenant only Tacker, not tenant in OpenStack (Keystone)? | 08:42 |
| hi-koba | OK, I’ll answer the question. | 08:44 |
| hi-koba | Tacker uses Keystone for tenant management, so in effect it becomes multi-tenancy of Tacker resources tied to Keystone-managed tenants/projects. | 08:46 |
| YuyaKuno | OK, does the new column of tenant_id associate to tenants/project of Keystone? | 08:47 |
| hi-koba | Yes, exactly. | 08:48 |
| YuyaKuno | Do we need this specification in the spec to clarify tenant_id? | 08:49 |
| hi-koba | I didn’t think it’s necessary. In Tacker, tenant_id refers to the Keystone project, same as other resources (e.g., vnf_instances/vims). | 08:54 |
| hi-koba | But I think it's okay to write it. | 08:55 |
| YuyaKuno | Thank you. | 08:55 |
| takahashi-tsc | I’m not exactly sure about Kuno-san's concerns, but because there seem to be multiple ways tenants are being used, I think it’s a good idea to include a detailed explanation just in case. | 08:56 |
| hi-koba | Thank you for your comment. | 08:56 |
| takahashi-tsc | OK, if further discussion or detailed consideration is needed, let's continue the conversation through comments on Gerrit, or in future IRC meetings. | 08:57 |
| hi-koba | ok | 08:57 |
| takahashi-tsc | Any others, everyone? | 08:57 |
| takahashi-tsc | OK, let's close the meeting. Thank you for joining, bye! | 08:59 |
| YuyaKuno | Thank you. Bye. | 08:59 |
| shivam | Thanks, Bye. | 08:59 |
| hi-koba | ok bye! | 08:59 |
| takahashi-tsc | #endmeeting | 08:59 |
| opendevmeet | Meeting ended Mon Jan 19 08:59:40 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 08:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tacker/2026/tacker.2026-01-19-08.02.html | 08:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tacker/2026/tacker.2026-01-19-08.02.txt | 08:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tacker/2026/tacker.2026-01-19-08.02.log.html | 08:59 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!