| kentaro_ | test | 02:32 |
|---|---|---|
| yasufum | hi team | 08:01 |
| ueha | hi | 08:02 |
| h_asahina | hi | 08:02 |
| kentaro | hi | 08:02 |
| takahashi-tsc | hi | 08:02 |
| yasufum | #startmeeting tacker | 08:03 |
| opendevmeet | Meeting started Tue Oct 26 08:03:07 2021 UTC and is due to finish in 60 minutes. The chair is yasufum. Information about MeetBot at http://wiki.debian.org/MeetBot. | 08:03 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:03 |
| opendevmeet | The meeting name has been set to 'tacker' | 08:03 |
| yasufum | There are two topics on etherpad today. | 08:03 |
| yasufum | #link https://etherpad.opendev.org/p/tacker-meeting | 08:04 |
| manpreetk | hi | 08:04 |
| yasufum | hi | 08:04 |
| yasufum | h-asahina and w-juso | 08:04 |
| w-juso | hi | 08:04 |
| yasufum | hi | 08:04 |
| yasufum | Is it OK to start from first item, h-asahina? | 08:05 |
| h_asahina | yes | 08:05 |
| yasufum | go ahead please | 08:06 |
| h_asahina | As I wrote in etherpad, recently, I submitted this patch: https://review.opendev.org/c/openstack/tacker/+/815211 | 08:06 |
| h_asahina | for this bug report: https://bugs.launchpad.net/tacker/+bug/1924917 | 08:06 |
| h_asahina | Actually, I had two plans to fix it, so I'd like to discuss which one is better. | 08:07 |
| h_asahina | The first approach is more consistent with the current implementation, but might incur DB bottleneck. | 08:08 |
| h_asahina | The second approach is opposite. It doesn't cause DB bottle neck, but might not be able to do the same operation as the current implementation. | 08:09 |
| h_asahina | In the submitted patch, I took the first approach. So, the question is which one is more important: avoiding DB bottleneck or keeping consistency of the LCM operation with the current implementation. | 08:10 |
| h_asahina | If you need more information to answer it, please tell me. I'll explain the details of bugs. | 08:11 |
| yasufum | Is that all? | 08:13 |
| yasufum | any comment, everyone? | 08:14 |
| yasufum | I remember that we agreed to not store any temporal status data in database at some previous meeting. | 08:17 |
| yasufum | For the point of view, It might be better to take your option a. | 08:18 |
| h_asahina | I see | 08:19 |
| h_asahina | In that case, we have to give up the correct operation of rollback and retry. Is it ok? | 08:20 |
| h_asahina | Of cource, users can fix by hand, something like running `openstack stack delete` | 08:21 |
| yasufum | However, it depends on how the usecase is critical if we think of changing the decision. | 08:21 |
| takahashi-tsc | In my opinion, option a is OK. Because this is abnormal case and sometimes stored error_point does not work even if we adopt option b. | 08:23 |
| h_asahina | Yes, that makes sense. | 08:24 |
| takahashi-tsc | Rather than error_handling, Tacker should provide force-terminate procedure. | 08:24 |
| h_asahina | You mean adding option like `openstack vnflcm terminate --force`? | 08:25 |
| h_asahina | or just taking the approach a. | 08:26 |
| takahashi-tsc | That is 1 example, but yes. need such operation. > terminate --force | 08:27 |
| h_asahina | I think, in that case, we have to change API, don't we? That's why I didn't take that solution. | 08:27 |
| takahashi-tsc | Yes... Hmm, I understand your point. But the need depends on usecase... | 08:30 |
| h_asahina | If we're allowed to change API even if it results in the violation of SOL definition, I think the solution will be more simple. | 08:32 |
| yasufum | I don’t think we have to keep the APIs as same as SOL completely if it is required. | 08:35 |
| yasufum | without changing behaviors defined in the standards. | 08:36 |
| yasufum | I think `—force` does not overwrite the SOL standards, right? | 08:37 |
| yasufum | It just an extension. | 08:37 |
| h_asahina | Yes. I think so too | 08:37 |
| yasufum | Altough it just my opinion. | 08:37 |
| takahashi-tsc | I think so too. | 08:38 |
| h_asahina | Ok, I'll change the patch, and add the --force option. | 08:38 |
| yasufum | We can suggest such a feature to ETSI standards futhermore | 08:38 |
| yasufum | if it seems agreeable for them. | 08:39 |
| h_asahina | yeah, that's a good idea. | 08:39 |
| yasufum | we can make our policy clear on documentation. | 08:39 |
| yasufum | if we take such a thinking of extension | 08:41 |
| yasufum | Anyway, I agree to h_asahina and takahashi-tsc for the discussion. | 08:41 |
| h_asahina | ok, thanks, for me, what we have to do is clear now. | 08:42 |
| yasufum | other comments? | 08:42 |
| takahashi-tsc | Not form myside, thanks. | 08:43 |
| yasufum | thanks | 08:44 |
| yasufum | So, we can go to the next topic. | 08:44 |
| yasufum | w-juso: did you make an update on Oct 24 for the meeting, right? | 08:45 |
| w-juso | no update, I could discussed our policies, so I'll move it to the bottom. | 08:45 |
| yasufum | Do you mean you will move it to the last part of old topics? | 08:50 |
| w-juso | yes | 08:51 |
| yasufum | OK. I would like to ask you to add the conclusion of the discussion because it is a little bit hard to understand what is the decision at a glance. | 08:53 |
| yasufum | thanks | 08:53 |
| yasufum | Oops, I have found one more topic for today. | 08:53 |
| yasufum | from kentaro | 08:54 |
| yasufum | kentaro: can you share your topic? | 08:54 |
| kentaro | Yes. | 08:54 |
| kentaro | I added a new topic, [Promotion of alignment from OpenStack Tacker to O-RAN SC]. | 08:54 |
| kentaro | Firstly, the overall purpose of this proposal is | 08:55 |
| kentaro | to promote the widespread use of Tacker by inclusion of Tacker code in the VNFM part of the open source code set to be released by O-RAN Software Community (O-RAN SC). | 08:55 |
| kentaro | And the background to this proposal is as follows. | 08:55 |
| kentaro | 1. O-RAN SC is a Linux Foundation project supported and funded by O-RAN to lead the implementation of the O-RAN specifications in Open Source. | 08:55 |
| kentaro | 2. O-RAN SC is developing open source software composed of a combination of existing open source code to realize O-RAN components and systems. | 08:55 |
| kentaro | 3. O-RAN SC has announced a call for contributions to the MANO interface that are directly related to Tacker. | 08:55 |
| kentaro | 4. As a user of Tacker, NTT DOCOMO is considering the application of Tacker to the vRAN domain, and expects to incorporate Tacker into the O-RAN standard reference model. | 08:56 |
| kentaro | The concrete action plan is supposed to be as follows. | 08:56 |
| kentaro | Firstly, we should discuss with OpenInfra Foundation, | 08:56 |
| kentaro | to get their approval to proceed this alignment activity with the intention of the OpenStack organization, | 08:56 |
| kentaro | and to request their support as the entire OpenStack community. (e.g. appealing to the public about the activity) | 08:56 |
| kentaro | After that we will be able to contact O-RAN SC. | 08:57 |
| kentaro | We will give a presentation to O-RAN SC on how Tacker community can contribute. | 08:57 |
| kentaro | I suppose we will provide Tacker sample code and documentation to O-RAN SC and support their technical review. | 08:57 |
| kentaro | That's all my explanation. | 08:57 |
| kentaro | Let me know if you have any questions or comments. | 08:57 |
| yasufum | Do you have any reference for O-RAN, such as project home page or so for helping our understanding. | 09:00 |
| kentaro | O-RAN SC website: https://www.o-ran.org/software | 09:01 |
| kentaro | Latest release code from O-RAN SC: https://docs.o-ran-sc.org/en/latest/ | 09:02 |
| yasufum | thx | 09:02 |
| yasufum | By the way, what do you think who should or might be the representitive for the action plans? | 09:04 |
| yasufum | It looks several plans on the note. | 09:05 |
| kentaro | Basically, I think the Tacker community itself will position as the responsible body toward O-RAN SC. | 09:08 |
| kentaro | We'll decide on a case-by-case basis who will work under the name of the Tacker community. | 09:09 |
| kentaro | for each action plan. | 09:10 |
| yasufum | one more question. | 09:12 |
| yasufum | Is there any milestone or goal for the actions, such as doing a PoC or making agreement? | 09:14 |
| kentaro | The goal is to have Tacker included in the code sets that O-RAN SC releases approximately every six months. | 09:15 |
| kentaro | The next E version will be released in January or February of next year, and I hope to have at least O-RAN SC's agreement on the direction to incorporate Tracker by then. | 09:18 |
| kentaro | That is the most recent milestone. | 09:18 |
| yasufum | I have roughly understood the purpose of your proposal, also still not sure if terms of release are suitable for our release cycles or so. | 09:20 |
| yasufum | Is there any other comment? | 09:21 |
| yasufum | everyone | 09:22 |
| yasufum | good | 09:24 |
| yasufum | I think it seems enough for today. | 09:26 |
| yasufum | So, close this meeting. | 09:27 |
| yasufum | Thanks for joining, bye! | 09:27 |
| manpreetk | bye | 09:27 |
| kentaro | bye | 09:27 |
| takahashi-tsc | bye | 09:27 |
| w-juso | bye | 09:27 |
| esto-aln | bye | 09:27 |
| ueha | bye | 09:27 |
| yasufum | #endmeeting | 09:27 |
| opendevmeet | Meeting ended Tue Oct 26 09:27:39 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:27 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tacker/2021/tacker.2021-10-26-08.03.html | 09:27 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tacker/2021/tacker.2021-10-26-08.03.txt | 09:27 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tacker/2021/tacker.2021-10-26-08.03.log.html | 09:27 |
| *** tosky_ is now known as tosky | 11:25 | |
| *** Guest3656 is now known as redrobot | 13:03 | |
| julianp | Hi Bob. | 21:02 |
| rbudden | hello | 21:09 |
| julianp | How are things rbudden? | 21:09 |
| rbudden | going good, crazy busy trying to get the new cloud in production and the old ones merged into it | 21:10 |
| julianp | Sounds hectic. | 21:10 |
| julianp | When are you hoping to go live? | 21:11 |
| rbudden | beginning to mid November is when the migrations are set to start | 21:12 |
| julianp | Not long! | 21:12 |
| rbudden | and all new tenants/users/VMs target Explore (new cloud name) | 21:12 |
| julianp | Looking forward to hearing how it went. | 21:14 |
| rbudden | I’m sure we’ll have updates and things to talk about once it all comes together :) | 21:15 |
| julianp | Are you going to SC? | 21:15 |
| julianp | Seems like that would overlap with your crunch-time... | 21:17 |
| rbudden | No, Gov has largely banned all travel still due to COVID | 21:18 |
| julianp | Gotcha. Just as well I guess. | 21:18 |
| rbudden | at least in person, some ppl may be doing it virtually | 21:18 |
| julianp | Ahoy martial! | 21:29 |
| martial | Hi Julian | 21:31 |
| martial | Sorry on kid pickup duties | 21:31 |
| julianp | All good. Just hanging out. | 21:32 |
| julianp | Have you had a chance to upload the recordings of the PTG to a Google Drive yet martial? | 21:34 |
| martial | Not yet but will be done shortly | 21:36 |
| martial | Mostly me following up with Ashley | 21:36 |
| julianp | Excellent. | 21:37 |
| rbudden | nice, looking forward to checking out the PTG, unfortunately I wasn’t able to make it this time | 21:38 |
| martial | Bummer | 21:47 |
| martial | Next one is in person in Germany | 21:47 |
| rbudden | spring timeframe I take it? | 21:47 |
| martial | Right before ISC | 21:48 |
| martial | Could be nice back to back | 21:53 |
| martial | Julian thanks for the reminder will email Ashley tomorrow | 21:54 |
| julianp | Of course. Thank _you_ for doing all the hard work of organizing the event and herding all the cats! | 21:54 |
| martial | Herding cats is a specialized OpenStack project 😉 | 21:56 |
| julianp | Hah. Nice. | 21:57 |
| julianp | Well, I'm heading out. See you all next time. 👋 | 21:58 |
| martial | Bye friends | 21:58 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!