 Good afternoon, everyone. And we see introduced our activities related to open source by four employees. At the end of this session, we do not set the time for Q&A. If you have a question, please catch the speaker and discuss your question later. And this session is provided omnibus mini sessions, not about the final discussion. At the first topic, I would like to talk to you about data science in technology management as an OSPO. My name is Shinon Yuami, and I work to analyze data about open source. She is preparing for various analysis in the company. These analysis are used for identifying open source to invent on development and incorporate into our business. Seeing the volume of open source from JITHAB, 20 million in the other words, 2,000 in Japanese or more repositories per year have increased during COVID-19. It includes non-IT repositories from peaceful graduation messages to political demonstrations. Therefore, our analysis are useful to filter enormous number of OSS. However, sorry. However, there is a common issue across analysis. That is, there are different ways of OSS categorization. Even in one company, we are confused about which one is the best. Especially, it is difficult to categorize a large number of OSS. Namely, we want to explainable categories and automated updates. As reference, CNCF, the Japanese OSS promotion forum and others are providing OSS categories and maps. Thus, I introduce our challenges about OSS classification and categorization. The first methodology is clustering for OSS classification. The methodology uses co-occurrent keywords networks. In the networks, a keyword switcher's GitHub tag is defined as a node and the keywords are connected. If they are in the same repository, after clustering the networks, it was expected that the clusters will indicate OSS categories. This is an example of the result. The top 12 clusters are colored and the top frequent keywords for each cluster are extracted. Although some well-known OSS categories, we identified some interesting categories. For example, the green-third cluster is about video and media. On the figure, the cluster is very dense and it means that keywords are deeply related. Observing each period, Linux is keeping almost the top. Currently, testing tool becomes important as shown in the first position. The conclusions of this methodology are, this methodology is beneficial to discover unconscious fields of OSS. However, for the purpose of OSS categorization, this is not enough because some clusters have mixed-term themes. Thus, at the next step, we are trying VERT multi-categorization. Although this is a work in progress, the techniques such as data augmentation have achieved 0.98 validation accuracy for approximately 400 well-known OSS. In the future, I desire that this methodology will be widely published as everyone can use it. That's all from me. And the next speaker is Akihiro Motoki. Hi, everyone. In this small talk, I will talk about why we contribute to upstream development and recent activities in OpenStack. This, the first half is not specific to OpenStack topics, but Kubernetes contribution will be covered by my next two speakers. So I will mainly talk about OpenStack topics in the second part. Yeah, I'm Akihiro Motoki from NSE. I work on OpenStack upstream development for almost 10 years. And I am serving as a co-reviewer in several OpenStack projects like Neutron, Horizon, and CLI. In addition, currently, I'm reading the OSS OpenSource upstream development team in NSE. My team is currently mainly target contribution to infrastructure-related OpenSource project like Kubernetes, OpenStack, and several CNSF projects. So I talk about the OpenStack and Kubernetes contributions. So this is our recent activities, contribution starts. We contribute to both these softwares actively and we are top 10 contributor in worldwide in recent releases. OpenStack is fourth, fifth, and Kubernetes is also the ninth in the latest releases. So the question is why we contribute to upstream development. So as you may know, branding is one of the reasons. Contribution ranking is easy to understand and customers check who are active in the community to know who is a key player in these softwares. So this is one motivation to contribute. But this is not the only reason. There are more important motivations. So the one is to implement required features in the community directories. So we also would like to fix important bugs and hopefully backport them to the released versions. So this kind of needs are usually based on the feedbacks from the project using OpenStack or Kubernetes and also from support team. So we can ask it to distribute us to implement the requirement. But it usually takes time because they have multiple customers as they need to prioritize various requests from various companies. So if you have a good connection in the community, it will be much faster and smooth because we can implement such things directly. Once changes are merged in the upstream, distributors usually tend to provide them easily. For example, our Red Hat distributions, for example, in the Red Hat distributions, their basic policy is a corresponding feature is included, implemented in the upstream. Another motivation to contribute is avoid local patches. We can implement features as local patches but if we have local patches, we need to update them for every upgrade. So if the community accept these patches, the maintenance cost would be reduced a lot. That's the motivation to contribute. So to make these changes effective efficiently so I think being a key member in the community is important, important. Position names are different depending on communities. So in case of OpenStack, these are called technical committee and project team lead and this kind of hierarchy exists in almost all open source projects. NEC serves as a various position in OpenStack now. We have technical committee seat and serve as a TC chair and we have project lead in Horizon currently and previously we serve the QA and Horizon details too. Also we have core reviewers in Nova Neutron, the core OpenStack project and the N-Tucker NFB project and I also serve as a qualifiers in CLI part. Also we have TC chair members recently was elected to individual board of directors as the main reason to serve as an individual board is to connect development side and the foundation board. So what we are working on now, so roughly speaking we have two areas, we are working on two areas. The one is the OpenStack wide improvements. We consider that OpenStack is considered as a nature so our focus is to improve OpenStack in general rather than specific features. So it is called this kind of effort is called as community goal and technical committee teams are based on feedback from users as leadership position like TC or project lead and we lead these efforts. Recent hot topics, there are two hot topics in this area. One is consistent, secure, role-based access control and the second another one is release cadence adjustment. I will cover them in later slide. The other area is NFB, different from other OpenStack project, TACA project is specific to NFB. NFB means networks function virtualizations. The main goal is to make TACA working reference implementation of NFB. So this effort is a joint effort with telecom carriers. The article has a URL captured recent activities with NTT and KDDIs. The article was published last year that we continue to improve TACA. As NEC, our focus is to improve stability and address feedbacks from production use including the POC's. In next two slides, I will cover the, I will talk about community-wide goals. The first thing is consistent, secure R-back. OpenStack APV provides the mechanism for role-based access control but the current default policy, very simple. We have only two roles, system-wide admin and tenant user. If you'd like to have more granular needs, we need to implement policies, configure policies almost from scratch. This is a pain point from operators. So in this effort, we'd like to define more well-defined default policies. In this effort, it consists of breakdown into several phase and now in the first step, we introduce project leader. Project means they cannot create or delete resources and they can just read the resources and the project member can create and delete resources. In the first step, these roles are revisited. In the second phase, we plan to split service to service API from admin roles and we introduce a service role and currently the service to service communication uses admin role, in most cases, but service should not have such powerful privileges. So that's the second step. The last phase, we are not sure we have more steps. We'd like to introduce a project level admin. They can create users for project or some. The next, the other topic is release cadence adjustment. Currently, the Opusk Update Pass is called the first for the upgrade. This means the upgrade should happen one by one even if we upgrade multiple release at a time. So this is a headache for a large scale crowd. Upgrade usually takes time, so they need to upgrade, upgrade, upgrade, continue to upgrade various nodes one by one. So this effort to mitigate, just mitigate this situation. This is what support upgrade from two release before. The community plans to test this style of upgrade from the next release as experimental. We, in the current plan, official support will start from three release next, 2024. This release will support direct upgrade from A to C. Yeah, that's the currently discussed, current community-wide activities. Then that's all from me. The next speaker is Ken. Ken will talk about testing in open source project. Hi, everyone. I am Ken Chomichi from NEC, and I have worked in some open source projects like Linux, kernel, OpenStack, and Kubernetes and to improve testing and debugging methods after those projects. Then today, I'm going to discuss continuous testing in open source project. In many open source projects, continuous testing are running for keeping good quality of software or product. For example, when a contributor submits a pull request, you need to test many tests like unit tests, integration tests, and E3 tests are operated. If all tests are passed successfully, and code review looks good for the pull request, this pull request is going to be merged into upstream like main branch or master branch. That is main working problem. For if some tests are failed, the contributor needs to investigate the root causes and solve the issue. Otherwise, the pull request never gets reviewed. And as my previous slide, we saw overview of continuous testing in open source projects. Here, we are going to see what kind of tests are running in Kubernetes as a example. As I said, basic tests are running like unit tests, integration tests, and E3 tests. In addition, we are operating coding style check, typo check, document style check, CLA, contributor license agreement check, package names, naming rule check, or something. So each pull request kicks 19 tests pattern, test type, and 45,000 tests kicked automatically. For so many tests and checks implemented and operated like this. As you know, so many contributors are working together in the world and in open source project. And we all have a different background and different culture and so on. And actually, the latest stable version of Kubernetes 1.25, which is computer, sorry, four months development cycle and 1,700 contributors join to the development. And it is in this session, it is so difficult to expect all contributors follow the development guideline. Instead of that, it is possible to make all contributors follow the development guideline and keep a good quality at the scale to improve automated tests and checks. That means we can keep the scalability for open source development. And unit tests and integration tests don't tend to depend on environment. It is enough or fine to run those tests in a single environment out of the CI system. On the other hand, each test depends on environment because we needed to deploy actual target, which is Kubernetes cluster in this case. And we needed to run the test against the deployed Kubernetes cluster. We needed to select operating system, IPv4 or IPv4 and IPv6 dual stack, or what is the container runtime, what is the CNI. We needed to select those things. And from the Kubernetes development, we needed to continue running E2S for many different pattern of Kubernetes clusters. When I joined to the Kubernetes open source project, I proposed test measuring tool, test coverage measuring tool. Kubernetes has an open API definition, specification which is API definition and generated from the implementation code. And I proposed a way to compare the open API specification and E2E test operation log to know which API is not tested during the E2E test. And I created some prototype based on this idea and many people agreed with it. Then today we have API smooth as a separate CNCF project. After this measuring tool, API coverage of E2E tests improved from 70% to 70% today. Sorry, this is so small. And open source software looks like common shared product in the world. We are improving the product for many people. If some tests are also good for many people, we can add those tests into the community. And we can run those tests with community asset. The community asset here means the credit for some sponsoring organization donate to open source foundation like Linux Foundation, CNCA, Open Infra Foundation and so on. By using those credit, open source community can operate those continuous testing on the some cloud provider like Google Cloud for Kubernetes community. Continuous test of open source project also should be good for many people. That should not for some specific people. If implementing continuous tests only for some few specific people, we are wasting not only the community asset but also wasting important developer time to investigating an issue when the issue happened at the test. So we needed to consider what kind of tests should be implemented in open source projects for many people. One good example is how about implementing test cases for hardening environments? I did, CIS Center for Internet Security provides CIS benchmark for Kubernetes. Those benchmarks explain how to make Kubernetes cluster more secure with actual Kubernetes configuration. It is nice to have some tests based on this benchmark for many people. I created a prerequisite, left side based on this idea. If we face some issue on your hardening environment, it would be nice hint to investigate such issues by comparing community test environment configuration and UI environment. And oh, sorry. Next, Muto-san will explain Kubernetes dashboard and Kubernetes upstream training in Japan. Hi, I'm Shu Muto. I'm contributing to Kubernetes dashboard and work as a one-node maintainer and CGUI chair. We are contributing to dashboard to optimize customers Kubernetes user experience. So now I'd like to show you introduction and plan for future next version of dashboard as a maintainer. Kubernetes dashboard is a general purpose web UI for Kubernetes clusters. It allows users to manage clusters and applications running in the clusters and troubleshoot them. The current version is 2.7 and it supported Kubernetes 1.25. Kubernetes dashboard has components for front-end UI and backend API. The front-end UI works as a single page application and backend API interacts with QB API server, hipster and the other third-party components. Now, Kubernetes dashboard is packaged in one binary until the latest release. We split that front-end UI and backend API into each container. And the splitting was done in master branch. We have plan for further improvements, setting up the API gateway that supports GraphQL, these migrating parts of the old APIs into separated microservices. These improvements will allow to optimize to scale each API and migrating current development by buying to support the new architecture. We also have plan to improve the authorization layer that will include supporting OpenID Connect, improving the authorization handling and setting up the microservices for the authorization. We presented this roadmap in KubeCon, Europe in May, and the current status is here. Not only to use, also to keep the Kubernetes and OSS supply chain sustainable, we have to also contribute to community growth. So we are running the Kubernetes upstream training in Japan for who want to get involved into Kubernetes community. Here, we have to mention the reason that prevent Japanese developers from joining community. First is language barrier compared with Western people. Eastern people, such as Japanese, are actually not used to speaking English. However, it seems like everyone in the community communicates in English, and mastering English is the only way to better integrate into the community. Second, cultural barrier. In community, everyone is expected to speak up actively, brainstorm together, and draw conclusions through this whole communication process. However, Japanese people tend to speak, tend to think a lot before they speak, and therefore miss the opportunity to state their opinion. And this makes them to think more and become more and more afraid to speak up. We are aiming to lower these barriers. These are what we tell the trainees in our training. We want to encourage more and more people to get involved in the community. For those who are interested, but don't know where to start, our training so far, an opportunity to work them throughout the whole processes of making contribution. And at the end of the day, most of them will go home with their very first group guest. We also want them to make friends and solve problems related to Kubernetes in Japan. So we added few channels for Japanese conversation. And the most important part is what we want to deliver the following message. Even if you are not fluent in English, you can say anything. Everyone in the community is very kind, so don't be afraid to start. We are running the upstream training eight times since 2019, and we got about 160 contributors. We held our training in these public events. I'd like to thank the organizers of this event for inviting us. Our training contents are based on the Kubernetes new contributor workshop that provided by Kubernetes community. We reorganized this original content for Japanese. These are improvements that we did. Two motivated trainees, we asked the trainees to express their enthusiasm in advance on the Kubernetes structure in Japanese. It would be the first step to join Kubernetes community. To address the guests of the survey for our training, we added introductions to the actual development environment like Cube Spray, website and dashboard, which is the activity area of our trainers. We took photos after the training and made it public so that they can aware of that they became a member of the community. For about a week after the training, our follow-up is carried out until the trainees' prerequisites are merged. Also, we made video and published it to YouTube, then created space for self-training and we reviewed their prerequisites too. Back in 2020, the situation is so bad that we can't leave home, so we had no choice but to hold our events online. So we improved everything we could think of. In that time, we could only prepare a Zoom meeting. Now, we can use webinar and breakout rooms too, but they are needed, taking a few extra steps to share discussions, questions and answers, so we continue to use the basic meeting style. And we make our training resources available for trainees' preparation. Since it was forced to be held online, so we considered pros and cons before running the online training. These pros have made our training easier to organize and the diversity of trainees are getting wider. Our training includes students with limited travel funds, people who doesn't have quiet room and participated from his car, and people rising children and people who are not strong in physical. On the other hand, there was a concern about that intimate support like one-on-one would be difficult. We can look at the trainees' computers and tell them what to do next we used to do. We thought that communication is not as convenient as before through the screen. But in fact, lots of the trainees were able to submit their progress in online training. Its percentage was significantly higher than in person, rather sharing with everyone on track or Zoom and running hard to solve problems remotely that matched the community manner. So concern about difficulty of one-on-one was unfounded fear. Many youths for online tools helped sharing everything with everyone, each other, instantly. And we found that online training is more practical for actual contribution. But sometimes we want to meet people in person. In a non-English native country, motivating, encouragement and support in the local language can be great help in getting started. Online training is more practical for contribution. So online training have already become a default. It is important to train in the environment like GitHub or Slack that actually used in the Kubernetes community and make them feel like they're already part of the community. It is effective to publish all training resources in the open source manner. Our next training will be held at Okinawa Open Days 2022 on December 14th. This training will be held as hybrid. It's a new challenge for us. These proud colleagues will run this training. And we shout out to ex-engineer Akita and very promising members here. Thank you for your great contribution to this training. Thank you everyone for coming to our session at last. Thank you to all of Open Source projects that are made by thanks, respect and collaboration. That's all from us. Thank you.