08:02:18 <takahashi-tsc> #startmeeting tacker
08:02:18 <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:18 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:02:18 <opendevmeet> The meeting name has been set to 'tacker'
08:03:05 <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:20 <takahashi-tsc> #link https://etherpad.opendev.org/p/tacker-meeting
08:03:55 <takahashi-tsc> Today we have 2 topics. Review reminder and discussion on bug fix.
08:04:09 <takahashi-tsc> Let's start from first topic.
08:04:44 <takahashi-tsc> but... KDDI Koba-san is not attending?
08:06:31 <takahashi-tsc> OK... I'll review the spec patch, and will ask Yasufumi-san to review it.
08:07:45 <takahashi-tsc> If no other comments, let's move to next topic.
08:08:56 <takahashi-tsc> Good
08:09:18 <takahashi-tsc> Then, let's move on Shivam's topic.
08:10:12 <takahashi-tsc> Shivam, could you please explain your topic?
08:10:38 <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:11:27 <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:12:16 <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:13:13 <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:14:32 <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:44 <shivam> This solution requires importing the "copy" module.
08:15:24 <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:16:09 <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:17:11 <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:28 <shivam> Thank you.
08:18:18 <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:39 <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:20:12 <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:45 <shivam> Hmm.... will need to check this point "why only the Scale has a different ID?"
08:21:59 <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:22:22 <takahashi-tsc> that is, if we can change ID for scale to simple.
08:23:02 <shivam> ok
08:25:07 <shivam> I will check this point that if it is possible to have same flavour_id (simple) for scale as well.
08:25:52 <takahashi-tsc> OK, thanks.
08:27:58 <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:28:10 <takahashi-tsc> Shivam, is it OK?
08:28:21 <shivam> Yes
08:28:42 <takahashi-tsc> Based on the result, the team can discuss "policies"
08:29:28 <takahashi-tsc> OK, any comments on this topic?
08:31:04 <takahashi-tsc> Good. and now Koba-san has joined this call. You have one topic, right?
08:31:33 <hi-koba> Yes
08:32:20 <hi-koba> I upload the spec for VNFD multi-tenancy. I would like reviews.
08:33:04 <hi-koba> I just added Yasufumi-san and Takahashi-san to the reviewers list.
08:33:24 <hi-koba> on gerrit.
08:34:52 <hi-koba> We apologize for not being able to meet the initial spec freeze (12/31).
08:36:54 <hi-koba> Please check if possible. That's all I have to say.
08:37:39 <takahashi-tsc> Thanks. Considering the New Year holidays, I don't think there is much delay.
08:38:13 <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:23 <takahashi-tsc> #link https://review.opendev.org/c/openstack/tacker-specs/+/972517
08:38:44 <takahashi-tsc> any comments?
08:38:46 <hi-koba> This is very helpful. Thank you so much.
08:41:00 <takahashi-tsc> OK, then we’ve covered all the topics today.
08:41:15 <takahashi-tsc> Any others?
08:42:50 <YuyaKuno> One question to KDDI's spec. Is scope of the tenant only Tacker, not tenant in OpenStack (Keystone)?
08:44:02 <hi-koba> OK, I’ll answer the question.
08:46:01 <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:47:34 <YuyaKuno> OK, does the new column of tenant_id associate to tenants/project of Keystone?
08:48:36 <hi-koba> Yes, exactly.
08:49:28 <YuyaKuno> Do we need this specification in the spec to clarify tenant_id?
08:54:33 <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:55:05 <hi-koba> But I think it's okay to write it.
08:55:14 <YuyaKuno> Thank you.
08:56:27 <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:36 <hi-koba> Thank you for your comment.
08:57:02 <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:06 <hi-koba> ok
08:57:43 <takahashi-tsc> Any others, everyone?
08:59:02 <takahashi-tsc> OK, let's close the meeting. Thank you for joining, bye!
08:59:25 <YuyaKuno> Thank you. Bye.
08:59:26 <shivam> Thanks, Bye.
08:59:36 <hi-koba> ok bye!
08:59:40 <takahashi-tsc> #endmeeting