Re: [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 Replied Message | From | Houliang Qi | | Date | 04/12/2023 20:08 | | To | dev@iotdb.apache.org | | Subject | Re: [discuss] consider revert the feature of multi-tenancy | Hi, I would like to end by stating my point of view. And I don't want to say it a second time. First of all, I agree to change the name of this feature to resource control. The reason why I think that both multi-tenancy and resource-control are suitable for us is that what we are currently doing is to limit the functions of users or databases resources. @Jinrui 2. A true multi-tenant system should also have features such as per-tenant configurations, customized tenant roles and permissions, and clear separation of tenant data. @Jinrui 3. In our case, the lack of configuration file isolation in the current implementation means that different tenants may inadvertently affect each other's configurations, which goes against the core principle of multi-tenancy. The example I raised in last mail is also used to illustrate it rather than the function scope definition. But I disagree with Jinrui said above: You can refer to this paper [1]. This document summarizes multi-tenancy very well. First of all, it does not mean that multi-tenancy must have the ability to configure isolation. For this feature, we do share configuration, but our data is logically isolated and can limit some resources such as cpu, memory, timeseries, etc. This is also a way to realize multi-tenancy. Of course, each tenant can even use a different operating system, which is also a way to realize multi-tenancy. Please don't limit the way to realize multi-tenancy. There I would like to paste a passage from the paper as a conclusion: By sharing infrastructure, middleware, or application among tenants, multi-tenancy can be achieved In a multi-tenant architecture, a single instance of the software is deployed on the server functioning on the service provider infrastructure. It provides access to multiple tenants at the same time, as describe by Karataş et al. [KCD+17]. Abdul et al. [ABG+18]describe several multi-tenant data layer models, such as dedicated, isolated, shared, and hybrid. By sharing infrastructure, middleware, or application among tenants, multi-tenancy can be achieved. Figure 2.2 visualizes the multi-tenancy strategies described by Walraven et al. [WLJ14]. However, application-level multi-tenancy with a shared everything architecture can lead to cost reduction. Chong et al. [CCW06] have outlined several viable database patterns, primarily for Microsoft SQL Server, which supports application-level multi-tenancy. In a multi-tenant situation, they present three major strategies which are: distinct databases, shared databases with distinct schemes, and shared databases with shared schemes. [1] Enabling multi-tenant scalable IoT platforms. https://elib.uni-stuttgart.de/bitstream/11682/11024/1/Enabling%20multi-tenant%20scalable%20IoT%20platforms.pdf Thanks, --- Houliang Qi BONC, Ltd Replied Message | From | Jinrui 张金瑞<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
Re: [discuss] consider revert the feature of multi-tenancy
Hi， > In some cases, reverting the code might be the best option to prevent > further damage. I don't think the current PR needs revert. The bad case you mentioned, from your point of view, I can also understand. But revet the pr, the reasons mentioned before are not convincing, whether it is that the multi-tenant boundary is not clearly defined, or that the pipeline fails, or it is a bad case. You can continue to test each PR, try to find bad cases and initiate a discussion on whether revert is necessary. I think it is very good and very rigorous. Of course, if you just want to target this PR, I have no objection, but strictly speaking, I can’t accept any of the reasons given. If I have to say it, it’s probably to avoid unnecessary misunderstandings. I can accept the revised description. > Perhaps I need to emphasize again that regarding the multi-tenancy section > discussed, the following is my conclusion. I understand what you said, you think multi-tenancy is not equal to resource control, I understand, just like k8s is not equal to cloud native, docker is not equal to container. Strictly speaking, it is true. So does this have something to do with whether to revert this PR? Now two questions: 1. Definition of multi-tenancy 2. Is it necessary to revert this PR 1. For multi-tenant issues, I think it can be modified to resource control. 2. For revert pr, I don’t think revert is needed. The reason has been mentioned before. It supports basic functions, has minimal performance impact and is turned off by default. Speaking of this, I would like to know, have you tested this pr https://github.com/apache/iotdb/pull/9430 and analyzed whether it affects the impact of IoTDB, whether it has an impact on the edge side, whether it will affect Development of other functions. Or there are just more questions about pr raised by some SPECIFIC community contributors. In fact, I don't want to continue this topic for a long time. I think it should be over after Jialin made a suggestion. It just seems that some opinions seem to be aimed at community participants. For the healthy development of the community, I think it would be better to clarify. Regarding the topic of this pr, this is my last reply, all opinions are accepted, and I do not insist that there is no need to revert this pr. I personally feel that my contribution to the community is really not much, and I may not think comprehensively enough. It may be more suitable for learning more in the community, doing less and seeing more. Thanks! Chao Wang BONC ltd On 4/12/2023 19:14，Jinrui 张金瑞<329920...@qq.com.INVALID> wrote： 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 create any misunderstandings about the core functionality of IoTDB, which is also mentioned in Xiangdong's mail. That's why we need to be precise in our definitions and avoid interchangeable usage of terms that could lead to confusion. I agree that the term multi-tenancy is somewhat imprecise in a sense and can be modified to avoid unnecessary misunderstandings. But just like the multi-tenant form you defined, what will be affected? Based on resource isolation technology or resource control technology, what's wrong with
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 create any misunderstandings about the core functionality of IoTDB, which is also
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 create >> any misunderstandings about the core functionality of IoTDB, which is also >> mentioned in Xiangdong's mail. That's why we need to be precise in our >> definitions and avoid interchangeable usage of terms that could lead to >> confusion. > > > I agree that the term multi-tenancy is somewhat imprecise in a sense and can > be modified to avoid unnecessary misunderstandings. But just like the > multi-tenant form you defined, what will be affected? Based on resource > isolation technology or resource control technology, what's wrong with > providing services to multiple tenants and declaring that this is a > multi-tenant function (possibly weak)? > > > I think it is good for everyone to discuss the definition clearly. Before the > definition is clear, there is no need to question a bunch of questions first. > > >> However, based on my personal judgment and the current state of the code, I >> don't believe it's ready to be merged yet due to its significant missing >> functionality. > > > I have tested the code and the steps below are working. I think the basic > functions are done. > > > set space quota timeseries=3 on root.test > create timeseries root.test.wf01.wt01.status with > datatype=BOOLEAN,encoding=PLAIN > create timeseries root.test.wf01.wt01.status1 with > datatype=BOOLEAN,encoding=PLAIN > create timeseries root.test.wf01.wt01.status2 with > datatype=BOOLEAN,encoding=PLAIN > create timeseries root.test.wf01.wt01.status4 with > datatype=BOOLEAN,encoding=PLAIN > > > The fourth statement will report an error. > > > > > You think this pr function is missing, and I can understand it, after all, > you have found some bad cases. So next time if there are other PRs and I find > out the bad case, is it better to consider launching a discussion and > reverting it? > > > > > > > > > > > Thanks! > > > Chao Wang > BONC ltd > On 4/12/2023 17:28，Jinrui 张金瑞<329920...@qq.com.INVALID> wrote： > Hi, > > @Chao: Well, there is a difference between multi-tenancy and resource control > as you define. Sometimes in communication, a certain application form is > often used to refer to the core technology or representative technology, or > the core technology represents a certain application form. I think it is not > accurate, but it is acceptable. Just like when I say cloud native, I will > naturally think of k8s, and when it comes to containers, I will think of > docker. I think the core technology of multi-tenancy is resource control or > isolation, so it is also possible to mention multi-tenancy. Functions similar > to multi-tenancy can be realized based on the resource control function. > (Jinrui): I understand your point of view, but I still believe that there is > a difference between multi-tenancy and resource control. While it may be > acceptable to use a certain application form to refer to a core technology or > representative technology, I think it's important to be accurate in our > terminology, especially when it comes to technical discussions. In my > opinion, the core technology of multi-tenancy is about providing separate > environments for different
Re: [discuss] consider revert the feature of multi-tenancy
Hi， > Especially when exposing these concepts to users, we don't want to create any > misunderstandings about the core functionality of IoTDB, which is also > mentioned in Xiangdong's mail. That's why we need to be precise in our > definitions and avoid interchangeable usage of terms that could lead to > confusion. I agree that the term multi-tenancy is somewhat imprecise in a sense and can be modified to avoid unnecessary misunderstandings. But just like the multi-tenant form you defined, what will be affected? Based on resource isolation technology or resource control technology, what's wrong with providing services to multiple tenants and declaring that this is a multi-tenant function (possibly weak)? I think it is good for everyone to discuss the definition clearly. Before the definition is clear, there is no need to question a bunch of questions first. > However, based on my personal judgment and the current state of the code, I > don't believe it's ready to be merged yet due to its significant missing > functionality. I have tested the code and the steps below are working. I think the basic functions are done. set space quota timeseries=3 on root.test create timeseries root.test.wf01.wt01.status with datatype=BOOLEAN,encoding=PLAIN create timeseries root.test.wf01.wt01.status1 with datatype=BOOLEAN,encoding=PLAIN create timeseries root.test.wf01.wt01.status2 with datatype=BOOLEAN,encoding=PLAIN create timeseries root.test.wf01.wt01.status4 with datatype=BOOLEAN,encoding=PLAIN The fourth statement will report an error. You think this pr function is missing, and I can understand it, after all, you have found some bad cases. So next time if there are other PRs and I find out the bad case, is it better to consider launching a discussion and reverting it? Thanks! Chao Wang BONC ltd On 4/12/2023 17:28，Jinrui 张金瑞<329920...@qq.com.INVALID> wrote： Hi, @Chao: Well, there is a difference between multi-tenancy and resource control as you define. Sometimes in communication, a certain application form is often used to refer to the core technology or representative technology, or the core technology represents a certain application form. I think it is not accurate, but it is acceptable. Just like when I say cloud native, I will naturally think of k8s, and when it comes to containers, I will think of docker. I think the core technology of multi-tenancy is resource control or isolation, so it is also possible to mention multi-tenancy. Functions similar to multi-tenancy can be realized based on the resource control function. (Jinrui): I understand your point of view, but I still believe that there is a difference between multi-tenancy and resource control. While it may be acceptable to use a certain application form to refer to a core technology or representative technology, I think it's important to be accurate in our terminology, especially when it comes to technical discussions. In my opinion, the core technology of multi-tenancy is about providing separate environments for different tenants, while resource control or isolation is a means to achieve that. While functions similar to multi-tenancy can be realized based on the resource control function, I think it's important to distinguish between the two and use the appropriate term depending on the context. Especially when exposing these concepts to users, we don't want to create any misunderstandings about the core functionality of IoTDB, which is also mentioned in Xiangdong's mail. That's why we need to be precise in our definitions and avoid interchangeable usage of terms that could lead to confusion. @Chao: I think there is a problem with this code and it needs to be fixed. You can continue to submit the code to fix it. We don't need to revert and wait for the repair to be completed before submit it. What you emphasize is that it affects the stability of the code, so it's better to revert. I Agree with that. But I don’t see how a function that is turned off by default affects the stability and affects the user? Has it affected the development of other functions? Does it affect pipeline testing? Only bug-free code does not affect stability? As Houliang said, can someone be sure that their code has no bugs? (Jinrui): While it's true that no one can guarantee bug-free code, it's also important to ensure that the code meets the minimum requirements for functionality and stability. We don't want to risk introducing more issues to the system by merging incomplete or flawed code. I would like to clarify that the current issue with the code is not just about the presence of bugs, but also about the basic functionality that is missing. Furthermore, even if the function is turned off by default, it could still have an impact on the development of other functions. I understand that we may have different opinions on whether this code should be merged or not. If you think it's acceptable
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 be merged or not. If you think it's acceptable
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 be merged or not. If you think it's acceptable to merge the code, I respect your opinion and we can proceed accordingly. However, based on my personal judgment and the current state of the code, I don't believe it's ready to be merged yet due to its significant missing functionality. > @Houliang: Second: why can't we call it multi-tenant? We can achieve logical > isolation of data through this feature and auth permission, and we can also > manage and control users and database resources. Doesn't this just verify > what you said above? (Jinrui): Let's say there are two tenants in the system, Tenant A and Tenant B. In the current implementation, if Tenant A disables the compaction function, it will also be disabled for Tenant B. This means that Tenant B has no control over this feature and must accept the configuration set by Tenant A. This is not an ideal scenario for multi-tenancy, as each tenant should be able to configure their own settings independently without affecting other tenants. Additionally, if one user modifies the configuration of their IoTDB instance, it can potentially impact the experience of other users sharing the same resources. This is not desirable for multi-tenancy, as each tenant should be isolated from each other and their actions should not impact other tenants. Therefore, it's important to have proper multi-tenancy implementation to avoid these kinds of issues and ensure each tenant can operate independently without interfering with each other. Thanks, Zhang Jinrui > 2023年4月12日 下午4:08，Houliang Qi 写道： > > 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
Re: [discuss] consider revert the feature of multi-tenancy
Hi, > 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 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. > 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. 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? > I didn't fully understand what you meant, could you please explain it again? Oh, what I want to say is that the function of this pr, that is, the multi-tenant or resource control function is still under discussion whether it will affect the positioning of IoTDB, should it not be contributed to the community, and is it necessary for contributors to fix bugs? Thanks! Chao Wang BONC ltd ccgow...@163.com On 4/12/2023 14:55，Jinrui 张金瑞<329920...@qq.com.INVALID> wrote： 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.
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't run, I don't know if it's suitable for this scenario). Then according
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'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
