Hi guys,
Here is a suggestion. If a change is identified as a large or controversial change. It might require an Improvement Proposal(refer to FLIP*1), and a discussion on the dev mailing list to reach agreement and consensus. 1* https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals Houliang Qi <[email protected]> 于2023年4月12日周三 21:30写道： > A healthy community requires different voices. It is these different > voices that enable us to strictly review each feature and consider each > scenario more comprehensively, so that we can better provide users with > better features. > > I am also very grateful to the colleagues who participated in this > discussion. > > If it is still the previous discussion point, I will stick to my previous > opinion and will not reply again. > > If someone brings up a new discussion point, I think it is possible to > open another discussion. > > > > > > Thanks. > --------------------------------------- > Houliang Qi > BONC, Ltd > > > ---- Replied Message ---- > | From | Houliang Qi<[email protected]> | > | Date | 04/12/2023 20:08 | > | To | [email protected]<[email protected]> | > | Subject | Re: [discuss] consider revert the feature of multi-tenancy | > Hi, > I would like to end by stating my point of view. And I don't want to say > it a second time. > > First of all, I agree to change the name of this feature to resource > control. The reason why I think that both multi-tenancy and > resource-control are suitable for us is that what we are currently doing is > to limit the functions of users or databases resources. > > > @Jinrui 2. A true multi-tenant system should also have features such as > per-tenant configurations, customized tenant roles and permissions, and > clear separation of tenant data. > @Jinrui 3. In our case, the lack of configuration file isolation in the > current implementation means that different tenants may inadvertently > affect each other's configurations, which goes against the core principle > of multi-tenancy. The example I raised in last mail is also used to > illustrate it rather than the function scope definition. > > > > But I disagree with Jinrui said above: > > You can refer to this paper [1]. This document summarizes multi-tenancy > very well. First of all, it does not mean that multi-tenancy must have the > ability to configure isolation. For this feature, we do share > configuration, but our data is logically isolated and can limit some > resources such as cpu, memory, timeseries, etc. This is also a way to > realize multi-tenancy. Of course, each tenant can even use a different > operating system, which is also a way to realize multi-tenancy. Please > don't limit the way to realize multi-tenancy. There I would like to paste a > passage from the paper as a conclusion: > > > By sharing infrastructure, middleware, or application among tenants, > multi-tenancy can be achieved > > In a multi-tenant architecture, a single instance of the software is > deployed on the server functioning on the service provider infrastructure. > It provides access to multiple tenants at the same time, as describe by > Karataş et al. [KCD+17]. Abdul et al. [ABG+18]describe several multi-tenant > data layer models, such as dedicated, isolated, shared, and hybrid. By > sharing infrastructure, middleware, or application among tenants, > multi-tenancy can be achieved. Figure 2.2 visualizes the multi-tenancy > strategies described by Walraven et al. [WLJ14]. However, application-level > multi-tenancy with a shared everything architecture can lead to cost > reduction. Chong et al. [CCW06] have outlined several viable database > patterns, primarily for Microsoft SQL Server, which supports > application-level multi-tenancy. In a multi-tenant situation, they present > three major strategies which are: distinct databases, shared databases with > distinct schemes, and shared databases with shared schemes. > > [1] Enabling multi-tenant scalable IoT platforms. > https://elib.uni-stuttgart.de/bitstream/11682/11024/1/Enabling%20multi-tenant%20scalable%20IoT%20platforms.pdf > > > > > > Thanks, > --------------------------------------- > Houliang Qi > BONC, Ltd > > > ---- Replied Message ---- > | From | Jinrui 张金瑞<[email protected]> | > | Date | 04/12/2023 19:14 | > | To | <[email protected]> | > | Subject | Re: [discuss] consider revert the feature of multi-tenancy | > Hi, > > Perhaps I need to emphasize again that regarding the multi-tenancy section > discussed, the following is my conclusion: > 1. The implementation of the PR cannot be called multi-tenancy > 2. Multi-tenancy is not equal to resource control. > > The reasons are: > 1. While resource isolation or control can be used to enable > multi-tenancy, it's not the only requirement. > 2. A true multi-tenant system should also have features such as per-tenant > configurations, customized tenant roles and permissions, and clear > separation of tenant data. > 3. In our case, the lack of configuration file isolation in the current > implementation means that different tenants may inadvertently affect each > other's configurations, which goes against the core principle of > multi-tenancy. The example I raised in last mail is also used to illustrate > it rather than the function scope definition. > > > @Chao: You think this pr function is missing, and I can understand it, > after all, you have found some bad cases. So next time if there are other > PRs and I find out the bad case, is it better to consider launching a > discussion and reverting it? > > (Jinrui): You have raised a good point. In some cases, reverting the code > might be the best option to prevent further damage. So, yes, please feel > free to start a discussion if you find any issues in the future. I > appreciate your understanding and willingness to consider discussions and > reverts if any bad cases are found in future PRs. It is definitely > welcomed. It’s important for us to maintain a high standard of code quality > and ensure that our users can rely on our product. Let's continue to work > together to achieve this goal. > > Thanks, > Zhang Jinrui > > 2023年4月12日 下午6:13，Chao Wang <[email protected]> 写道： > > Hi， > > > Especially when exposing these concepts to users, we don't want to create > any misunderstandings about the core functionality of IoTDB, which is also > mentioned in Xiangdong's mail. That's why we need to be precise in our > definitions and avoid interchangeable usage of terms that could lead to > confusion. > > > I agree that the term multi-tenancy is somewhat imprecise in a sense and > can be modified to avoid unnecessary misunderstandings. But just like the > multi-tenant form you defined, what will be affected? Based on resource > isolation technology or resource control technology, what's wrong with > providing services to multiple tenants and declaring that this is a > multi-tenant function (possibly weak)? > > > I think it is good for everyone to discuss the definition clearly. Before > the definition is clear, there is no need to question a bunch of questions > first. > > > However, based on my personal judgment and the current state of the code, > I don't believe it's ready to be merged yet due to its significant missing > functionality. > > > I have tested the code and the steps below are working. I think the basic > functions are done. > > > set space quota timeseries=3 on root.test > create timeseries root.test.wf01.wt01.status with > datatype=BOOLEAN,encoding=PLAIN > create timeseries root.test.wf01.wt01.status1 with > datatype=BOOLEAN,encoding=PLAIN > create timeseries root.test.wf01.wt01.status2 with > datatype=BOOLEAN,encoding=PLAIN > create timeseries root.test.wf01.wt01.status4 with > datatype=BOOLEAN,encoding=PLAIN > > > The fourth statement will report an error. > > > > > You think this pr function is missing, and I can understand it, after all, > you have found some bad cases. So next time if there are other PRs and I > find out the bad case, is it better to consider launching a discussion and > reverting it? > > > > > > > > > > > Thanks! > > > Chao Wang > BONC ltd > On 4/12/2023 17:28，Jinrui 张金瑞<[email protected]> wrote： > Hi, > > @Chao: Well, there is a difference between multi-tenancy and resource > control as you define. Sometimes in communication, a certain application > form is often used to refer to the core technology or representative > technology, or the core technology represents a certain application form. I > think it is not accurate, but it is acceptable. Just like when I say cloud > native, I will naturally think of k8s, and when it comes to containers, I > will think of docker. I think the core technology of multi-tenancy is > resource control or isolation, so it is also possible to mention > multi-tenancy. Functions similar to multi-tenancy can be realized based on > the resource control function. > (Jinrui): I understand your point of view, but I still believe that there > is a difference between multi-tenancy and resource control. While it may be > acceptable to use a certain application form to refer to a core technology > or representative technology, I think it's important to be accurate in our > terminology, especially when it comes to technical discussions. In my > opinion, the core technology of multi-tenancy is about providing separate > environments for different tenants, while resource control or isolation is > a means to achieve that. While functions similar to multi-tenancy can be > realized based on the resource control function, I think it's important to > distinguish between the two and use the appropriate term depending on the > context. > Especially when exposing these concepts to users, we don't want to create > any misunderstandings about the core functionality of IoTDB, which is also > mentioned in Xiangdong's mail. That's why we need to be precise in our > definitions and avoid interchangeable usage of terms that could lead to > confusion. > > @Chao: I think there is a problem with this code and it needs to be fixed. > You can continue to submit the code to fix it. We don't need to revert and > wait for the repair to be completed before submit it. What you emphasize is > that it affects the stability of the code, so it's better to revert. I > Agree with that. But I don’t see how a function that is turned off by > default affects the stability and affects the user? Has it affected the > development of other functions? Does it affect pipeline testing? Only > bug-free code does not affect stability? As Houliang said, can someone be > sure that their code has no bugs? > (Jinrui): While it's true that no one can guarantee bug-free code, it's > also important to ensure that the code meets the minimum requirements for > functionality and stability. We don't want to risk introducing more issues > to the system by merging incomplete or flawed code. I would like to clarify > that the current issue with the code is not just about the presence of > bugs, but also about the basic functionality that is missing. Furthermore, > even if the function is turned off by default, it could still have an > impact on the development of other functions. > I understand that we may have different opinions on whether this code > should be merged or not. If you think it's acceptable to merge the code, I > respect your opinion and we can proceed accordingly. However, based on my > personal judgment and the current state of the code, I don't believe it's > ready to be merged yet due to its significant missing functionality. > > > @Houliang: Second: why can't we call it multi-tenant? We can achieve > logical isolation of data through this feature and auth permission, and we > can also manage and control users and database resources. Doesn't this just > verify what you said above? > (Jinrui): Let's say there are two tenants in the system, Tenant A and > Tenant B. In the current implementation, if Tenant A disables the > compaction function, it will also be disabled for Tenant B. This means that > Tenant B has no control over this feature and must accept the configuration > set by Tenant A. This is not an ideal scenario for multi-tenancy, as each > tenant should be able to configure their own settings independently without > affecting other tenants. > Additionally, if one user modifies the configuration of their IoTDB > instance, it can potentially impact the experience of other users sharing > the same resources. This is not desirable for multi-tenancy, as each tenant > should be isolated from each other and their actions should not impact > other tenants. > Therefore, it's important to have proper multi-tenancy implementation to > avoid these kinds of issues and ensure each tenant can operate > independently without interfering with each other. > > Thanks, > Zhang Jinrui > > > 2023年4月12日 下午4:08，Houliang Qi <[email protected]> 写道： > > Hi, Jinrui > > > (Jinrui): Just like how I believe that multi-tenancy and multi-user are > not the same thing, regarding the suggestion to interchange "multi-tenancy" > and "resource control," while they may have some similarities in concept, > they are not interchangeable. > > First of all, you misunderstood me. I never said that multi-tenancy and > multi-user are the same thing. What I want to emphasize is: one user per > tenant is also one of the ways to realize multi-tenancy, and one tenant > manages one database, which is also one of the ways to realize > multi-tenancy, and dories, spanner also has such an implementation. > > (Jinrui): multi-tenancy is a specific approach to architecture that > enables multiple tenants to share the same resources while keeping their > data isolated, whereas resource control is a broader term that can refer to > any mechanism used to manage and allocate system resources. > > Second: why can't we call it multi-tenant? We can achieve logical > isolation of data through this feature and auth permission, and we can also > manage and control users and database resources. Doesn't this just verify > what you said above? > > > > > > > Thanks, > --------------------------------------- > Houliang Qi > BONC, Ltd > > > ---- Replied Message ---- > | From | Jinrui 张金瑞<[email protected]> | > | Date | 04/12/2023 14:55 | > | To | <[email protected]> | > | Subject | Re: [discuss] consider revert the feature of multi-tenancy | > Hi, > > > the following description assumes that multi-tenancy = resource control, > the two words can be interchanged. Are there any objections? > > (Jinrui): Just like how I believe that multi-tenancy and multi-user are > not the same thing, regarding the suggestion to interchange "multi-tenancy" > and "resource control," while they may have some similarities in concept, > they are not interchangeable. Multi-tenancy is a specific approach to > architecture that enables multiple tenants to share the same resources > while keeping their data isolated, whereas resource control is a broader > term that can refer to any mechanism used to manage and allocate system > resources. > > Based on this, continue to infer, if it is found that the released version > has a bug a few days after it was released, should the release be > cancelled, and it is better to wait for the bug to be fixed. > (Jinrui): Actually, we were not discussing how to do code control. But > since you brought up the issue of code quality, do you think the current > code is of sufficient quality to be merged? Or did you notice the issue > when reviewing the code? Of course, I understand that we don't have a > quantifiable standard to judge whether code is mergeable or not, and > everyone has their own criteria for making that judgment. Regarding your > question about cancelling a release if a bug is found a few days after it > was released, I think it depends on the severity of the bug and the impact > it has on users. If the bug is minor and does not affect the core > functionality of the software, it may be acceptable to wait for the bug to > be fixed in the next release. However, if the bug is severe and causes > major issues for users, it may be necessary to cancel the release and fix > the bug immediately. > > As for the fact that it hasn’t been fixed for two days, this function is > being discussed whether it should be discarded or not. Does it still take > time to fix bugs? > > (Jinrui): I didn't fully understand what you meant, could you please > explain it again? > > Thanks, > Zhang Jinrui > > 2023年4月12日 下午1:35，Chao Wang <[email protected]> 写道： > > Hi all, > > > It seems that Houliang didn't make it very clear before. Let me add some > more information. > > > If you think this code is doing multi tenant things now, why do we need to > change the name to some other words like resource control ? Is it > just to > prevent users from misunderstandings from the definition? If that's the > case, does it mean that users perceive multi tenancy as different from what > we do? This is contradictory. > > > Why change multi-tenancy to resource control is just because everyone’s > perception of multi-tenancy is not very unified. It may be more unified to > change it to resource control. This should not be contradictory. > > > Suppose, under the advance statement in pr, the following description > assumes that multi-tenancy = resource control, the two words can be > interchanged. Are there any objections? > > > It has been two days since this code was merged, and I don't know if > anyone is fixing the issue I mentioned. Bug is definitely accepted, but I > don't think this issue belongs to a 'bug' because it failed even the most > basic functional testing. > > > > > From your test, it is true that there is a problem with this pr, and there > is no pr fix at present. For the stability of the code base, it should be > better to revert, even if this function is turned off by default (reminds > me of developing a new version of distributed Framework, it seems that many > codes are merged when they can't run, I don't know if it's suitable for > this scenario). Then according to this inference, whether all PRs in the > future have to repair and submit bugfix immediately once a bug is found, > and it is better to revert after a certain period of time (assuming 2 > days). Based on this, continue to infer, if it is found that the released > version has a bug a few days after it was released, should the release be > cancelled, and it is better to wait for the bug to be fixed. > > > As for the fact that it hasn’t been fixed for two days, this function is > being discussed whether it should be discarded or not. Does it still take > time to fix bugs? > > > > > Thanks! > > > Chao Wang > BONC ltd > On 4/12/2023 11:26，张金瑞<[email protected]> wrote： > Hi all, > > > Although it seems that we have reached an agreement on what this PR really > did, there are a few issues that I think are still unclear and need to be > further discussed. > > > > @Houliang said in previous mail: "a user is a tenant, and each tenant > has different resources. This is also multi-tenancy" > (Jinrui) Everyone difinitely can have their own understanding of > multi-tenancy but I don't think "Tenant is equal to User". We can refer the > definition of MultiTenancy from wikipedia here > https://en.wikipedia.org/wiki/Multitenancy. I think no matter how we > define the concept of multi tenant ourselves, the reaction of most users > when they see this word is more important when they use IoTDB. On the other > hand, If you think this code is doing multi tenant things now, why do we > need to change the name to some other words like resource control ? Is it > just to prevent users from misunderstandings from the definition? If that's > the case, does it mean that users perceive multi tenancy as different from > what we do? This is contradictory. > > > > > @Houliang said in previous mail: "I STRONGLY think that > this PR does not violate the positioning and future development of IOTDB, > so I STRONGLY think that revert is not needed" > (Jinrui) I think the first part of my previous mail is not noticed. > Maybe I need to emphasize it again. I didn't say that it was a MUST to > perform a revert. What actually I said is if there is significant > uncertainty in the code, revert is a quick way to make the repo keep > stable. And I also appended a simple test report in last mail. And the test > report showed that a very simple scenario cannot passed when enable the > feature. It has been two days since this code was merged, and I don't > know if anyone is fixing the issue I mentioned. Bug is definitely accepted, > but I don't think this issue belongs to a 'bug' because it failed even the > most basic functional testing. > > > > Thanks, > Zhang Jinrui > > > Original > > > > From:"Jialin Qiao"< [email protected] >; > > Date:2023/4/11 21:47 > > To:"dev"< [email protected] >; > > Subject:Re: [discuss] consider revert the feature of multi-tenancy > > > Hi, > > > I think we have reached a consensus from the discussion, change the > name of this feature to resource control, and continue to contribute to > this feature. > > +1, Thanks for Houliang and Yuhua's contribution! We indeed need a > resource control module to keep the system safe :) > > Best, > ————————————————— > Jialin Qiao > Apache IoTDB PMC > > Houliang Qi 于2023年4月11日周二 16:02写道： > > > > Hi, all > > > > > > I think we have reached a consensus from the discussion, change the > name of this feature to resource control, and continue to contribute to > this feature. > > Thank you for your concern. > > > > > > > > > > > > Thanks, > > --------------------------------------- > > Houliang Qi > > BONC, Ltd > > > > > > ---- Replied Message ---- > > | From | Xiangdong Huang | > > | Date | 04/11/2023 15:39 | > > | To | | > > | Subject | Re: [discuss] consider revert the feature of > multi-tenancy | > > Hi Houliang, > > > > It makes no sense to refer Doris. Doris is not a lightweight db, and > > edge side is never its goal. > > > > The topic of this discussion is whether to revert the feature of > multi-tenancy. > > > > I wonder why you fall into these words.... I think I have mentioned at > > least twice (or maybe 3 times) that Jialin's suggestion is fine for > > me. > > > > Best, > > ----------------------------------- > > Xiangdong Huang > > School of Software, Tsinghua University > > > > > > Houliang Qi 于2023年4月11日周二 15:05写道： > > > > Hi Jinrui, > > > > (Jinrui) From my perspective, Multi-tenancy is different from > resource-control and they are not the different term for same thing. > According to our implementation, current feature focus on the resource > control on users of one tenant rather than on different tenants. If we did > not reflect the wording `multi-tenancy` in the code, why do we use it on > user docs and PR's description ? > > > > Sorry, I am not agree with you, from my perspective, a user is a > tenant, and each tenant has different resources. This is also > multi-tenancy. Even each tenant can only have one db. In our current > implementation, a user is a tenant. > > For doris, they also mention multi-tenancy, but it is limited user > resources.[1], the same as our current implementation. > > For Spanner, a tenant can also have only one db. [2] > > The reason why I think that both multi-tenancy and resource-control > are suitable for us is that what we are currently doing is to limit the > functions of users or db resources. > > On this point, I agree with Wang Chao's point of view. > > > > As for whether the multi-tenant function you mentioned affects the > positioning of IoTDB, I don't think it is accurate. I personally think > that the multi-tenant function is a term for resource isolation technology > and will not affect the positioning of IoTDB. I don't know how you define > the multi-tenant function. If it refers to the connection with the billing > system of the cloud service provider, it may be another form. This > discussion will not continue to discuss multi-tenancy. > > > > > > > > (Jinrui) REVERT does not mean REJECT. It is only a quick way to keep > the code more reliable before we reach the same page. And furthermore, I > don't think it is harmful or discouraging and it is only a regular way we > use to replace hot-fix. > > (Jinrui) The reviewers may be confused by the PR's description and > then focus on whether `multi-tenant` should be integrated in current > development stage of IoTDB. > > > > The topic of this discussion is whether to revert the feature of > multi-tenancy. I STRONGLY think that this PR does not violate the > positioning and future development of IOTDB, so I STRONGLY think that > revert is not needed, as this function is not enabled by default, and we > are continuing Iterate and refine this feature. Before the actual release, > it is necessary to consider some scenarios and do some testing. > > > > > > > > [1] https://doris.apache.org/docs/dev/admin-manual/multi-tenant/ > > <https://doris.apache.org/docs/dev/admin-manual/multi-tenant/>>; > [2] > https://cloud.google.com/solutions/implementing-multi-tenancy-cloud-spanner > > > <https://cloud.google.com/solutions/implementing-multi-tenancy-cloud-spanner>> > ; > > > > Thanks, > > --------------------------------------- > > Houliang Qi > > BONC, Ltd > > > > > > ---- Replied Message ---- > > | From | Chao Wang | > > | Date | 04/11/2023 13:42 | > > | To | [email protected] | > > | Subject | Re: Re：Re: [discuss] consider revert the feature of > multi-tenancy | > > Everyone's contribution counts. But what we are talking about is > whether `multi-tenancy` is suitable for current IoTDB's development. > > From my perspective, Multi-tenancy is different from resource-control > and they are not the different term for same thing. According to our > implementation, current feature focus on the resource control on users of > one tenant rather than on different tenants. If we did not reflect the > wording `multi-tenancy` in the code, why do we use it on user docs and PR's > description ? > > > > > > As I said before, the description is indeed not very clear, and the > description can be modified as a resource control. So what's the point of > wondering if this pr is a multi-tenant function? Even if it is a > multi-tenant function, how will it affect the development of IoTDB? > > > > > > REVERT does not mean REJECT. It is only a quick way to keep the code > more reliable before we reach the same page. And furthermore, I don't think > it is harmful or discouraging and it is only a regular way we use to > replace hot-fix. > > > > > > Yes, revert is a normal process, and PR also has some problems. Let's > discuss the reason for reverting this PR. As Xiangdong said, this is a > feature that will affect the positioning of IoTDB, so how does this feature > affect the positioning of IoTDB? > > > > > > Agree. But if we don't make it clear before PR merged, pushing > forward the discussion is better than directly merging, from my side. > > > > > > Agree. I remember sending an email to discuss it. Does that mean > that every PR needs to send an email to discuss clearly? After all, pushing > forward the discussion is better than directly merging. > > > > > > > > > > Thanks! > > > > > > Chao Wang > > BONC ltd > > On 4/11/2023 13:10，张金瑞<[email protected]> wrote： > > (Sorry for the format issue in previous mail) > > ====== > > Hi, all > > > > I tried this feature locally according to the User Manual, and I am > blocked at the beginning. > > > > > > Firstly, I didn't found the parameters `quota_enable` and > `rate_limiter_type` in iotdb-common.properties to enable this functionality. > > I am not sure whether it is by design but it is not aligned with the > user manual. And I have to add these two parameters into configuration file > manually. > > > > > > Then, I tried the function to limit devices regarding a database and > it seems some basic functionality is unexpected. See the test step below: > > 1. create a databse named `root.iov` and insert 5 devices into it. > > 2. run the command "set space quota devices=4 on root.iov" to set the > device limit to 4. It can be executed successfully. (UNEXPECTED) > > 3. try to insert a new devices. > > 4. try to use the command "set space quota devices=8 on root.iov" to > increase the threshold of device count but failed. (UNEXPECTED) > > 5. I created another database named `sg2` and tried to set quota > limit to it but failed (UNEXPECTED) > > 6. After this test, I tried another test with more simple scenario > but still failed. > > > > > > The detailed test steps can be found in this doc: > https://apache-iotdb.feishu.cn/docx/IerZdPFHroEbRYxKvihcBpncnie > > <https://apache-iotdb.feishu.cn/docx/IerZdPFHroEbRYxKvihcBpncnie>>; > > > My confidence in the completeness of testing regarding this feature > has greatly decreased. And at least from my perspective, I cannot guarantee > how much impact this feature will have on the user experience. > > > > > > On the other hand, I also have some thoughts to share with you > regarding the questions raised in the previous email. > > > > > > >> Leaving aside this feature, has the PR of the big feature we > merged in been discussed in detail? How to define detailed discussion? > > (Jinrui) I think currently we are focusing on the side effects of > this PR, whether the discussion is detailed depends on whether we have > enough confidence of this feature's definition and implementation. > > > > > > >> I think that we should discuss some of our discussion > points clearly at the beginning of the design, instead of how to revert the > PR after the PR is merged. I think there is a problem with this process. > > (Jinrui) Agree. But if we don't make it clear before PR merged, > pushing forward the discussion is better than directly merging, from my > side. > > > > > > >> Who can guarantee that there are no bugs and no problems in > the developed functions, and we are all improving through continuous > iteration > > (Jinrui) Yes. But the developer should do enough tests including > different scenarios to ensure this feature can work smoothly. > > > > > > >> However, reverting will undoubtedly be harmful to the > community, will discourage the enthusiasm of community participants, and is > very unfriendly to community participants > > (Jinrui) REVERT does not mean REJECT. It is only a quick way to keep > the code more reliable before we reach the same page. And furthermore, I > don't think it is harmful or discouraging and it is only a regular way we > use to replace hot-fix. > > > > > > >> If in doubt, I think it would be better to raise it as soon > as possible, instead of waiting for others to finish their hard work before > questioning. > > (Jinrui) My words has no doubt and offense to anyone and it is only a > discussion about this issue. Contribution is welcomed and talking is also > welcomed. If we notice some potential issue which is worth to be talked > about, any time is ok I think. > > > > > > >> This discuss is not for getting "+1" or "-1" (though anyone > can reply the vote..). I just want to discuss that do we REALLY consider > and analyze the feature and the implementation carefully? > > (Jinrui) The reviewers may be confused by the PR's description and > then focus on whether `multi-tenant` should be integrated in current > development stage of IoTDB. > > > > > > >> As for the name of this feature, in doris, it is called > multi-tenancy[1], in hbase it is called quota[2], we can call it > resource-control, I think it is ok. > > (Jinrui) From my perspective, Multi-tenancy is different from > resource-control and they are not the different term for same thing. > According to our implementation, current feature focus on the resource > control on users of one tenant rather than on different tenants. If we did > not reflect the wording `multi-tenancy` in the code, why do we use it on > user docs and PR's description ? > > > > > > >> Another point is that the multi-tenancy function may be a > function required by other companies' IOTDB releases, but will other > people's contributions to the community affect the development of the > community? > > (Jinrui) Everyone's contribution counts. But what we are talking > about is whether `multi-tenancy` is suitable for current IoTDB's > development. > > > > > > > > > > Thanks, > > Zhang Jinrui > > > > > > > > > > > > > > > > > > Original > > > > > > > > From:"Xiangdong Huang"< [email protected] >; > > > > Date:2023/4/11 12:27 > > > > To:"dev"< [email protected] >; > > > > Subject:Re: [discuss] consider revert the feature of multi-tenancy > > > > > > Hi Houliang, > > > > Notice that I never said the feature should be reverted because of > > bugs.. The key point is the feature is harmful for Industry users > > because most of them do not like cloud. (that is why I opt for > > Jialin's suggestion). > > > > > I think that we should discuss some of our discussion points > clearly at the beginning of the design, instead of how to revert the PR > after the PR is merged. I think there is a problem with this process. > > > > It is of course right, but it does not mean that we can not revert a > > PR if it is merged. > > > > > Leaving aside this feature, has the PR of the big feature we > merged in been discussed in detail? How to define detailed discussion? > > > > Yes for each big feature we need a discussion in detail. As I have no > > much time to join all the features, being the PMC chair, at least I > > need to keep the project following its original destination or new > > destination if we all agree. > > > > Considering my personal time, I judge and intervene featuers which may > > change the product's position. That is why I spent time to discuss > > whether we redesign the cluster mode, whether we split an IoTDB > > instance into two (CN and DN), and whether we tell IoTDB is for > > cloud-native... And that is why I do not care about more detailed > > features.. > > > > Best, > > ----------------------------------- > > Xiangdong Huang > > School of Software, Tsinghua University > > > > Houliang Qi 于2023年4月11日周二 09:51写道： > > > > > > Hi, all > > > > > > > > > Leaving aside this feature, has the PR of the big feature we > merged in been discussed in detail? How to define detailed discussion? > > > > > > I think that we should discuss some of our discussion points > clearly at the beginning of the design, instead of how to revert the PR > after the PR is merged. I think there is a problem with this process. > > > > > > Who can guarantee that there are no bugs and no problems in the > developed functions, and we are all improving through continuous iteration. > And this feature also refers to the design of some other excellent > projects, such as doris and hbase. > > > > > > As for the name of this feature, in doris, it is called > multi-tenancy[1], in hbase it is called quota[2], we can call it > resource-control, I think it is ok. After all, we did not reflect the > wording of multi-tenancy in the code implementation. > > > > > > > > > > > > [1] https://doris.apache.org/docs/dev/admin-manual/multi-tenant > > <https://doris.apache.org/docs/dev/admin-manual/multi-tenant>>; > > [2] https://hbase.apache.org/book.html#quota > > > > > > > > > > > > > > > Thanks, > > > --------------------------------------- > > > Houliang Qi > > > BONC, Ltd > > > > > > > > > ---- Replied Message ---- > > > | From | Chao Wang | > > > | Date | 04/11/2023 09:15 | > > > | To | [email protected] | > > > | Cc | [email protected] | > > > | Subject | Re: [discuss] consider revert the feature of > multi-tenancy | > > > Hi, Xiangdong, > > > > > > > > > what is the side effect when we manually create a time series? > > > > > > > > > How about the pr https://github.com/apache/iotdb/pull/9430, > limit the timeseries number of cluster, anyone analyze the side effect > about creating a time series? > > > > > > > > > This discuss is not for getting "+1" or "-1" (though anyone can > reply > > > the vote..). > > > I just want to discuss that do we REALLY consider and analyze the > > > feature and the implementation carefully? > > > > > > > > > Why not discuss before the PR submission, but wait until the PR > submission before discussing, wouldn't it waste the energy of community > participants? I have also seen emails sent before, not without notifying > everyone. > > > > > > > > > > > > > > > In addition, I think Jialin's suggestion is more reasonable. The > description of this function may not be particularly clear. It can be said > in another way, such as resource control. However, reverting will > undoubtedly be harmful to the community, will discourage the enthusiasm of > community participants, and is very unfriendly to community participants. > If in doubt, I think it would be better to raise it as soon as possible, > instead of waiting for others to finish their hard work before questioning. > > > > > > > > > Another point is that the multi-tenancy function may be a > function required by other companies' IOTDB releases, but will other > people's contributions to the community affect the development of the > community? I think it will be more conducive to the development of > community diversity. > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > Chao Wang > > > BONC ltd > > > [email protected] > > > On 4/10/2023 23:45，Xiangdong Huang wrote： > > > Besides the above, when we merge this pr, we posted the design > in the feishu[4] and discussed it online as least two times, and emailed > and discussed it with everyone[5], it has been passed 10 days. > > > > > > I think I know this and I have shown my concern about the > possible > > > harm of this featuer to IoTDB's edge mode... > > > > > > 1) how many side-effects the feature will bring; > > > We have done some tests under[1], which says with 20 databases > and 1 user when we set `quota_enable` to true to enable the multi-tenancy > feature, the write performance is only slowed down 1.75%, the read latency > has not much difference, we will do more tests to show the side-effects in > the feature. > > > > > > The experiment is rather simple... > > > When we really want to show the added codes having no > side-effects, > > > all the exepriemnt settings should follow a rule that how to > fully > > > expose the possible problems. > > > > > > For example, as mult-tenancy limits the available # of devices, > > > timeseries, and the spaces of disk, it should have side-effect on > > > create new device/timeseries, and writing new data. > > > So, > > > - what is the side effect when we manually create a time series? > > > - what is the side effect when we use automatical creating a > time series? > > > - what is the side effect when we write new data? (as the data > can be > > > compressed when it is flushed on disk in async mode, how to > check the > > > disk space?). Besides, as it impaces each write operation, we > need to > > > focus on write operstions which's batchsize=1. > > > > > > This discuss is not for getting "+1" or "-1" (though anyone can > reply > > > the vote..). > > > I just want to discuss that do we REALLY consider and analyze the > > > feature and the implementation carefully? > > > > > > If not, then this big feature is not the time to be merged (and > I will > > > call a vote then), and then let's rethink it and make it really > > > available together. > > > If yes, we also need to rethink it and improve it for better > performance. > > > > > > > > > Best, > > > ----------------------------------- > > > Xiangdong Huang > > > School of Software, Tsinghua University > > > > > > Chao Wang 于2023年4月10日周一 19:14写道： > > > > > > Agree with Houliang's opinion. > > > > > > > > > Thanks! > > > > > > > > > Chao Wang > > > BONC ltd > > > On 4/10/2023 19:01，Houliang Qi wrote： > > > -1 > > > > > > First of all, thanks Xiangdong for pointing out IoTDB's Charter. > > > > > > "RESOLVED, that the Apache IoTDB Project be and hereby is > > > responsible for the creation and maintenance of software > > > related to an IoT native database with high performance > > > for data management and analysis, on the edge and the cloud." > > > > > > As the charter post, IoTDB can be deployed in the cloud, this is > why we deploy the multi-tenancy feature. > > > > > > The cloud can be a public or private cloud if we can deploy only > one IoTDB cluster, and manage multi databases and users with different > resources, which will simplify the maintenance. > > > > > > -> 1) how many side-effects the feature will bring; > > > > > > We have done some tests under[1], which says with 20 databases > and 1 user when we set `quota_enable` to true to enable the multi-tenancy > feature, the write performance is only slowed down 1.75%, the read latency > has not much difference, we will do more tests to show the side-effects in > the feature. > > > > > > -> 2) how to reduce the effect when IoTDB is deployed on the > edge. > > > > > > We supply one switch about this feature, called `quota_enable`, > by default this value is false, so it has no effect when IoTDB is deployed > on the edge. > > > This also answers Jinrui's doubt. > > > > > > -> 3) some checks failed on WinOS, are they irrelevant? > > > > > > No, I think they are not irrelevant, the false check message is > about the Compaction module, and > > > I see the former pr[2][3] which have been merged 4 days ago has > the same issue, so I suspect that the compaction module has occasional bugs > > > > > > -> 4) The feature SHOULD be discussed carefully in the > community, rather that submit PRs and merged after some reviews. > > > > > > Besides the above, when we merge this pr, we posted the design > in the feishu[4] and discussed it online as least two times, and emailed > and discussed it with everyone[5], it has been passed 10 days. > > > > > > > > > The IoTDB community is open and different opinions are welcome. > After all, we all have the same original intention of wanting IoTDB's > features to be more diverse. > > > > > > [1] > https://apache-iotdb.feishu.cn/docx/DbqCd8t3EoxlCFx1yYicd9N4n4s > > <https://apache-iotdb.feishu.cn/docx/DbqCd8t3EoxlCFx1yYicd9N4n4s>>; > > [2] > https://github.com/apache/iotdb/actions/runs/4625220921/jobs/8181102446 > > > <https://github.com/apache/iotdb/actions/runs/4625220921/jobs/8181102446>>; > > [3] > https://github.com/apache/iotdb/actions/runs/4531046594/jobs/7980725316 > > > <https://github.com/apache/iotdb/actions/runs/4531046594/jobs/7980725316>>; > > [4] https://apache-iotdb.feishu.cn/docx/doxcnKOYKDmJ40FpVnVsPMd3nTg > > <https://apache-iotdb.feishu.cn/docx/doxcnKOYKDmJ40FpVnVsPMd3nTg>>; > > [5] https://lists.apache.org/thread/y6dqcm2o7qk0nbkllb61bp8cv6d3m1h7 > > <https://lists.apache.org/thread/y6dqcm2o7qk0nbkllb61bp8cv6d3m1h7>>; > > > > > > > > > > > > > > > > > Thanks, > > > --------------------------------------- > > > Houliang Qi > > > BONC, Ltd > > > > > > > > > ---- Replied Message ---- > > > | From | 张金瑞<[email protected]> | > > > | Date | 04/10/2023 15:03 | > > > | To | dev | > > > | Subject | Re：[discuss] consider revert the feature of > multi-tenancy | > > > +1, > > > > > > > > > Agree with Xiangdong's opinion. > > > And on the other hand, checking this PR's side effects may > take lot of time and during this period, there may be lots of users > using latest code to deploy/upgrade their systems. So the best practice is > reverting this PR until the side-effect is eliminated > > > > > > > > > > > > Thanks, > > > Zhang Jinrui，Apache IoTDB PMC > > > > > > > > > > > > Original > > > > > > > > > > > > From:"Xiangdong Huang"< [email protected] >; > > > > > > Date:2023/4/10 10:05 > > > > > > To:"dev"< [email protected] >; > > > > > > Subject:[discuss] consider revert the feature of multi-tenancy > > > > > > > > > Hi all, > > > > > > I see the multi-tenancy feature is merged, and several > committers made > > > a lot of contributions on that. > > > > > > As multi-tenancy is quite a big feature, which may change IoTDB's > > > position. The feature SHOULD be discussed carefully in the > community, > > > rather that submit PRs and merged after some reviews. > > > > > > Therefore, I call to revert the PR and discuss ASAP about the > feature > > > after that. > > > > > > At least, the proposer need to answer the following questions, > > > 1) how many side-effect the feature will bring; > > > 2) how to reduce the effect when IoTDB is deployed on the edge. > > > 3) some checks failed on WinOS, are they irrelevant? > > > > > > I don't mean of rejecting any big contribution to IoTDB or > harming the > > > community's diversity, but accepting this feature is really big > > > decision and it deserves us to take time to deliberate. > > > > > > > > > Attached IoTDB's Charter: > > > "RESOLVED, that the Apache IoTDB Project be and hereby is > > > responsible for the creation and maintenance of software > > > related to an IoT native database with high performance > > > for data management and analysis, on the edge and the cloud." > > > > > > > > > [1] https://github.com/apache/iotdb/pull/9534/checks > > > > > > Best, > > > ----------------------------------- > > > Xiangdong Huang > > > School of Software, Tsinghua University > > > -- Thanks, Xin
