subject:"\[discuss\] consider revert the feature of multi\-tenancy"

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

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

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

Re: [discuss] consider revert the feature of multi-tenancy

2023-04-12 Thread Chao Wang

on, 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  写道：

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 张金瑞<329920...@qq.com.INVALID> |
| Date | 04/12/2023 14:55 |
| To |  |
| 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  写道：

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 n

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 张金瑞<329920...@qq.com.INVALID> |
| Date | 04/12/2023 19:14 |
| To |  |
| 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  写道：

Hi，


Especially when exposing these concepts to users, we don't want to crea

Re: [discuss] consider revert the feature of multi-tenancy

2023-04-12 Thread Jinrui 张金瑞

uld 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 |
>  | 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

Re: [discuss] consider revert the feature of multi-tenancy

2023-04-12 Thread Chao Wang

. 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  写道：

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 张金瑞<329920...@qq.com.INVALID> |
| Date | 04/12/2023 14:55 |
| To |  |
| 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

Re: [discuss] consider revert the feature of multi-tenancy

Hi, Jinrui


> (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.

In our user manual, is it mentioned that different tenants can set different 
compaction parameters? Did it mention that different users can set different 
configurations?
We mentioned that disk, timeseries, devices, cpu and meory, etc. can be limited 
in different tenants.

Any function has a scope, does it make sense to discuss something beyond that 
scope? Why don't you say that different tenants can have different versions of 
iotdb? Can different tenants have different cpu chips? Can different users have 
different operating systems? I think the example you gave above is beyond the 
scope of the user manual we gave, and it doesn't make sense.




Thanks,
---
Houliang Qi
BONC, Ltd


 Replied Message 
| From | Jinrui 张金瑞<329920...@qq.com.INVALID> |
| Date | 04/12/2023 17:28 |
| To |  |
| Subject | Re: [discuss] consider revert the feature of multi-tenancy |
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

Re: [discuss] consider revert the feature of multi-tenancy

2023-04-12 Thread Jinrui 张金瑞

larities 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 张金瑞<329920...@qq.com.INVALID> |
> | Date | 04/12/2023 14:55 |
> | To |  |
> | 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  写道：
> 
> 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

Re: [discuss] consider revert the feature of multi-tenancy

2023-04-12 Thread Chao Wang

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  写道：

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
resourc

Re: [discuss] consider revert the feature of multi-tenancy

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 张金瑞<329920...@qq.com.INVALID> |
| Date | 04/12/2023 14:55 |
| To |  |
| 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  写道：

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

Re: [discuss] consider revert the feature of multi-tenancy

2023-04-12 Thread Jinrui 张金瑞

enancy"
> (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 |
>  | 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 per

Re: Re：Re: [discuss] consider revert the feature of multi-tenancy

2023-04-11 Thread Chao Wang

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,
 --

Re: [discuss] consider revert the feature of multi-tenancy

2023-04-11 Thread Jialin Qiao

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

Re: [discuss] consider revert the feature of multi-tenancy

2023-04-11 Thread Houliang Qi

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

2023-04-11 Thread Xiangdong Huang

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

Re: [discuss] consider revert the feature of multi-tenancy

2023-04-11 Thread Houliang Qi

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 thes

Re: [discuss] consider revert the feature of multi-tenancy

2023-04-11 Thread Xiangdong Huang

---
> 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
> [2] https://github.com/apache/iotdb/actions/runs/4625220921/jobs/8181102446
> [3] https://github.com/apache/iotdb/actions/runs/4531046594/jobs/7980725316
> [4] https://apache-iotdb.feishu.cn/docx/doxcnKOYKDmJ40FpVnVsPMd3nTg
> [5] https://lists.apache.org/thread/y6dqcm2o7qk0nbkllb61bp8cv6d3m1h7
>
>
>
>
>
> Thanks,
> ---
> Houliang Qi
> BONC, Ltd
>
>
>  Replied Message 
> | From | 张金瑞<329920...@qq.com.INVALID> |
> | 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"< saint...@gmail.com ;
>
> Date:2023/4/10 10:05
>
> To:"dev"< dev@iotdb.apache.org ;
>
> 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

Re: [discuss] consider revert the feature of multi-tenancy

2023-04-11 Thread Chao Wang

ing IoTDB's features to be more 
diverse.

[1] https://apache-iotdb.feishu.cn/docx/DbqCd8t3EoxlCFx1yYicd9N4n4s
[2] https://github.com/apache/iotdb/actions/runs/4625220921/jobs/8181102446
[3] https://github.com/apache/iotdb/actions/runs/4531046594/jobs/7980725316
[4] https://apache-iotdb.feishu.cn/docx/doxcnKOYKDmJ40FpVnVsPMd3nTg
[5] https://lists.apache.org/thread/y6dqcm2o7qk0nbkllb61bp8cv6d3m1h7





Thanks,
---
Houliang Qi
BONC, Ltd


 Replied Message 
| From | 张金瑞<329920...@qq.com.INVALID> |
| 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"< saint...@gmail.com ;

Date:2023/4/10 10:05

To:"dev"< dev@iotdb.apache.org ;

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

Re: [discuss] consider revert the feature of multi-tenancy

2023-04-11 Thread Xiangdong Huang

views.
>
> 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
> [2] https://github.com/apache/iotdb/actions/runs/4625220921/jobs/8181102446
> [3] https://github.com/apache/iotdb/actions/runs/4531046594/jobs/7980725316
> [4] https://apache-iotdb.feishu.cn/docx/doxcnKOYKDmJ40FpVnVsPMd3nTg
> [5] https://lists.apache.org/thread/y6dqcm2o7qk0nbkllb61bp8cv6d3m1h7
>
>
>
>
>
> Thanks,
> ---
> Houliang Qi
> BONC, Ltd
>
>
>  Replied Message 
> | From | 张金瑞<329920...@qq.com.INVALID> |
> | 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"< saint...@gmail.com ;
>
> Date:2023/4/10 10:05
>
> To:"dev"< dev@iotdb.apache.org ;
>
> 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

Re: Re：Re: [discuss] consider revert the feature of multi-tenancy

o 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"< saint...@gmail.com ;

Date:2023/4/11 12:27

To:"dev"< dev@iotdb.apache.org ;

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
 [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 | dev@iotdb.apache.org |
 | Cc | dev@iotdb.apache.org |
 | 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?

Re: [discuss] consider revert the feature of multi-tenancy

ulti-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
[2] https://github.com/apache/iotdb/actions/runs/4625220921/jobs/8181102446
[3] https://github.com/apache/iotdb/actions/runs/4531046594/jobs/7980725316
[4] https://apache-iotdb.feishu.cn/docx/doxcnKOYKDmJ40FpVnVsPMd3nTg
[5] https://lists.apache.org/thread/y6dqcm2o7qk0nbkllb61bp8cv6d3m1h7





Thanks,
---
Houliang Qi
BONC, Ltd


 Replied Message 
| From | 张金瑞<329920...@qq.com.INVALID> |
| 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"< saint...@gmail.com ;

Date:2023/4/10 10:05

To:"dev"< dev@iotdb.apache.org ;

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

Re：Re: [discuss] consider revert the feature of multi-tenancy

2023-04-10 Thread 张金瑞

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
> [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 | dev@iotdb.apache.org |
> | Cc | dev@iotdb.apache.org |
> | 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
> ccgow...@163.com
> 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)

Re: [discuss] consider revert the feature of multi-tenancy

=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
> [2] https://github.com/apache/iotdb/actions/runs/4625220921/jobs/8181102446
> [3] https://github.com/apache/iotdb/actions/runs/4531046594/jobs/7980725316
> [4] https://apache-iotdb.feishu.cn/docx/doxcnKOYKDmJ40FpVnVsPMd3nTg
> [5] https://lists.apache.org/thread/y6dqcm2o7qk0nbkllb61bp8cv6d3m1h7
>
>
>
>
>
> Thanks,
> ---
> Houliang Qi
> BONC, Ltd
>
>
>  Replied Message 
> | From | 张金瑞<329920...@qq.com.INVALID> |
> | 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"< saint...@gmail.com ;
>
> Date:2023/4/10 10:05
>
> To:"dev"< dev@iotdb.apache.org ;
>
> 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

Re: [discuss] consider revert the feature of multi-tenancy

2023-04-10 Thread Houliang Qi

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
[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 | dev@iotdb.apache.org |
| Cc | dev@iotdb.apache.org |
| 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
ccgow...@163.com
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

Re: [discuss] consider revert the feature of multi-tenancy

 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
[2] https://github.com/apache/iotdb/actions/runs/4625220921/jobs/8181102446
[3] https://github.com/apache/iotdb/actions/runs/4531046594/jobs/7980725316
[4] https://apache-iotdb.feishu.cn/docx/doxcnKOYKDmJ40FpVnVsPMd3nTg
[5] https://lists.apache.org/thread/y6dqcm2o7qk0nbkllb61bp8cv6d3m1h7





Thanks,
---
Houliang Qi
BONC, Ltd


 Replied Message 
| From | 张金瑞<329920...@qq.com.INVALID> |
| 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"< saint...@gmail.com ;

Date:2023/4/10 10:05

To:"dev"< dev@iotdb.apache.org ;

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

Re: [discuss] consider revert the feature of multi-tenancy

>  Multi tenant functionality is a basic capability in cloud native scenarios

This is the most important reason that I disapprove this feature...
"multi-tenancy" is deeply binded with "Cloud"..
When people heard of "multi-tenancy", the first impression is "ha,
this is a cloud native product"...

However, IoTDB's domain is IIoT, and Edge mode is one of its important
format. And that is why I claim the Charter.

Maybe "multi-tenancy" can be used by some company's IoTDB distribution
if the company provides Cloud service (like BNOC),
But for Apache IoTDB, we need to consider the side effect of not only
the technology but also the user reaction..

> (1) The function name should be resource-control on the storage group
> level, rather than multi-tenancy.

Jialin's opinion maybe a better choice.

Best,
---
Xiangdong Huang
School of Software, Tsinghua University

HW-Chao Wang <576749...@qq.com.invalid> 于2023年4月10日周一 23:43写道：
>
> hi all, Multi tenant functionality is a basic capability in cloud native 
> scenarios, and currently many open source databases have this capability, 
> such as clickhouse, hbase, doris, and so on. Therefore, I suggest integrating 
> this feature into the community. As for resource consumption, it can be 
> turned off at the edge through configuration. The side effects (performance 
> loss) that come with it require some testing to identify the problem.
>
>
>
>
> ---Original---
> From: "Chao Wang" Date: Mon, Apr 10, 2023 19:14 PM
> To: "dev@iotdb.apache.org" Cc: "dev@iotdb.apache.org" Subject: Re: [discuss] consider revert the feature of multi-tenancy
>
>
> 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
> [2] https://github.com/apache/iotdb/actions/runs/4625220921/jobs/8181102446
> [3] https://github.com/apache/iotdb/actions/runs/4531046594/jobs/7980725316
> [4] https://apache-iotdb.feishu.cn/docx/doxcnKOYKDmJ40FpVnVsPMd3nTg
> [5] https://lists.apache.org/thread/y6dqcm2o7qk0nbkllb61bp8cv6d3m1h7
>
>
>
>
>
> Thanks,
> ---
> Houliang Qi
> BONC, Ltd
>
>
>  Replied Message 
> | From | 张金瑞<329920...@qq.com.INVALID |
> | 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

Re: [discuss] consider revert the feature of multi-tenancy

> 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
> [2] https://github.com/apache/iotdb/actions/runs/4625220921/jobs/8181102446
> [3] https://github.com/apache/iotdb/actions/runs/4531046594/jobs/7980725316
> [4] https://apache-iotdb.feishu.cn/docx/doxcnKOYKDmJ40FpVnVsPMd3nTg
> [5] https://lists.apache.org/thread/y6dqcm2o7qk0nbkllb61bp8cv6d3m1h7
>
>
>
>
>
> Thanks,
> ---
> Houliang Qi
> BONC, Ltd
>
>
>  Replied Message

Re: [discuss] consider revert the feature of multi-tenancy

2023-04-10 Thread Jialin Qiao

Hi,

The following is my perspective.

(1) The function name should be resource-control on the storage group
level, rather than multi-tenancy.
(2) This PR does not bring many side effects as it is disabled by
default, so a revert is not a must.
(3) The code may need to be improved, but it's ok as long as we keep optimizing.

Thanks,
—
Jialin Qiao
Apache IoTDB PMC

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
> [2] https://github.com/apache/iotdb/actions/runs/4625220921/jobs/8181102446
> [3] https://github.com/apache/iotdb/actions/runs/4531046594/jobs/7980725316
> [4] https://apache-iotdb.feishu.cn/docx/doxcnKOYKDmJ40FpVnVsPMd3nTg
> [5] https://lists.apache.org/thread/y6dqcm2o7qk0nbkllb61bp8cv6d3m1h7
>
>
>
>
>
> Thanks,
> -----------
> Houliang Qi
> BONC, Ltd
>
>
>  Replied Message 
> | From | 张金瑞<329920...@qq.com.INVALID> |
> | 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"< saint...@gmail.com ;
>
> Date:2023/4/10 10:05
>
> To:"dev"< dev@iotdb.apache.org ;
>
> 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

Re: [discuss] consider revert the feature of multi-tenancy