Re: Re：Re: [discuss] consider revert the feature of multi-tenancy
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，张金瑞<329920...@qq.com.INVALID> 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 herehttps://en.wikipedia.org/wiki/Multitenancy. I think nomatter 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. MaybeI 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"< qiaojia...@apache.org ; Date:2023/4/11 21:47 To:"dev"< dev@iotdb.apache.org ; 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 |
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/ > [2] > 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 | dev@iotdb.apache.org | > | 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
Re: [discuss] consider revert the feature of multi-tenancy
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/ [2] 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 | dev@iotdb.apache.org | | 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
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/ > [2] > 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 | dev@iotdb.apache.org | > | 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
Re: [discuss] consider revert the feature of multi-tenancy
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/ [2] 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 | dev@iotdb.apache.org | | 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，张金瑞<329920...@qq.com.INVALID> 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
Re: [discuss] consider revert the feature of multi-tenancy
The topic of this discussion only focus on "multi-tenancy", rather than others. Technology term sometimes blind people's eyes and developers may lack this sensitivity. You can try to make a small survey: if a product provides multi-tenancy feature, do you think the product is a cloud native product or ? and do you think the product is lightweight? Though I do not endorse some features (e.g, timeseries limitation by other contributor you mentationed), but "I do not like" does not mean "it can not be merged". In the community, no body has the power. I only care and intervene features that may bring far-reaching influence (according to my knowledge and judegement). To put it more bluntly: resource-control is just a feature of IoTDB, but multi-tenancy is a key feature for IoTDB's product position. So, I do not intervene the former but I will keep eyes on the latter and do not give in to the term. "reverting PR" is my suggestion but not the only and final option. Jialin's suggestion is also acceptable from my side. Best --- Xiangdong Huang School of Software, Tsinghua University Chao Wang 于2023年4月11日周二 14:34写道： > > Hi, Xiangdong, > > > Thank you for your reminder, I think it's okay to correct the description, > but it's a bit rash to go directly to revert PR without seeing what PR did in > detail. I don't think any community participant wants that. > > > 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. > > > Thanks! > > > Chao Wang > BONC ltd > On 4/11/2023 14:04，Xiangdong Huang wrote： > Hi Chao, > > It is true that PMC should pay attention to the direction of the project, so > what direction does this function affect? Does it affect the edge side? What > are the effects of features that can be turned off? > > I have claimed my standpoint. > I reclaim it here once again and do not want to mention it further: > when people heard of "multi-tenancy", the first impression is "this > product is for the cloud", which is conflict with IoTDB's description. > > Best, > --- > Xiangdong Huang > School of Software, Tsinghua University > > Chao Wang 于2023年4月11日周二 13:19写道： > > I missed this PR. I also do not endorse this PR as I think setting > the limitation strategy is not what an open source project should > consider (It is desired only if the system will be unstable if we have > no such a limitation) > > > Why can't some restriction strategies be added to the open source system to > prevent a single user from affecting the operation of the overall system. At > present, mature open source systems have similar mechanisms, such as doris, > hbase, etc.? In addition, what does this mechanism have to do with whether > the system is open source or not? It itself is a function that a more mature > multi-user system should have. Isn't IoTDB a multi-user system? > > > > What we can do is avoid the case. But if something has conflict with the > project's position, we must do some action. > > > Does this function affect the positioning of IoTDB? IoTDB is only for the > edge side? Can't be deployed and used on the cloud side? > > > Different users have different requirements. But, the PMC need to keep awake > to know or make a CONSENSUS about where the project will go. > > > It is true that PMC should pay attention to the direction of the project, so > what direction does this function affect? Does it affect the edge side? What > are the effects of features that can be turned off? > > > > > Thanks! > > > Chao Wang > BONC ltd > On 4/11/2023 12:16，Xiangdong Huang wrote： > 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? > > I missed this PR. I also do not endorse this PR as I think setting > the limitation strategy is not what an open source project should > consider (It is desired only if the system will be unstable if we have > no such a limitation) > > 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. > > Discussing and notifying on the community is absolutely right. But it > does not mean we have to accept and do not change all the fact that > has happened. > What we can do is avoid the case. But if something has conflict with > the project's position, we must do some action. > > Another point is that the
Re: [discuss] consider revert the feature of multi-tenancy
Hi, Xiangdong, Thank you for your reminder, I think it's okay to correct the description, but it's a bit rash to go directly to revert PR without seeing what PR did in detail. I don't think any community participant wants that. 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. Thanks! Chao Wang BONC ltd On 4/11/2023 14:04，Xiangdong Huang wrote： Hi Chao, It is true that PMC should pay attention to the direction of the project, so what direction does this function affect? Does it affect the edge side? What are the effects of features that can be turned off? I have claimed my standpoint. I reclaim it here once again and do not want to mention it further: when people heard of "multi-tenancy", the first impression is "this product is for the cloud", which is conflict with IoTDB's description. Best, --- Xiangdong Huang School of Software, Tsinghua University Chao Wang 于2023年4月11日周二 13:19写道： I missed this PR. I also do not endorse this PR as I think setting the limitation strategy is not what an open source project should consider (It is desired only if the system will be unstable if we have no such a limitation) Why can't some restriction strategies be added to the open source system to prevent a single user from affecting the operation of the overall system. At present, mature open source systems have similar mechanisms, such as doris, hbase, etc.? In addition, what does this mechanism have to do with whether the system is open source or not? It itself is a function that a more mature multi-user system should have. Isn't IoTDB a multi-user system? What we can do is avoid the case. But if something has conflict with the project's position, we must do some action. Does this function affect the positioning of IoTDB? IoTDB is only for the edge side? Can't be deployed and used on the cloud side? Different users have different requirements. But, the PMC need to keep awake to know or make a CONSENSUS about where the project will go. It is true that PMC should pay attention to the direction of the project, so what direction does this function affect? Does it affect the edge side? What are the effects of features that can be turned off? Thanks! Chao Wang BONC ltd On 4/11/2023 12:16，Xiangdong Huang wrote： 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? I missed this PR. I also do not endorse this PR as I think setting the limitation strategy is not what an open source project should consider (It is desired only if the system will be unstable if we have no such a limitation) 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. Discussing and notifying on the community is absolutely right. But it does not mean we have to accept and do not change all the fact that has happened. What we can do is avoid the case. But if something has conflict with the project's position, we must do some action. 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. Different users have different requirements. But, the PMC need to keep awake to know or make a CONSENSUS about where the project will go. That is why I start this discussion though I know it will cause many complaint. Best, --- Xiangdong Huang School of Software, Tsinghua University Chao Wang 于2023年4月11日周二 09:16写道： 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
Re: [discuss] consider revert the feature of multi-tenancy
Hi Chao, > It is true that PMC should pay attention to the direction of the project, so > what direction does this function affect? Does it affect the edge side? What > are the effects of features that can be turned off? I have claimed my standpoint. I reclaim it here once again and do not want to mention it further: when people heard of "multi-tenancy", the first impression is "this product is for the cloud", which is conflict with IoTDB's description. Best, --- Xiangdong Huang School of Software, Tsinghua University Chao Wang 于2023年4月11日周二 13:19写道： > > > I missed this PR. I also do not endorse this PR as I think setting > > the limitation strategy is not what an open source project should > > consider (It is desired only if the system will be unstable if we have > > no such a limitation) > > > Why can't some restriction strategies be added to the open source system to > prevent a single user from affecting the operation of the overall system. At > present, mature open source systems have similar mechanisms, such as doris, > hbase, etc.? In addition, what does this mechanism have to do with whether > the system is open source or not? It itself is a function that a more mature > multi-user system should have. Isn't IoTDB a multi-user system? > > > > > What we can do is avoid the case. But if something has conflict with the > > project's position, we must do some action. > > > Does this function affect the positioning of IoTDB? IoTDB is only for the > edge side? Can't be deployed and used on the cloud side? > > > > Different users have different requirements. But, the PMC need to keep > > awake to know or make a CONSENSUS about where the project will go. > > > It is true that PMC should pay attention to the direction of the project, so > what direction does this function affect? Does it affect the edge side? What > are the effects of features that can be turned off? > > > > > Thanks! > > > Chao Wang > BONC ltd > On 4/11/2023 12:16，Xiangdong Huang wrote： > 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? > > I missed this PR. I also do not endorse this PR as I think setting > the limitation strategy is not what an open source project should > consider (It is desired only if the system will be unstable if we have > no such a limitation) > > 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. > > Discussing and notifying on the community is absolutely right. But it > does not mean we have to accept and do not change all the fact that > has happened. > What we can do is avoid the case. But if something has conflict with > the project's position, we must do some action. > > 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. > > Different users have different requirements. But, the PMC need to keep > awake to know or make a CONSENSUS about where the project will go. > That is why I start this discussion though I know it will cause many > complaint. > > Best, > --- > Xiangdong Huang > School of Software, Tsinghua University > > Chao Wang 于2023年4月11日周二 09:16写道： > > 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
