Inline, my concerns are more with the project status feedback. The project status seems as same as I felt when reviewing the project today. And both from the project tech perspective and also from the experience level of initial committers is also too early to jump into the foundation incubator, before a basic license understanding and requirements and expectations of foundation projects. I highly recommend the project takes a longer time to learn the knowledge and at least build a (small but existing) community that out of Xiaomi to prove the project's real recommended use scenarios.
More details inline. Zhiyong Zhang <goodj...@apache.org> 于2023年9月5日周二 22:33写道： > > > > On 2023/09/05 05:56:51 Sheng Wu wrote: > > Several important things > > The entire project https://github.com/XiaoMi/mone has passed the internal > audit of Xiaomi, and the owners and leaders of the entire project are > consistent with the initiators of the ozhera project. The main donation to > ASF this time is ozhera-all, and other modules follow the Apache protocol, > which will not cause protocol or ownership ambiguity. This doesn't make sense. Apache 2.0 is just a license and it should be based on IP clearance and ownership declaration. These will become two projects, and each of them has different owners, Why suddenly this will not be an issue? > > 1. You are mentioning the donation is about > > `https://github.com/XiaoMi/mone/tree/master/ozhera-all`, It is a part > > of the repository, so will others stay out of the ASF? If so, have the > > project been going through Xiaomi's internal audit about the sharing > > codes between this part of the whole project? Who owns that? > > We hope to complete the internationalization transformation with the help of > ASF; we are preparing the English documents, and a version will be completed > by tomorrow; I am asking whether your community already exists and is ready for the incubator. If you are building an English document today(you have confirmed this), and have no clear documentation, I assume this project is too early. > > 2. I can't see any English document for the project. Is the community > > for a global foundation incubating journey? > > The user interface currently only has Chinese, and the internationalization > of the page requires a longer time to iterate, but we will complete the > transformation of this function in the early stage of incubation; This seems as same as the project is too early to join the foundation. Why so hurry to join rather than being patient to setup the initial community and write good documents What does an incubating project mean for you? > > 3. More importantly, all screenshots and UIs are only in Chinese as well? > > a.We have received full support from Xiaomi's legal affairs and are able to > submit the SGA; > b.The project has gradually recruited partners outside of Xiaomi, and the > initial committers from Xiaomi are also actively participating in the > construction of other open source communities. These are a group of partners > who are passionate about open source. I believe that this group of partners > can continue the project in the long term. What do you mean `recruited`? Does Xiaomi just hire people to do this? > > 4. Have Xiaomi Inc. agreed on this? Will they submit a SGA? Are the > > initial committers still working on Xiaomi and going to continue work > > this project? Will Xiaomi permit their CCLAs? > > We have checked in advance, and we hope to do the replacement and upgrade > during the future incubation period. > > 5. I can see several incompatible licenses of dependencies existing, > > including GPLs. Do you have plans to remove or replace them? Have you > > worked with your mentors to go through licenses of dependencies check? > > There is a relatively clear division of labor among the mentors, and the > mentors will regularly assign us corresponding tasks. Through efficient > project collaboration, we ensure the activity of the community; > At the same time, we can gain more experience and guidance from multiple > mentors, which will further promote the positive cycle development of the > community. > > 6. Why a 10 people PPMC initial team has a mentor team of 6 people? > > Typically, I don't think this is a good practice. Instead, mentors are > > most likely counting on others and will become inactive. > > I hope that ozhera can play its value in the observability of cloud-native > applications. Many components in ozhera (Opentelemetry, Grafana, Prometheus, > MQ, etc.) come from the open source community. We hope to feed back our > experience in the field of application observation to the community through > this platform. The UI design will actively embrace open source like the > backend, but we hope to implement mature solutions from the community for > chart display, currently it is Grafana. > > 7. How would you process the branding? Including you are sharing UI > > design. I have concerns this would be another issues with the main > > project. > > a. We have chosen MySQL and Elasticsearch as the project's storage solutions > based on their excellent performance in their respective fields. The versions > we have chosen strictly comply with the GPL and Apache2.0 agreements. > b. While Elasticsearch has changed from Apache 2.0 to the Server Side Public > License (SSPL), although SSPL is no longer an OSI-approved open source > license, it still allows free use, modification, and distribution, but > imposes some restrictions on commercial use. I think these (a)(b) have approved that 1. The initial team is not working with your mentors closely. 2. The initial team is not experienced enough with Open Source. I am 100% sure, that everyone who had been through the incubating process, would NOT have this answer. This is far away from understanding license compatibility in the foundation. Again, it makes me feel the initial team is also too early to join the incubator. > c. We are also working on storage design. In the future, we will abstract a > complete storage layer interface to decouple the code logic from the specific > storage implementation. This facilitates integrating more alternative storage > solutions. Our project is open and is willing to cooperate with the Apache > Incubator community, mentors, and other relevant parties to resolve potential > license issues. If there is not a single one available solution, why didn't you think deeply about whether your project is suitable for the foundation? ASF's requirements are not hard requirements for every project, but if you join the foundation, it is. It is abnormal for a project to join the ASF incubator, and it can't be used safely with a key part(storage) of the project is Apache 2.0 incompatible. If you even don't know the meaning and there is no clear solution for this, it is pointless to suffer all paperwork, meanwhile, your project is NOT ready from a technology perspective too. > > 8. You are using MySQL and ElasticSearch as storage. The one is on GPL > > and the other is not longer OSI-approved license anymore. What is your > > plan on that? > > Firstly, SkyWalking is an excellent open source APM, with comprehensive > capabilities in tracing, real-time topology, and multi-language adaptation. > The starting point for creating OzHera is to build an enterprise-level > observability platform for the cloud-native era that truly solves the problem > of discovering business issues within 1 minute and locating them within 5 > minutes. > Its core features include: > a. Embracing Cloud-native > It adheres to the Opentracing standard and integrates several renowned > open-source products including Opentelemetry, Grafana, Prometheus, and ES. > Hera also deeply adapts to K8S and provides one-click deployment capability > based on K8S. > b. Accuracy: Availability metrics > Too many alerts essentially equate to ineffective alerts, making the accuracy > of alerts particularly important. No one understands the correctness of > requests better than their own business error codes. We incorporate the > ability to recognize business error codes into the business availability > metrics, allowing business alerts to focus on just this one indicator. At the > same time, we are also expanding SLA metrics to view the availability of > server services from the client's perspective. > c. Excellent Linkage: Metrics-Tracing-Logging linkage > Based on the traceId, we establish a closed-loop linkage of > alarm->indicator->link->log, significantly improving user efficiency in > pinpointing issues. > d. Economical: <0.1% storage cost, satisfying 99.9% of tracing demands > We judge the importance of traces (exceptional span, single span calls > exceeding 1s, error log output, business exception error codes, etc.). Any > trace identified as important is fully retained, while the remaining normal > traces are sampled to ensure efficiency while considering economic costs. > e. Enterprise-level Observable Product > Complete tenant permissions and application management mechanisms make it > easy for users to quickly deploy and integrate their own accounts, CI/CD > systems, etc., within the enterprise. It can also quickly connect to > enterprise office software to achieve alert delivery; > Within Xiaomi, it handles over 100T of data daily in a smooth and efficient > manner; > The core link is well decoupled to facilitate rapid scaling at each stage. > For large volumes of tracing, we have implemented head and tail sampling to > ensure the platform's cost-effectiveness. > > 9 What are the differences between you and SkyWalking? What is this > > new project bringing new to the users? Notice, this is a not a > > rejection for a similar project, but, if they are nearly same, you > > will face competitions in the same foundation but already have larger > > community. All of these statements seem you are actually not taking serious consideration. For most things you mentioned, SkyWalking is able to do it and has better performance behavior, larger scale, and even large ecosystem adoption. SkyWalking could easily support PB level and 100+ billion telemetry data could be collected and analyzed from one SkyWalking cluster years ago. Do you have ever evaluated the differences seriously? Or just think you could do this better. To compare a project, it is also strange to compare in this way. Usually, similar projects co-exist when they have different use scenarios to support rather than a single feature or scale. A mature project is good at that. > > > > Sheng Wu 吴晟 > > Twitter, wusheng1108 > > > > Yu Xiao <xia...@apache.org> 于2023年9月5日周二 11:12写道： > > > > > > Dear incubator community, > > > > > > I would like to propose OzHera[1] as a new apache incubator project, you > > > can find the proposal[2] of OzHera for more detail. > > > > > > OzHera is an application performance observation platform that centers > > > around applications, > > > integrating metric monitoring, link tracing, logs, alerts, and other > > > capabilities. > > > The Hera platform has the following core features: > > > > > > ** Embrace Cloud Native > > > Complies with the Opentracing standard, integrating multiple star > > > open-source products such as OpenTelemetry, > > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply > > > adapts to K8S, > > > providing one-click deployment on K8S through operator. > > > > > > ** Precise: Availability Metrics > > > We have defined corresponding availability metrics for common RPC > > > (Dubbo, HTTP, etc.) requests. > > > These request-scope metrics are automatically extracted from tracing > > > by Hera, and during extraction, > > > we enhance the ability to recognize business error codes. > > > A single metric can accurately express the exceptions encapsulated by > > > RPC and business processing. > > > > > > ** Quick: Metrics-Tracing-Logging Linkage > > > Based on traceId, it links the alarm -> metrics -> link -> log closed > > > loop. > > > From the moment the alarm card touches the user, the user can quickly > > > view the link and log situation related to this alarm, > > > greatly improving the efficiency of problem locating. > > > > > > ** Economical > > > Less than 0.1% storage cost, satisfying 99.9% of tracing demands > > > OzHera achieves the recognition of abnormal calls (error span, > > > abnormal business error codes, > > > error logs, single span time exceeding 1 second, etc.) and ensures the > > > storage of data for the entire call link of abnormal traces. > > > For normal traces, we adopt a default random sampling strategy of one > > > in ten thousand. > > > > > > ** Enterprise-level Observable Products > > > Complete account, permission, application management mechanisms, > > > allowing users to quickly implement within the enterprise and connect > > > to the enterprise’s own account, application deployment system, etc. > > > It can also quickly dock with enterprise office software to achieve > > > alarm touch. Core links are well decoupled for rapid scaling, > > > and for large volumes of tracing, we have implemented tail sampling > > > strategies, > > > able to support high qps, real-time observable demands of high > > > timeliness systems. > > > > > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all > > > [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal > > > > > > Best, > > > Yu Xiao > > > > > > ASF Member > > > Apache ShenYu V.P. > > > Apache Incubator PMC > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
