Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Hi Chiradeep, On 26-Nov-2014, at 4:32 am, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Instead of adding yet another parameter, could we look into adding a generic filter as in: http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeInstances.html But there already are so many parameters on the API, adding a filter param (map) will break semantics? May be we should do this for the next (restful) API layer we create? Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Good ideas, I’ll use them. So I think no one disagrees with this; - list VMs still has user_id, but deployVM won’t - We’ll use first user in the account if someone’s impersonating; else use logged in user to get user_id On 25-Nov-2014, at 12:17 am, Prachi Damle prachi.da...@citrix.com wrote: Hi Rohit, I see your point: when deploy VM is called by an admin impersonating another account, the user_id value will be set to logged in user, which will be the admin. And this will break your usecase. Correct? Do you think your functionality needs this usecase i.e an admin impersonating deployVm for another user? If you won't hit this scenario primarily, we can just set the user_id to first user in the account being impersonated to cover this case - just as your upgrade code for existing Vms. What do you think? Thanks, Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Friday, November 21, 2014 11:13 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Hi Min, Prachi, Thanks for your comments. I see your point, the use case is to list VMs for a user_id (uuid, not name). I'm going to add the arg/option the listVM api to accept user_id and return the list of VMs for that user, and add option in the UI to do the same. Note, this is not for auditing purposes (for that we have events). But, since we allow impersonation of account while deploying a VM by the same logic we should allow impersonation at the user_id as well which we only accept in the deploy VM API if an account/domain is mentioned along with the user_id. If I only use logged-in user ID, it makes implementation very simple but at the same time but sort of breaks impersonation semantics. Note: the fix will be simple, won't change IAM and this is just to add capability to list VMs for a user ID. On 21-Nov-2014, at 11:57 pm, Prachi Damle prachi.da...@citrix.com wrote: Hi Rohit, The accountId in deployVm API is serving the purpose of impersonation and can be passed typically by admin accounts to deploy VM on behalf of other User. So Ideally with IAM, this parameter should be removed from the API and impersonation should be handled separately. Keeping this goal, I think let's not add userID parameter in the API. We should default the value to the logged in user - this will prevent usecases around cross-account/cross-user scenarios. Thanks, Prachi -Original Message- From: Min Chen [mailto:min.c...@citrix.com] Sent: Friday, November 21, 2014 8:16 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount If I understood correctly, (account, domainId) passed into deployVMCmd is used for impersonation-like behavior, that is, caller is deploying a VM on behalf of an account. Personally I don't like this kind of putting so many parameters in one API to perform several different functionalities, impersonation should be done through IAM separately. Too many parameters will just make our API semantics very hard to understand and maintain. Along this line, I will not like to see this user_id added here. Thanks -min On 11/21/14 5:20 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Prachi, Since we¹re already allowing users to specific account and list VMs by account, following the same pattern I added the case so as to allow users to specify user_id in both list/deploy VM commands. In case the userid is not specified, in that case the logged in user¹s ID will be used. It¹s open for discussion of course, let me know if it¹s a good idea to follow the same pattern or strictly use the logged-in user¹s ID? On 21-Nov-2014, at 1:41 am, Prachi Damle prachi.da...@citrix.com wrote: Rohit, I checked the code here https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog; h= ref s/heads/useraccount-refactoring and I don't understand why we need to expose the userId parameter in the deployVm API. I think we should be using the userId of the logged in user always. Exposing the parameter at the API allows it to be set by a user to the ID of another user . Also we need validation around it to make sure it belongs to the passed account etc. +//Owner userId +@Parameter(name = ApiConstants.USER_ID, type = + CommandType.UUID, entityType = UserResponse.class, required = true, description = the user ID of the owner, optional to use with account and domainId. If not provided logged in user's ID is used.) +private Long userId; Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Sunday, November 16, 2014 6:06 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Only one table will be affected. On 16-Nov-2014, at 3:14 am, Amogh
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Instead of adding yet another parameter, could we look into adding a generic filter as in: http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeInstances.html From: Rohit Yadav rohit.ya...@shapeblue.commailto:rohit.ya...@shapeblue.com Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Tuesday, November 25, 2014 at 1:27 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Good ideas, I’ll use them. So I think no one disagrees with this; - list VMs still has user_id, but deployVM won’t - We’ll use first user in the account if someone’s impersonating; else use logged in user to get user_id On 25-Nov-2014, at 12:17 am, Prachi Damle prachi.da...@citrix.commailto:prachi.da...@citrix.com wrote: Hi Rohit, I see your point: when deploy VM is called by an admin impersonating another account, the user_id value will be set to logged in user, which will be the admin. And this will break your usecase. Correct? Do you think your functionality needs this usecase i.e an admin impersonating deployVm for another user? If you won't hit this scenario primarily, we can just set the user_id to first user in the account being impersonated to cover this case - just as your upgrade code for existing Vms. What do you think? Thanks, Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Friday, November 21, 2014 11:13 PM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Hi Min, Prachi, Thanks for your comments. I see your point, the use case is to list VMs for a user_id (uuid, not name). I'm going to add the arg/option the listVM api to accept user_id and return the list of VMs for that user, and add option in the UI to do the same. Note, this is not for auditing purposes (for that we have events). But, since we allow impersonation of account while deploying a VM by the same logic we should allow impersonation at the user_id as well which we only accept in the deploy VM API if an account/domain is mentioned along with the user_id. If I only use logged-in user ID, it makes implementation very simple but at the same time but sort of breaks impersonation semantics. Note: the fix will be simple, won't change IAM and this is just to add capability to list VMs for a user ID. On 21-Nov-2014, at 11:57 pm, Prachi Damle prachi.da...@citrix.commailto:prachi.da...@citrix.com wrote: Hi Rohit, The accountId in deployVm API is serving the purpose of impersonation and can be passed typically by admin accounts to deploy VM on behalf of other User. So Ideally with IAM, this parameter should be removed from the API and impersonation should be handled separately. Keeping this goal, I think let's not add userID parameter in the API. We should default the value to the logged in user - this will prevent usecases around cross-account/cross-user scenarios. Thanks, Prachi -Original Message- From: Min Chen [mailto:min.c...@citrix.com] Sent: Friday, November 21, 2014 8:16 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount If I understood correctly, (account, domainId) passed into deployVMCmd is used for impersonation-like behavior, that is, caller is deploying a VM on behalf of an account. Personally I don't like this kind of putting so many parameters in one API to perform several different functionalities, impersonation should be done through IAM separately. Too many parameters will just make our API semantics very hard to understand and maintain. Along this line, I will not like to see this user_id added here. Thanks -min On 11/21/14 5:20 AM, Rohit Yadav rohit.ya...@shapeblue.commailto:rohit.ya...@shapeblue.com wrote: Hi Prachi, Since we¹re already allowing users to specific account and list VMs by account, following the same pattern I added the case so as to allow users to specify user_id in both list/deploy VM commands. In case the userid is not specified, in that case the logged in user¹s ID will be used. It¹s open for discussion of course, let me know if it¹s a good idea to follow the same pattern or strictly use the logged-in user¹s ID? On 21-Nov-2014, at 1:41 am, Prachi Damle prachi.da...@citrix.commailto:prachi.da...@citrix.com wrote: Rohit, I checked the code here https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog; h= ref s/heads/useraccount-refactoring and I don't understand why we need to expose the userId parameter in the deployVm API. I think we should be using the userId of the logged in user always. Exposing the parameter at the API allows it to be set
RE: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Hi Rohit, I see your point: when deploy VM is called by an admin impersonating another account, the user_id value will be set to logged in user, which will be the admin. And this will break your usecase. Correct? Do you think your functionality needs this usecase i.e an admin impersonating deployVm for another user? If you won't hit this scenario primarily, we can just set the user_id to first user in the account being impersonated to cover this case - just as your upgrade code for existing Vms. What do you think? Thanks, Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Friday, November 21, 2014 11:13 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Hi Min, Prachi, Thanks for your comments. I see your point, the use case is to list VMs for a user_id (uuid, not name). I'm going to add the arg/option the listVM api to accept user_id and return the list of VMs for that user, and add option in the UI to do the same. Note, this is not for auditing purposes (for that we have events). But, since we allow impersonation of account while deploying a VM by the same logic we should allow impersonation at the user_id as well which we only accept in the deploy VM API if an account/domain is mentioned along with the user_id. If I only use logged-in user ID, it makes implementation very simple but at the same time but sort of breaks impersonation semantics. Note: the fix will be simple, won't change IAM and this is just to add capability to list VMs for a user ID. On 21-Nov-2014, at 11:57 pm, Prachi Damle prachi.da...@citrix.com wrote: Hi Rohit, The accountId in deployVm API is serving the purpose of impersonation and can be passed typically by admin accounts to deploy VM on behalf of other User. So Ideally with IAM, this parameter should be removed from the API and impersonation should be handled separately. Keeping this goal, I think let's not add userID parameter in the API. We should default the value to the logged in user - this will prevent usecases around cross-account/cross-user scenarios. Thanks, Prachi -Original Message- From: Min Chen [mailto:min.c...@citrix.com] Sent: Friday, November 21, 2014 8:16 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount If I understood correctly, (account, domainId) passed into deployVMCmd is used for impersonation-like behavior, that is, caller is deploying a VM on behalf of an account. Personally I don't like this kind of putting so many parameters in one API to perform several different functionalities, impersonation should be done through IAM separately. Too many parameters will just make our API semantics very hard to understand and maintain. Along this line, I will not like to see this user_id added here. Thanks -min On 11/21/14 5:20 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Prachi, Since we¹re already allowing users to specific account and list VMs by account, following the same pattern I added the case so as to allow users to specify user_id in both list/deploy VM commands. In case the userid is not specified, in that case the logged in user¹s ID will be used. It¹s open for discussion of course, let me know if it¹s a good idea to follow the same pattern or strictly use the logged-in user¹s ID? On 21-Nov-2014, at 1:41 am, Prachi Damle prachi.da...@citrix.com wrote: Rohit, I checked the code here https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog; h= ref s/heads/useraccount-refactoring and I don't understand why we need to expose the userId parameter in the deployVm API. I think we should be using the userId of the logged in user always. Exposing the parameter at the API allows it to be set by a user to the ID of another user . Also we need validation around it to make sure it belongs to the passed account etc. +//Owner userId +@Parameter(name = ApiConstants.USER_ID, type = + CommandType.UUID, entityType = UserResponse.class, required = true, description = the user ID of the owner, optional to use with account and domainId. If not provided logged in user's ID is used.) +private Long userId; Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Sunday, November 16, 2014 6:06 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Only one table will be affected. On 16-Nov-2014, at 3:14 am, Amogh Vasekar amogh.vase...@citrix.com wrote: Question - What happens to the already existing VMs with entries in the DB? Do we keep it NULL? NULL will be and not useful. I think it should be okay to have a db migration path that sets user_id to the first user in account_id (which usually has the same name
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Hi Prachi, Since we’re already allowing users to specific account and list VMs by account, following the same pattern I added the case so as to allow users to specify user_id in both list/deploy VM commands. In case the userid is not specified, in that case the logged in user’s ID will be used. It’s open for discussion of course, let me know if it’s a good idea to follow the same pattern or strictly use the logged-in user’s ID? On 21-Nov-2014, at 1:41 am, Prachi Damle prachi.da...@citrix.com wrote: Rohit, I checked the code here https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/useraccount-refactoring and I don't understand why we need to expose the userId parameter in the deployVm API. I think we should be using the userId of the logged in user always. Exposing the parameter at the API allows it to be set by a user to the ID of another user . Also we need validation around it to make sure it belongs to the passed account etc. +//Owner userId +@Parameter(name = ApiConstants.USER_ID, type = CommandType.UUID, entityType = UserResponse.class, required = true, description = the user ID of the owner, optional to use with account and domainId. If not provided logged in user's ID is used.) +private Long userId; Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Sunday, November 16, 2014 6:06 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Only one table will be affected. On 16-Nov-2014, at 3:14 am, Amogh Vasekar amogh.vase...@citrix.com wrote: Question - What happens to the already existing VMs with entries in the DB? Do we keep it NULL? NULL will be and not useful. I think it should be okay to have a db migration path that sets user_id to the first user in account_id (which usually has the same name as account) for existing VMs. The amount of code change will be minimal. Checkout some code in this branch (has the db migration code and API layer changes); https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/useraccount-refactoring Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge - rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
If I understood correctly, (account, domainId) passed into deployVMCmd is used for impersonation-like behavior, that is, caller is deploying a VM on behalf of an account. Personally I don't like this kind of putting so many parameters in one API to perform several different functionalities, impersonation should be done through IAM separately. Too many parameters will just make our API semantics very hard to understand and maintain. Along this line, I will not like to see this user_id added here. Thanks -min On 11/21/14 5:20 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Prachi, Since we¹re already allowing users to specific account and list VMs by account, following the same pattern I added the case so as to allow users to specify user_id in both list/deploy VM commands. In case the userid is not specified, in that case the logged in user¹s ID will be used. It¹s open for discussion of course, let me know if it¹s a good idea to follow the same pattern or strictly use the logged-in user¹s ID? On 21-Nov-2014, at 1:41 am, Prachi Damle prachi.da...@citrix.com wrote: Rohit, I checked the code here https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=ref s/heads/useraccount-refactoring and I don't understand why we need to expose the userId parameter in the deployVm API. I think we should be using the userId of the logged in user always. Exposing the parameter at the API allows it to be set by a user to the ID of another user . Also we need validation around it to make sure it belongs to the passed account etc. +//Owner userId +@Parameter(name = ApiConstants.USER_ID, type = CommandType.UUID, entityType = UserResponse.class, required = true, description = the user ID of the owner, optional to use with account and domainId. If not provided logged in user's ID is used.) +private Long userId; Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Sunday, November 16, 2014 6:06 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Only one table will be affected. On 16-Nov-2014, at 3:14 am, Amogh Vasekar amogh.vase...@citrix.com wrote: Question - What happens to the already existing VMs with entries in the DB? Do we keep it NULL? NULL will be and not useful. I think it should be okay to have a db migration path that sets user_id to the first user in account_id (which usually has the same name as account) for existing VMs. The amount of code change will be minimal. Checkout some code in this branch (has the db migration code and API layer changes); https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=ref s/heads/useraccount-refactoring Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge - rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com
RE: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Hi Rohit, The accountId in deployVm API is serving the purpose of impersonation and can be passed typically by admin accounts to deploy VM on behalf of other User. So Ideally with IAM, this parameter should be removed from the API and impersonation should be handled separately. Keeping this goal, I think let's not add userID parameter in the API. We should default the value to the logged in user - this will prevent usecases around cross-account/cross-user scenarios. Thanks, Prachi -Original Message- From: Min Chen [mailto:min.c...@citrix.com] Sent: Friday, November 21, 2014 8:16 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount If I understood correctly, (account, domainId) passed into deployVMCmd is used for impersonation-like behavior, that is, caller is deploying a VM on behalf of an account. Personally I don't like this kind of putting so many parameters in one API to perform several different functionalities, impersonation should be done through IAM separately. Too many parameters will just make our API semantics very hard to understand and maintain. Along this line, I will not like to see this user_id added here. Thanks -min On 11/21/14 5:20 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Prachi, Since we¹re already allowing users to specific account and list VMs by account, following the same pattern I added the case so as to allow users to specify user_id in both list/deploy VM commands. In case the userid is not specified, in that case the logged in user¹s ID will be used. It¹s open for discussion of course, let me know if it¹s a good idea to follow the same pattern or strictly use the logged-in user¹s ID? On 21-Nov-2014, at 1:41 am, Prachi Damle prachi.da...@citrix.com wrote: Rohit, I checked the code here https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h= ref s/heads/useraccount-refactoring and I don't understand why we need to expose the userId parameter in the deployVm API. I think we should be using the userId of the logged in user always. Exposing the parameter at the API allows it to be set by a user to the ID of another user . Also we need validation around it to make sure it belongs to the passed account etc. +//Owner userId +@Parameter(name = ApiConstants.USER_ID, type = CommandType.UUID, entityType = UserResponse.class, required = true, description = the user ID of the owner, optional to use with account and domainId. If not provided logged in user's ID is used.) +private Long userId; Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Sunday, November 16, 2014 6:06 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Only one table will be affected. On 16-Nov-2014, at 3:14 am, Amogh Vasekar amogh.vase...@citrix.com wrote: Question - What happens to the already existing VMs with entries in the DB? Do we keep it NULL? NULL will be and not useful. I think it should be okay to have a db migration path that sets user_id to the first user in account_id (which usually has the same name as account) for existing VMs. The amount of code change will be minimal. Checkout some code in this branch (has the db migration code and API layer changes); https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h= ref s/heads/useraccount-refactoring Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge - rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Hi Min, Prachi, Thanks for your comments. I see your point, the use case is to list VMs for a user_id (uuid, not name). I’m going to add the arg/option the listVM api to accept user_id and return the list of VMs for that user, and add option in the UI to do the same. Note, this is not for auditing purposes (for that we have events). But, since we allow impersonation of account while deploying a VM by the same logic we should allow impersonation at the user_id as well which we only accept in the deploy VM API if an account/domain is mentioned along with the user_id. If I only use logged-in user ID, it makes implementation very simple but at the same time but sort of breaks impersonation semantics. Note: the fix will be simple, won’t change IAM and this is just to add capability to list VMs for a user ID. On 21-Nov-2014, at 11:57 pm, Prachi Damle prachi.da...@citrix.com wrote: Hi Rohit, The accountId in deployVm API is serving the purpose of impersonation and can be passed typically by admin accounts to deploy VM on behalf of other User. So Ideally with IAM, this parameter should be removed from the API and impersonation should be handled separately. Keeping this goal, I think let's not add userID parameter in the API. We should default the value to the logged in user - this will prevent usecases around cross-account/cross-user scenarios. Thanks, Prachi -Original Message- From: Min Chen [mailto:min.c...@citrix.com] Sent: Friday, November 21, 2014 8:16 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount If I understood correctly, (account, domainId) passed into deployVMCmd is used for impersonation-like behavior, that is, caller is deploying a VM on behalf of an account. Personally I don't like this kind of putting so many parameters in one API to perform several different functionalities, impersonation should be done through IAM separately. Too many parameters will just make our API semantics very hard to understand and maintain. Along this line, I will not like to see this user_id added here. Thanks -min On 11/21/14 5:20 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Prachi, Since we¹re already allowing users to specific account and list VMs by account, following the same pattern I added the case so as to allow users to specify user_id in both list/deploy VM commands. In case the userid is not specified, in that case the logged in user¹s ID will be used. It¹s open for discussion of course, let me know if it¹s a good idea to follow the same pattern or strictly use the logged-in user¹s ID? On 21-Nov-2014, at 1:41 am, Prachi Damle prachi.da...@citrix.com wrote: Rohit, I checked the code here https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h= ref s/heads/useraccount-refactoring and I don't understand why we need to expose the userId parameter in the deployVm API. I think we should be using the userId of the logged in user always. Exposing the parameter at the API allows it to be set by a user to the ID of another user . Also we need validation around it to make sure it belongs to the passed account etc. +//Owner userId +@Parameter(name = ApiConstants.USER_ID, type = CommandType.UUID, entityType = UserResponse.class, required = true, description = the user ID of the owner, optional to use with account and domainId. If not provided logged in user's ID is used.) +private Long userId; Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Sunday, November 16, 2014 6:06 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Only one table will be affected. On 16-Nov-2014, at 3:14 am, Amogh Vasekar amogh.vase...@citrix.com wrote: Question - What happens to the already existing VMs with entries in the DB? Do we keep it NULL? NULL will be and not useful. I think it should be okay to have a db migration path that sets user_id to the first user in account_id (which usually has the same name as account) for existing VMs. The amount of code change will be minimal. Checkout some code in this branch (has the db migration code and API layer changes); https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h= ref s/heads/useraccount-refactoring Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge - rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack
RE: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Rohit, I checked the code here https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/useraccount-refactoring and I don't understand why we need to expose the userId parameter in the deployVm API. I think we should be using the userId of the logged in user always. Exposing the parameter at the API allows it to be set by a user to the ID of another user . Also we need validation around it to make sure it belongs to the passed account etc. +//Owner userId +@Parameter(name = ApiConstants.USER_ID, type = CommandType.UUID, entityType = UserResponse.class, required = true, description = the user ID of the owner, optional to use with account and domainId. If not provided logged in user's ID is used.) +private Long userId; Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Sunday, November 16, 2014 6:06 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Only one table will be affected. On 16-Nov-2014, at 3:14 am, Amogh Vasekar amogh.vase...@citrix.com wrote: Question - What happens to the already existing VMs with entries in the DB? Do we keep it NULL? NULL will be and not useful. I think it should be okay to have a db migration path that sets user_id to the first user in account_id (which usually has the same name as account) for existing VMs. The amount of code change will be minimal. Checkout some code in this branch (has the db migration code and API layer changes); https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/useraccount-refactoring Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge - rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Only one table will be affected. On 16-Nov-2014, at 3:14 am, Amogh Vasekar amogh.vase...@citrix.com wrote: Question - What happens to the already existing VMs with entries in the DB? Do we keep it NULL? NULL will be and not useful. I think it should be okay to have a db migration path that sets user_id to the first user in account_id (which usually has the same name as account) for existing VMs. The amount of code change will be minimal. Checkout some code in this branch (has the db migration code and API layer changes); https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/useraccount-refactoring Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
I agree with Nitin. It will be cleaner to use the events table. Since cloudstack is concerned only about account, it makes sense to have only that information which is the owner field(and remove account_id, domain_id). I think, there is no auto purging or archival of events. Its the operator who decides to delete the events. He can decide what he wants to retain/delete. If the resource id is added to events table, even for the sysadmin it would be a simple join to get the required information. ~Rajani On Sat, Nov 15, 2014 at 12:41 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Good discussion everyone. Nitin, I thought of using that as well but there are some issues using events; - events can be deleted - if some sysadmin is working with the db/tables, he would appreciate if all the information are with the resource (for VMs, the vm_instance table) Prachi, thanks I think I’ll go with just adding the column and make additions in the API/UI. I understand the ownership of the VM/resource will still be with the account, the purpose is mostly to support API query such as listing VMs of a userid etc. On 15-Nov-2014, at 2:52 am, Nitin Mehta nitin.me...@citrix.com wrote: Mike - we already do that in the action events (event table) ? We log the user_id as well and so we always would know the user responsible for an action One thing better we can do there is have a resource_id column in the table since the resource_id is currently embedded in the description at the moment. So instead of adding user_id for each resource we should do the change in the event table. Since all we want is a log of the actions. Thanks, -Nitin On 14/11/14 11:19 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Yeah, I think the idea is not to change ownership of the resource but to be better able to 'assign blame' for action x or y. On Fri, Nov 14, 2014 at 12:17 PM, Prachi Damle prachi.da...@citrix.com wrote: Rohit, Just on note on: Min, you’re right I don’t propose to change the IAM model just some additional data that notes who *actually* owns the resource (VM, volume, etc.) in an account which can be useful for sysadmins to list resource by userid etc. Adding 'user_id' column but not changing IAM model should be a small change and not causing any IAM side effects. But, it still won't really mean that that 'userid' 'owns' the resource. The ownership will still stay with the account - and so all other users in that account will still be able to access that resource, as per CS IAM. The userid will just provide an insight on which user in the account created the resource. Thanks, Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Friday, November 14, 2014 11:04 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Min, you’re right I don’t propose to change the IAM model just some additional data that notes who *actually* owns the resource (VM, volume, etc.) in an account which can be useful for sysadmins to list resource by userid etc. I can understand the hesitation and the side effects such a refactoring can produce, so I think the best would be to add user_id (uuid) columns and change only the API/query layer. Mike: I don’t propose to use user name but uuids so they are unique. My concern was adding user_id column to say vm_instance table denormalizes data as that table already has domain_id and account_id in it and as Rajani suggested earlier those two are not needed as using user_id one can find account_id and domain_id. I guess, the easiest way would be to just add an additional user_id column. Cheers. On 15-Nov-2014, at 12:14 am, Min Chen min.c...@citrix.com wrote: Rohit, If I understood you correctly, the user_id column is only used for listing resources to indicate which user is the real owner/creator of the resource, but you don't want to change CloudStack account-level permission model to user-level permission model, right? If so, the change will be smaller, maybe some Response classes, which should not involve too many business layer change. I will hesitate to really change CloudStack IAM model though. Thanks -min On 11/14/14 10:35 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Hi, On 15-Nov-2014, at 2:27 pm, Rajani Karuturi raj...@apache.org wrote: I agree with Nitin. It will be cleaner to use the events table. Since cloudstack is concerned only about account, it makes sense to have only that information which is the owner field(and remove account_id, domain_id). I think, there is no auto purging or archival of events. Its the operator who decides to delete the events. He can decide what he wants to retain/delete. I don’t think it’s a pragmatic solution, let me explain — In the past few months, apart from ACS development I’ve been heavily involved in working and supporting large production grade clouds and my ops experience is that there are usually couple of sysadmins (usually working in shifts) and we cannot really rely on the assumption that events are only cleared by one operator or that there is culture of knowledge sharing of all the actions. If one of the sysadmins (during their shift) removes some events, others won’t know. The events feature is perhaps good for event-driven consumption such as via AMQP/RabbitMQ and automated monitoring systems but perhaps not best suited for humans all the time (yet). The other use case is of a large org who are consumer of a (rented) CloudStack cloud among other tenants, the whole team of an org shares the account but has various users in it. For them it can be useful to list vms and other resources by userid within their account. Since, they may not be admin (renting cloud?) the pragmatic solution would be to have such metadata somewhere easily slice-able and dice-able using APIs. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Any idea on how many tables would be impacted by a decision for us to add the user ID directly into the tables (as opposed to relying on events)? Since we already have a domain_id and an account_id in certain tables, it might be better from a consistency standpoint to just add user_id to those tables, as well (I know it is a bit de-normalized that way, but we already have that situation with having both domain_id and account_id in these tables). On Sat, Nov 15, 2014 at 3:28 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, On 15-Nov-2014, at 2:27 pm, Rajani Karuturi raj...@apache.org wrote: I agree with Nitin. It will be cleaner to use the events table. Since cloudstack is concerned only about account, it makes sense to have only that information which is the owner field(and remove account_id, domain_id). I think, there is no auto purging or archival of events. Its the operator who decides to delete the events. He can decide what he wants to retain/delete. I don’t think it’s a pragmatic solution, let me explain — In the past few months, apart from ACS development I’ve been heavily involved in working and supporting large production grade clouds and my ops experience is that there are usually couple of sysadmins (usually working in shifts) and we cannot really rely on the assumption that events are only cleared by one operator or that there is culture of knowledge sharing of all the actions. If one of the sysadmins (during their shift) removes some events, others won’t know. The events feature is perhaps good for event-driven consumption such as via AMQP/RabbitMQ and automated monitoring systems but perhaps not best suited for humans all the time (yet). The other use case is of a large org who are consumer of a (rented) CloudStack cloud among other tenants, the whole team of an org shares the account but has various users in it. For them it can be useful to list vms and other resources by userid within their account. Since, they may not be admin (renting cloud?) the pragmatic solution would be to have such metadata somewhere easily slice-able and dice-able using APIs. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Build http://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineering http://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Support http://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courses http://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Question - What happens to the already existing VMs with entries in the DB? Do we keep it NULL? Amogh On 11/15/14 8:41 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Any idea on how many tables would be impacted by a decision for us to add the user ID directly into the tables (as opposed to relying on events)? Since we already have a domain_id and an account_id in certain tables, it might be better from a consistency standpoint to just add user_id to those tables, as well (I know it is a bit de-normalized that way, but we already have that situation with having both domain_id and account_id in these tables). On Sat, Nov 15, 2014 at 3:28 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, On 15-Nov-2014, at 2:27 pm, Rajani Karuturi raj...@apache.org wrote: I agree with Nitin. It will be cleaner to use the events table. Since cloudstack is concerned only about account, it makes sense to have only that information which is the owner field(and remove account_id, domain_id). I think, there is no auto purging or archival of events. Its the operator who decides to delete the events. He can decide what he wants to retain/delete. I don¹t think it¹s a pragmatic solution, let me explain ‹ In the past few months, apart from ACS development I¹ve been heavily involved in working and supporting large production grade clouds and my ops experience is that there are usually couple of sysadmins (usually working in shifts) and we cannot really rely on the assumption that events are only cleared by one operator or that there is culture of knowledge sharing of all the actions. If one of the sysadmins (during their shift) removes some events, others won¹t know. The events feature is perhaps good for event-driven consumption such as via AMQP/RabbitMQ and automated monitoring systems but perhaps not best suited for humans all the time (yet). The other use case is of a large org who are consumer of a (rented) CloudStack cloud among other tenants, the whole team of an org shares the account but has various users in it. For them it can be useful to list vms and other resources by userid within their account. Since, they may not be admin (renting cloud?) the pragmatic solution would be to have such metadata somewhere easily slice-able and dice-able using APIs. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Build http://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineering http://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Support http://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courses http://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*�*
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
I would say, 'yes.' On Saturday, November 15, 2014, Amogh Vasekar amogh.vase...@citrix.com wrote: Question - What happens to the already existing VMs with entries in the DB? Do we keep it NULL? Amogh On 11/15/14 8:41 AM, Mike Tutkowski mike.tutkow...@solidfire.com javascript:; wrote: Any idea on how many tables would be impacted by a decision for us to add the user ID directly into the tables (as opposed to relying on events)? Since we already have a domain_id and an account_id in certain tables, it might be better from a consistency standpoint to just add user_id to those tables, as well (I know it is a bit de-normalized that way, but we already have that situation with having both domain_id and account_id in these tables). On Sat, Nov 15, 2014 at 3:28 AM, Rohit Yadav rohit.ya...@shapeblue.com javascript:; wrote: Hi, On 15-Nov-2014, at 2:27 pm, Rajani Karuturi raj...@apache.org javascript:; wrote: I agree with Nitin. It will be cleaner to use the events table. Since cloudstack is concerned only about account, it makes sense to have only that information which is the owner field(and remove account_id, domain_id). I think, there is no auto purging or archival of events. Its the operator who decides to delete the events. He can decide what he wants to retain/delete. I don¹t think it¹s a pragmatic solution, let me explain ‹ In the past few months, apart from ACS development I¹ve been heavily involved in working and supporting large production grade clouds and my ops experience is that there are usually couple of sysadmins (usually working in shifts) and we cannot really rely on the assumption that events are only cleared by one operator or that there is culture of knowledge sharing of all the actions. If one of the sysadmins (during their shift) removes some events, others won¹t know. The events feature is perhaps good for event-driven consumption such as via AMQP/RabbitMQ and automated monitoring systems but perhaps not best suited for humans all the time (yet). The other use case is of a large org who are consumer of a (rented) CloudStack cloud among other tenants, the whole team of an org shares the account but has various users in it. For them it can be useful to list vms and other resources by userid within their account. Since, they may not be admin (renting cloud?) the pragmatic solution would be to have such metadata somewhere easily slice-able and dice-able using APIs. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com javascript:; Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Build http://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineering http://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Support http://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courses http://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com javascript:; o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play* * -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
[DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it’s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Agreed. Using userid could make isolation of resources more strictly. Which is more suitable for public cloud,but more work have to be done I think. On Nov 14, 2014 4:54 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it’s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Build http://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineering http://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Support http://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courses http://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd.
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Can a username like mike be re-used in multiple accounts? For example: Acct1\mike Acct2\mike If so, the name mike would be insufficient to determine ownership of the resource in some situations (unless it was fully qualified with its account). On Fri, Nov 14, 2014 at 11:35 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Build http://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineering http://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Support http://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courses http://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Rohit, If I understood you correctly, the user_id column is only used for listing resources to indicate which user is the real owner/creator of the resource, but you don't want to change CloudStack account-level permission model to user-level permission model, right? If so, the change will be smaller, maybe some Response classes, which should not involve too many business layer change. I will hesitate to really change CloudStack IAM model though. Thanks -min On 11/14/14 10:35 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies.
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
I haven't looked at the DB tables for this, but presumably there is a user table like we have an account table and you can figure out what account a given user is in? That would be OK then. I just wasn't sure if we only allowed you to go from account to user, but not user to account in the DB. On Fri, Nov 14, 2014 at 11:39 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Can a username like mike be re-used in multiple accounts? For example: Acct1\mike Acct2\mike If so, the name mike would be insufficient to determine ownership of the resource in some situations (unless it was fully qualified with its account). On Fri, Nov 14, 2014 at 11:35 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment framework http://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Build http://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineering http://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Support http://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courses
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
I didn't have access to the VM with my CS DB on it for a while, but I do now and checked the DB structure. I see the user table has a reference to the account table, so that's what I was expecting and hoped to see. On Fri, Nov 14, 2014 at 11:48 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: I haven't looked at the DB tables for this, but presumably there is a user table like we have an account table and you can figure out what account a given user is in? That would be OK then. I just wasn't sure if we only allowed you to go from account to user, but not user to account in the DB. On Fri, Nov 14, 2014 at 11:39 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Can a username like mike be re-used in multiple accounts? For example: Acct1\mike Acct2\mike If so, the name mike would be insufficient to determine ownership of the resource in some situations (unless it was fully qualified with its account). On Fri, Nov 14, 2014 at 11:35 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment framework http://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Build http://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
As for Min's question, I think Rohit is talking about keeping the account-ownership model the same in CloudStack, but just providing greater insight into what user specifically created or did whatever to a given resource. On Fri, Nov 14, 2014 at 11:59 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: I didn't have access to the VM with my CS DB on it for a while, but I do now and checked the DB structure. I see the user table has a reference to the account table, so that's what I was expecting and hoped to see. On Fri, Nov 14, 2014 at 11:48 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: I haven't looked at the DB tables for this, but presumably there is a user table like we have an account table and you can figure out what account a given user is in? That would be OK then. I just wasn't sure if we only allowed you to go from account to user, but not user to account in the DB. On Fri, Nov 14, 2014 at 11:39 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Can a username like mike be re-used in multiple accounts? For example: Acct1\mike Acct2\mike If so, the name mike would be insufficient to determine ownership of the resource in some situations (unless it was fully qualified with its account). On Fri, Nov 14, 2014 at 11:35 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment framework http://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. Regards, Rohit Yadav Software Architect,
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Yes, we support going both directions, account - user. Thanks -min On 11/14/14 10:59 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: I didn't have access to the VM with my CS DB on it for a while, but I do now and checked the DB structure. I see the user table has a reference to the account table, so that's what I was expecting and hoped to see. On Fri, Nov 14, 2014 at 11:48 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: I haven't looked at the DB tables for this, but presumably there is a user table like we have an account table and you can figure out what account a given user is in? That would be OK then. I just wasn't sure if we only allowed you to go from account to user, but not user to account in the DB. On Fri, Nov 14, 2014 at 11:39 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Can a username like mike be re-used in multiple accounts? For example: Acct1\mike Acct2\mike If so, the name mike would be insufficient to determine ownership of the resource in some situations (unless it was fully qualified with its account). On Fri, Nov 14, 2014 at 11:35 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment framework http://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Min, you’re right I don’t propose to change the IAM model just some additional data that notes who *actually* owns the resource (VM, volume, etc.) in an account which can be useful for sysadmins to list resource by userid etc. I can understand the hesitation and the side effects such a refactoring can produce, so I think the best would be to add user_id (uuid) columns and change only the API/query layer. Mike: I don’t propose to use user name but uuids so they are unique. My concern was adding user_id column to say vm_instance table denormalizes data as that table already has domain_id and account_id in it and as Rajani suggested earlier those two are not needed as using user_id one can find account_id and domain_id. I guess, the easiest way would be to just add an additional user_id column. Cheers. On 15-Nov-2014, at 12:14 am, Min Chen min.c...@citrix.com wrote: Rohit, If I understood you correctly, the user_id column is only used for listing resources to indicate which user is the real owner/creator of the resource, but you don't want to change CloudStack account-level permission model to user-level permission model, right? If so, the change will be smaller, maybe some Response classes, which should not involve too many business layer change. I will hesitate to really change CloudStack IAM model though. Thanks -min On 11/14/14 10:35 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. Regards, Rohit Yadav Software Architect,
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Yeah, I assume you would use the column ID of the user table (as opposed to the UUID of the given user), right? On Fri, Nov 14, 2014 at 12:04 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Min, you’re right I don’t propose to change the IAM model just some additional data that notes who *actually* owns the resource (VM, volume, etc.) in an account which can be useful for sysadmins to list resource by userid etc. I can understand the hesitation and the side effects such a refactoring can produce, so I think the best would be to add user_id (uuid) columns and change only the API/query layer. Mike: I don’t propose to use user name but uuids so they are unique. My concern was adding user_id column to say vm_instance table denormalizes data as that table already has domain_id and account_id in it and as Rajani suggested earlier those two are not needed as using user_id one can find account_id and domain_id. I guess, the easiest way would be to just add an additional user_id column. Cheers. On 15-Nov-2014, at 12:14 am, Min Chen min.c...@citrix.com wrote: Rohit, If I understood you correctly, the user_id column is only used for listing resources to indicate which user is the real owner/creator of the resource, but you don't want to change CloudStack account-level permission model to user-level permission model, right? If so, the change will be smaller, maybe some Response classes, which should not involve too many business layer change. I will hesitate to really change CloudStack IAM model though. Thanks -min On 11/14/14 10:35 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Also, yeah, it's a bit odd having domain_id, account_id, and user_id since having user_id would allow you to retrieve the other information, but that might be the easiest way to implement this (and we were already semi-denormalized having both domain_id and account_id in these tables). On Fri, Nov 14, 2014 at 12:08 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Yeah, I assume you would use the column ID of the user table (as opposed to the UUID of the given user), right? On Fri, Nov 14, 2014 at 12:04 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Min, you’re right I don’t propose to change the IAM model just some additional data that notes who *actually* owns the resource (VM, volume, etc.) in an account which can be useful for sysadmins to list resource by userid etc. I can understand the hesitation and the side effects such a refactoring can produce, so I think the best would be to add user_id (uuid) columns and change only the API/query layer. Mike: I don’t propose to use user name but uuids so they are unique. My concern was adding user_id column to say vm_instance table denormalizes data as that table already has domain_id and account_id in it and as Rajani suggested earlier those two are not needed as using user_id one can find account_id and domain_id. I guess, the easiest way would be to just add an additional user_id column. Cheers. On 15-Nov-2014, at 12:14 am, Min Chen min.c...@citrix.com wrote: Rohit, If I understood you correctly, the user_id column is only used for listing resources to indicate which user is the real owner/creator of the resource, but you don't want to change CloudStack account-level permission model to user-level permission model, right? If so, the change will be smaller, maybe some Response classes, which should not involve too many business layer change. I will hesitate to really change CloudStack IAM model though. Thanks -min On 11/14/14 10:35 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must
RE: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Rohit, Just on note on: Min, you’re right I don’t propose to change the IAM model just some additional data that notes who *actually* owns the resource (VM, volume, etc.) in an account which can be useful for sysadmins to list resource by userid etc. Adding 'user_id' column but not changing IAM model should be a small change and not causing any IAM side effects. But, it still won't really mean that that 'userid' 'owns' the resource. The ownership will still stay with the account - and so all other users in that account will still be able to access that resource, as per CS IAM. The userid will just provide an insight on which user in the account created the resource. Thanks, Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Friday, November 14, 2014 11:04 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Min, you’re right I don’t propose to change the IAM model just some additional data that notes who *actually* owns the resource (VM, volume, etc.) in an account which can be useful for sysadmins to list resource by userid etc. I can understand the hesitation and the side effects such a refactoring can produce, so I think the best would be to add user_id (uuid) columns and change only the API/query layer. Mike: I don’t propose to use user name but uuids so they are unique. My concern was adding user_id column to say vm_instance table denormalizes data as that table already has domain_id and account_id in it and as Rajani suggested earlier those two are not needed as using user_id one can find account_id and domain_id. I guess, the easiest way would be to just add an additional user_id column. Cheers. On 15-Nov-2014, at 12:14 am, Min Chen min.c...@citrix.com wrote: Rohit, If I understood you correctly, the user_id column is only used for listing resources to indicate which user is the real owner/creator of the resource, but you don't want to change CloudStack account-level permission model to user-level permission model, right? If so, the change will be smaller, maybe some Response classes, which should not involve too many business layer change. I will hesitate to really change CloudStack IAM model though. Thanks -min On 11/14/14 10:35 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Yeah, I think the idea is not to change ownership of the resource but to be better able to 'assign blame' for action x or y. On Fri, Nov 14, 2014 at 12:17 PM, Prachi Damle prachi.da...@citrix.com wrote: Rohit, Just on note on: Min, you’re right I don’t propose to change the IAM model just some additional data that notes who *actually* owns the resource (VM, volume, etc.) in an account which can be useful for sysadmins to list resource by userid etc. Adding 'user_id' column but not changing IAM model should be a small change and not causing any IAM side effects. But, it still won't really mean that that 'userid' 'owns' the resource. The ownership will still stay with the account - and so all other users in that account will still be able to access that resource, as per CS IAM. The userid will just provide an insight on which user in the account created the resource. Thanks, Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Friday, November 14, 2014 11:04 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Min, you’re right I don’t propose to change the IAM model just some additional data that notes who *actually* owns the resource (VM, volume, etc.) in an account which can be useful for sysadmins to list resource by userid etc. I can understand the hesitation and the side effects such a refactoring can produce, so I think the best would be to add user_id (uuid) columns and change only the API/query layer. Mike: I don’t propose to use user name but uuids so they are unique. My concern was adding user_id column to say vm_instance table denormalizes data as that table already has domain_id and account_id in it and as Rajani suggested earlier those two are not needed as using user_id one can find account_id and domain_id. I guess, the easiest way would be to just add an additional user_id column. Cheers. On 15-Nov-2014, at 12:14 am, Min Chen min.c...@citrix.com wrote: Rohit, If I understood you correctly, the user_id column is only used for listing resources to indicate which user is the real owner/creator of the resource, but you don't want to change CloudStack account-level permission model to user-level permission model, right? If so, the change will be smaller, maybe some Response classes, which should not involve too many business layer change. I will hesitate to really change CloudStack IAM model though. Thanks -min On 11/14/14 10:35 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7908 Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Mike - we already do that in the action events (event table) ? We log the user_id as well and so we always would know the user responsible for an action One thing better we can do there is have a resource_id column in the table since the resource_id is currently embedded in the description at the moment. So instead of adding user_id for each resource we should do the change in the event table. Since all we want is a log of the actions. Thanks, -Nitin On 14/11/14 11:19 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Yeah, I think the idea is not to change ownership of the resource but to be better able to 'assign blame' for action x or y. On Fri, Nov 14, 2014 at 12:17 PM, Prachi Damle prachi.da...@citrix.com wrote: Rohit, Just on note on: Min, you’re right I don’t propose to change the IAM model just some additional data that notes who *actually* owns the resource (VM, volume, etc.) in an account which can be useful for sysadmins to list resource by userid etc. Adding 'user_id' column but not changing IAM model should be a small change and not causing any IAM side effects. But, it still won't really mean that that 'userid' 'owns' the resource. The ownership will still stay with the account - and so all other users in that account will still be able to access that resource, as per CS IAM. The userid will just provide an insight on which user in the account created the resource. Thanks, Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Friday, November 14, 2014 11:04 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Min, you’re right I don’t propose to change the IAM model just some additional data that notes who *actually* owns the resource (VM, volume, etc.) in an account which can be useful for sysadmins to list resource by userid etc. I can understand the hesitation and the side effects such a refactoring can produce, so I think the best would be to add user_id (uuid) columns and change only the API/query layer. Mike: I don’t propose to use user name but uuids so they are unique. My concern was adding user_id column to say vm_instance table denormalizes data as that table already has domain_id and account_id in it and as Rajani suggested earlier those two are not needed as using user_id one can find account_id and domain_id. I guess, the easiest way would be to just add an additional user_id column. Cheers. On 15-Nov-2014, at 12:14 am, Min Chen min.c...@citrix.com wrote: Rohit, If I understood you correctly, the user_id column is only used for listing resources to indicate which user is the real owner/creator of the resource, but you don't want to change CloudStack account-level permission model to user-level permission model, right? If so, the change will be smaller, maybe some Response classes, which should not involve too many business layer change. I will hesitate to really change CloudStack IAM model though. Thanks -min On 11/14/14 10:35 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO and resource layer, and add columns in the schema. This gets us all the information we need to determine domainId, AccountId and Id (the user ID). Should we do it for all entities or just keep status quo (use account as owners), or just fix it on-demand basis for specific entities such as for user VMs [1]. [1] https://issues.apache.org
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Do you think this info is sufficient, Rohit? On Friday, November 14, 2014, Nitin Mehta nitin.me...@citrix.com wrote: Mike - we already do that in the action events (event table) ? We log the user_id as well and so we always would know the user responsible for an action One thing better we can do there is have a resource_id column in the table since the resource_id is currently embedded in the description at the moment. So instead of adding user_id for each resource we should do the change in the event table. Since all we want is a log of the actions. Thanks, -Nitin On 14/11/14 11:19 AM, Mike Tutkowski mike.tutkow...@solidfire.com javascript:; wrote: Yeah, I think the idea is not to change ownership of the resource but to be better able to 'assign blame' for action x or y. On Fri, Nov 14, 2014 at 12:17 PM, Prachi Damle prachi.da...@citrix.com javascript:; wrote: Rohit, Just on note on: Min, you’re right I don’t propose to change the IAM model just some additional data that notes who *actually* owns the resource (VM, volume, etc.) in an account which can be useful for sysadmins to list resource by userid etc. Adding 'user_id' column but not changing IAM model should be a small change and not causing any IAM side effects. But, it still won't really mean that that 'userid' 'owns' the resource. The ownership will still stay with the account - and so all other users in that account will still be able to access that resource, as per CS IAM. The userid will just provide an insight on which user in the account created the resource. Thanks, Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com javascript:;] Sent: Friday, November 14, 2014 11:04 AM To: dev@cloudstack.apache.org javascript:; Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Min, you’re right I don’t propose to change the IAM model just some additional data that notes who *actually* owns the resource (VM, volume, etc.) in an account which can be useful for sysadmins to list resource by userid etc. I can understand the hesitation and the side effects such a refactoring can produce, so I think the best would be to add user_id (uuid) columns and change only the API/query layer. Mike: I don’t propose to use user name but uuids so they are unique. My concern was adding user_id column to say vm_instance table denormalizes data as that table already has domain_id and account_id in it and as Rajani suggested earlier those two are not needed as using user_id one can find account_id and domain_id. I guess, the easiest way would be to just add an additional user_id column. Cheers. On 15-Nov-2014, at 12:14 am, Min Chen min.c...@citrix.com javascript:; wrote: Rohit, If I understood you correctly, the user_id column is only used for listing resources to indicate which user is the real owner/creator of the resource, but you don't want to change CloudStack account-level permission model to user-level permission model, right? If so, the change will be smaller, maybe some Response classes, which should not involve too many business layer change. I will hesitate to really change CloudStack IAM model though. Thanks -min On 11/14/14 10:35 AM, Rohit Yadav rohit.ya...@shapeblue.com javascript:; wrote: Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com javascript:; wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com javascript:; wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity and not a user? If user were the owner, we could easily get the account Id using the user Id. One solution to fix this problem is to refactor and replace Account (interface) usage with UserAccount (interface) usage, fix the DAO
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Good discussion everyone. Nitin, I thought of using that as well but there are some issues using events; - events can be deleted - if some sysadmin is working with the db/tables, he would appreciate if all the information are with the resource (for VMs, the vm_instance table) Prachi, thanks I think I’ll go with just adding the column and make additions in the API/UI. I understand the ownership of the VM/resource will still be with the account, the purpose is mostly to support API query such as listing VMs of a userid etc. On 15-Nov-2014, at 2:52 am, Nitin Mehta nitin.me...@citrix.com wrote: Mike - we already do that in the action events (event table) ? We log the user_id as well and so we always would know the user responsible for an action One thing better we can do there is have a resource_id column in the table since the resource_id is currently embedded in the description at the moment. So instead of adding user_id for each resource we should do the change in the event table. Since all we want is a log of the actions. Thanks, -Nitin On 14/11/14 11:19 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Yeah, I think the idea is not to change ownership of the resource but to be better able to 'assign blame' for action x or y. On Fri, Nov 14, 2014 at 12:17 PM, Prachi Damle prachi.da...@citrix.com wrote: Rohit, Just on note on: Min, you’re right I don’t propose to change the IAM model just some additional data that notes who *actually* owns the resource (VM, volume, etc.) in an account which can be useful for sysadmins to list resource by userid etc. Adding 'user_id' column but not changing IAM model should be a small change and not causing any IAM side effects. But, it still won't really mean that that 'userid' 'owns' the resource. The ownership will still stay with the account - and so all other users in that account will still be able to access that resource, as per CS IAM. The userid will just provide an insight on which user in the account created the resource. Thanks, Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Friday, November 14, 2014 11:04 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Min, you’re right I don’t propose to change the IAM model just some additional data that notes who *actually* owns the resource (VM, volume, etc.) in an account which can be useful for sysadmins to list resource by userid etc. I can understand the hesitation and the side effects such a refactoring can produce, so I think the best would be to add user_id (uuid) columns and change only the API/query layer. Mike: I don’t propose to use user name but uuids so they are unique. My concern was adding user_id column to say vm_instance table denormalizes data as that table already has domain_id and account_id in it and as Rajani suggested earlier those two are not needed as using user_id one can find account_id and domain_id. I guess, the easiest way would be to just add an additional user_id column. Cheers. On 15-Nov-2014, at 12:14 am, Min Chen min.c...@citrix.com wrote: Rohit, If I understood you correctly, the user_id column is only used for listing resources to indicate which user is the real owner/creator of the resource, but you don't want to change CloudStack account-level permission model to user-level permission model, right? If so, the change will be smaller, maybe some Response classes, which should not involve too many business layer change. I will hesitate to really change CloudStack IAM model though. Thanks -min On 11/14/14 10:35 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Min, Good to know. What do you propose we do moving forward. Do a refactoring run to fix it or leave it as it is and perhaps add user_id columns to few resources that are more useful for sysadmins such as vm_instance table. On 14-Nov-2014, at 11:49 pm, Min Chen min.c...@citrix.com wrote: Rohit, I think that the historic reason for this is that CloudStack is only doing IAM access permission check on account level, user is only login authentication purpose. That is why we will see that all our CloudStack resource owner field is an account, since that is the only information used for controlling whether you have some permissions to the resource. Thanks -min On 11/14/14 12:53 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, All CloudStack DB entities (VM, storage, network etc.) have an owner field which is mostly the account. An account can have multiple users so just by looking at the resource (say VM) it¹s not possible to make out which user in the account (owner or account_id field in the db row of the entity) created it. CloudStack users may want to know this information for at least entities such as VMs and Volumes. Historically, why is the account owner of an entity
