RE: [DISCUSS] Upgrading Mockito & phasing out powermock
+1 Agree with the approach, Vishesh. -Original Message- From: Wei ZHOU Sent: Tuesday, June 6, 2023 8:11 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Upgrading Mockito & phasing out powermock lgtm. go ahead Vishesh. -Wei On Tue, 6 Jun 2023 at 14:17, Vishesh Jindal wrote: > Hi all, > > I am working on upgrading Mockito's version & phasing out powermock. > For new maven modules, I would request all to use Mockito's mockStatic > instead of Powermock. > > Why? > Powermock's last release was on Nov 2, 2020. The project seems to have > been abandoned. Powermock has compatibility issues with Mockito's > latest version as well. > > How? > The only usage for PowerMock I could see in code was for mocking > static methods. Since Mockito v3.4.0, it has the capability to mock static > methods. > I plan to migrate tests to Mockito's mockStatic instead of PowerMock. > This will have to be done module by module and will take some time. > > I have prepared a PR here: > https://github.com/apache/cloudstack/pull/7577 > > This PR upgrades mockito from v3.2.4 to v3.12.4 and removes the usage > of PowerMock from utils module. > > > Let me know if you have any questions/concerns. > > Regards, > Vishesh > > > > >
RE: [proposal] Consistency of naming in Cloudstack
Hi Daan - thanks for your input. Some comments inline below Kind Regards Giles -Original Message- From: Daan Hoogland Sent: Thursday, June 8, 2023 4:17 PM To: dev@cloudstack.apache.org Subject: Re: [proposal] Consistency of naming in Cloudstack Giles, the principle of what you are saying seems good but I have a few remarks; 1. Consistency should not become a goal. Clarity is and if context might give rise to a different understanding of the same work consistency is detrimental to understanding >> I *think* I understand your point, but I see high correlation between >> consistency of naming and clarity. Surely, using different names (or >> metaphors!) for the same object type inherently reduces clarity?. Could you >> give an example of where using different names for one cloudstack object >> type could increase clarity ? 2. Metaphor is an important aspect in system development [1] first introduced into software development in xtreme programming [2] I think instance is a bad metaphor to use for Virtual Machine Instances in a system that is full of all kinds of items (first class citizens) that can also be seen as instances. I would go for "VM instance", "VM-instance" or just machines. I am not saying either of these are ideal but they are all better than instance. >>To be clear here: this would involve renaming every UI element to >>standardise. Would you propose renaming the current main menu & lifecycle >>commands to one of these names ? and finally 3. The industry standard is not a good reason to go for a term. we can improve on the industry standard and so we should. >> We'll have to agree to disagree on that €0.02 [1] https://medium.com/swlh/the-importance-of-metaphors-in-programming-philosophy-and-trading-a0030ed176b6 [2] http://www.extremeprogramming.org/rules/metaphor.html On Thu, Jun 8, 2023 at 4:47 PM Giles Sirett wrote: > > Background > Recently, I have been looking at a number of issues relating to the > "first use" / "first impression" use of cloudstack. What to people > think of Cloudstack as a new user? What is peoples perception of > Cloudstack as a new user ? How easy is it for people to understand > cloudstack & its concepts and to get help > > > One thing I have seen is that CloudStack is inconsistent with what we call > VM's/Instances: > > > * In the UI main menu, we say Instances. We then have a very large > "Create instance" button. All lifecycle operations are then "Foo Instance" > * In various other places in the UI (many text messages, error messages, > column headers, for example) we say "VM" > * The API uses Instance, VM and Virtual Machine > * The documentation, again, uses all 3 terms > > Now - I know everybody on this list (myself included for the last 10 > years) has always used these terms interchangeably - we all KNOW that > these are the same things. However, I think it could cause confusion > to people seeing Cloudstack for the first time and create negative > impressions. Also, there is no consistency when searching > documentation - one page uses one term, one the other (and some even > use both on the same page) . I don't know of many other pieces of > software that use 2/3 different names for their primary functional > object > > > My proposal is to move towards having consistency of this naming and would > look something like this: > > > 1. Choose the name to use going forwards (more on that later) > 2. Undertake a remedial exercise: > * Update UI elements to [new name] > * Update documentation to [New Name] > * Leave Global Settings names alone, but change their description to > reflect [New Name] > * Leave the API alone - theres no way of getting consistency there > without breaking compatibility > 3. Encourage contributors to use [new name] in all work going > forwards > > > The remedial exercise (hopefully) could be a find/replace (with some > manual checking) - I'd be happy to take that on with some help from work > colleagues As/when/if we do do Cloudstack 5.0, then look at the API, but IMO > this is lower priority as people that's not usdually "first impression" > > > So - first proposal point: any objections to me undertaking this work ? > > > Second point: what to call these things ? > It is my view that we should call them Instances. These are my reasons: > > * Nearly all Cloud computing platforms refer to them as instances (i.e. > industry standard) . Yes, it is a VM "behind the scenes", but Instance is an > accepted term that is slightly abstracted from VM > * Our primary UI already uses Instance ns most prominent places, renaming > top level nav and functionality is a step backwards IMO > * Today, Cloudstack provides these through VMs , but that could change in > the future (please don't read anything into that comment) - instance doesn't > tie us to VMs (which is probably why most cloud providers use it
[GitHub] [cloudstack-documentation] DaanHoogland commented on a diff in pull request #315: CKS: Add documentation for unmanaged kubernetes cluster
DaanHoogland commented on code in PR #315: URL: https://github.com/apache/cloudstack-documentation/pull/315#discussion_r1224018203 ## source/plugins/cloudstack-kubernetes-service.rst: ## @@ -185,22 +187,24 @@ New Kubernetes clusters can be created using the API or via the UI. User will be createKubernetesCluster API can be used to create new Kubernetes cluster. It takes following parameters as input, - **name** (name for the Kubernetes cluster; Required) -- **description** (description for the Kubernetes cluster; Required) +- **description** (description for the Kubernetes cluster) Review Comment: the png still shows the red star for required . can you update that as well? ## source/plugins/cloudstack-kubernetes-service.rst: ## @@ -185,22 +187,24 @@ New Kubernetes clusters can be created using the API or via the UI. User will be createKubernetesCluster API can be used to create new Kubernetes cluster. It takes following parameters as input, - **name** (name for the Kubernetes cluster; Required) -- **description** (description for the Kubernetes cluster; Required) +- **description** (description for the Kubernetes cluster) - **zoneid** (availability zone in which Kubernetes cluster to be launched; Required) -- **kubernetesversionid** (Kubernetes version with which cluster to be launched; Required) -- **serviceofferingid** (the ID of the service offering for the virtual machines in the cluster; Required) +- **kubernetesversionid** (Kubernetes version with which cluster to be launched; Required for CloudManaged clusters) Review Comment: is "CloudManaged" the right term? we could be looking at other SDI managed clusters as well and these would not be CloudManaged from our perspective. I think "CloudStack managed" would be a better term. ## source/plugins/cloudstack-kubernetes-service.rst: ## @@ -185,22 +187,24 @@ New Kubernetes clusters can be created using the API or via the UI. User will be createKubernetesCluster API can be used to create new Kubernetes cluster. It takes following parameters as input, - **name** (name for the Kubernetes cluster; Required) -- **description** (description for the Kubernetes cluster; Required) +- **description** (description for the Kubernetes cluster) - **zoneid** (availability zone in which Kubernetes cluster to be launched; Required) -- **kubernetesversionid** (Kubernetes version with which cluster to be launched; Required) -- **serviceofferingid** (the ID of the service offering for the virtual machines in the cluster; Required) +- **kubernetesversionid** (Kubernetes version with which cluster to be launched; Required for CloudManaged clusters) Review Comment: addendum I see that the term is explained further on. I think it should be explained at first use. (not sure if we have a glosary this would fit into) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [proposal] Consistency of naming in Cloudstack
Giles, just about point one as the others follow from it. On Fri, Jun 9, 2023 at 10:17 AM Giles Sirett wrote: > > Hi Daan - thanks for your input. Some comments inline below > > > > Kind Regards > Giles > > > > > -Original Message- > From: Daan Hoogland > Sent: Thursday, June 8, 2023 4:17 PM > To: dev@cloudstack.apache.org > Subject: Re: [proposal] Consistency of naming in Cloudstack > > Giles, the principle of what you are saying seems good but I have a few > remarks; 1. Consistency should not become a goal. Clarity is and if context > might give rise to a different understanding of the same work consistency is > detrimental to understanding > > >> I *think* I understand your point, but I see high correlation between > >> consistency of naming and clarity. Surely, using different names (or > >> metaphors!) for the same object type inherently reduces clarity?. Could > >> you give an example of where using different names for one cloudstack > >> object type could increase clarity ? When under "compute", there is the occurrence of "instance", this is not accurate. It is not a "compute instance". Would this item occur under "Virtual Machines" there would not be an issue. I am sure we can find many instances for the use of "instance" that would not refer to a VM instance. (that sentence was not more than a happy incident!) So far the only good argument I read about using "instance" is the fact that iot has already been used a lot. which is "kind of" weak. As far as I can see the industry is already doing damage control, specifying other uses of instance further to avoid cognitive clashes. > €0.02 > > [1] > https://medium.com/swlh/the-importance-of-metaphors-in-programming-philosophy-and-trading-a0030ed176b6 > [2] http://www.extremeprogramming.org/rules/metaphor.html > > On Thu, Jun 8, 2023 at 4:47 PM Giles Sirett > wrote: > > > > Background > > Recently, I have been looking at a number of issues relating to the > > "first use" / "first impression" use of cloudstack. What to people > > think of Cloudstack as a new user? What is peoples perception of > > Cloudstack as a new user ? How easy is it for people to understand > > cloudstack & its concepts and to get help > > > > > > One thing I have seen is that CloudStack is inconsistent with what we call > > VM's/Instances: > > > > > > * In the UI main menu, we say Instances. We then have a very large > > "Create instance" button. All lifecycle operations are then "Foo Instance" > > * In various other places in the UI (many text messages, error > > messages, column headers, for example) we say "VM" > > * The API uses Instance, VM and Virtual Machine > > * The documentation, again, uses all 3 terms > > > > Now - I know everybody on this list (myself included for the last 10 > > years) has always used these terms interchangeably - we all KNOW that > > these are the same things. However, I think it could cause confusion > > to people seeing Cloudstack for the first time and create negative > > impressions. Also, there is no consistency when searching > > documentation - one page uses one term, one the other (and some even > > use both on the same page) . I don't know of many other pieces of > > software that use 2/3 different names for their primary functional > > object > > > > > > My proposal is to move towards having consistency of this naming and would > > look something like this: > > > > > > 1. Choose the name to use going forwards (more on that later) > > 2. Undertake a remedial exercise: > > * Update UI elements to [new name] > > * Update documentation to [New Name] > > * Leave Global Settings names alone, but change their description > > to reflect [New Name] > > * Leave the API alone - theres no way of getting consistency there > > without breaking compatibility > > 3. Encourage contributors to use [new name] in all work going > > forwards > > > > > > The remedial exercise (hopefully) could be a find/replace (with some > > manual checking) - I'd be happy to take that on with some help from work > > colleagues As/when/if we do do Cloudstack 5.0, then look at the API, but > > IMO this is lower priority as people that's not usdually "first impression" > > > > > > So - first proposal point: any objections to me undertaking this work ? > > > > > > Second point: what to call these things ? > > It is my view that we should call them Instances. These are my reasons: > > > > * Nearly all Cloud computing platforms refer to them as instances (i.e. > > industry standard) . Yes, it is a VM "behind the scenes", but Instance is > > an accepted term that is slightly abstracted from VM > > * Our primary UI already uses Instance ns most prominent places, > > renaming top level nav and functionality is a step backwards IMO > > * Today, Cloudstack provides these through VMs , but that could change > > in the future (please don't read anything into that comment) -
[GitHub] [cloudstack-terraform-provider] rohityadavcloud commented on pull request #60: Fix Build Error - Too Many Arguments
rohityadavcloud commented on PR #60: URL: https://github.com/apache/cloudstack-terraform-provider/pull/60#issuecomment-1584759050 Thanks for the PR @FarnazBGH I still see the error from the CI: ```==> Checking that code complies with gofmt requirements... make: *** [GNUmakefile:32: fmtcheck] Error 1 gofmt needs running on the following files: ./cloudstack/data_source_cloudstack_instance_test.go You can use the command: `make fmt` to reformat code. Error: Process completed with exit code 2. ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-terraform-provider] rohityadavcloud commented on pull request #62: Feature/vapp properties added
rohityadavcloud commented on PR #62: URL: https://github.com/apache/cloudstack-terraform-provider/pull/62#issuecomment-1584759497 Thanks for the PR @Z-eeshan I've pinged a few contributors to review. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [proposal] Consistency of naming in Cloudstack
+1 to use “Instance” in the UI and docs. Everyone knows what " Instance " is, in my view, just a label to refer to an object in ACS. As Rohit said, it is under Compute, then it refers to a Compute Instance. From: Giles Sirett Date: Thursday, 8 June 2023 at 16:46 To: dev@cloudstack.apache.org Subject: [proposal] Consistency of naming in Cloudstack Background Recently, I have been looking at a number of issues relating to the "first use" / "first impression" use of cloudstack. What to people think of Cloudstack as a new user? What is peoples perception of Cloudstack as a new user ? How easy is it for people to understand cloudstack & its concepts and to get help One thing I have seen is that CloudStack is inconsistent with what we call VM's/Instances: * In the UI main menu, we say Instances. We then have a very large "Create instance" button. All lifecycle operations are then "Foo Instance" * In various other places in the UI (many text messages, error messages, column headers, for example) we say "VM" * The API uses Instance, VM and Virtual Machine * The documentation, again, uses all 3 terms Now - I know everybody on this list (myself included for the last 10 years) has always used these terms interchangeably - we all KNOW that these are the same things. However, I think it could cause confusion to people seeing Cloudstack for the first time and create negative impressions. Also, there is no consistency when searching documentation - one page uses one term, one the other (and some even use both on the same page) . I don't know of many other pieces of software that use 2/3 different names for their primary functional object My proposal is to move towards having consistency of this naming and would look something like this: 1. Choose the name to use going forwards (more on that later) 2. Undertake a remedial exercise: * Update UI elements to [new name] * Update documentation to [New Name] * Leave Global Settings names alone, but change their description to reflect [New Name] * Leave the API alone - theres no way of getting consistency there without breaking compatibility 3. Encourage contributors to use [new name] in all work going forwards The remedial exercise (hopefully) could be a find/replace (with some manual checking) - I'd be happy to take that on with some help from work colleagues As/when/if we do do Cloudstack 5.0, then look at the API, but IMO this is lower priority as people that's not usdually "first impression" So - first proposal point: any objections to me undertaking this work ? Second point: what to call these things ? It is my view that we should call them Instances. These are my reasons: * Nearly all Cloud computing platforms refer to them as instances (i.e. industry standard) . Yes, it is a VM "behind the scenes", but Instance is an accepted term that is slightly abstracted from VM * Our primary UI already uses Instance ns most prominent places, renaming top level nav and functionality is a step backwards IMO * Today, Cloudstack provides these through VMs , but that could change in the future (please don't read anything into that comment) - instance doesn't tie us to VMs (which is probably why most cloud providers use it) So, my proposal is to bring consistency and use the term Instance >From brief discussions, I know other people favour other terms and may have >objections to the term Instance (despite it having been in use in ACS for many >years) - but happy to take all inputs if people feel this is just wrong. Kind Regards Giles
[GitHub] [cloudstack-terraform-provider] rohityadavcloud commented on pull request #62: Feature/vapp properties added
rohityadavcloud commented on PR #62: URL: https://github.com/apache/cloudstack-terraform-provider/pull/62#issuecomment-1584903704 @Z-eeshan can you check the build failures? (probably a go fmt fix?) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [proposal] Consistency of naming in Cloudstack
+1 thanks Giles. For the API we could also update the API docs descriptions for methods, parameters, and response fields (even though we can end up with: parameter: virtualmachineid and description: ‘Instance ID’ for example) Regards, Nicolas Vazquez From: Marco Sinhoreli Date: Friday, 9 June 2023 at 12:58 To: dev@cloudstack.apache.org Subject: Re: [proposal] Consistency of naming in Cloudstack +1 to use “Instance” in the UI and docs. Everyone knows what " Instance " is, in my view, just a label to refer to an object in ACS. As Rohit said, it is under Compute, then it refers to a Compute Instance. From: Giles Sirett Date: Thursday, 8 June 2023 at 16:46 To: dev@cloudstack.apache.org Subject: [proposal] Consistency of naming in Cloudstack Background Recently, I have been looking at a number of issues relating to the "first use" / "first impression" use of cloudstack. What to people think of Cloudstack as a new user? What is peoples perception of Cloudstack as a new user ? How easy is it for people to understand cloudstack & its concepts and to get help One thing I have seen is that CloudStack is inconsistent with what we call VM's/Instances: * In the UI main menu, we say Instances. We then have a very large "Create instance" button. All lifecycle operations are then "Foo Instance" * In various other places in the UI (many text messages, error messages, column headers, for example) we say "VM" * The API uses Instance, VM and Virtual Machine * The documentation, again, uses all 3 terms Now - I know everybody on this list (myself included for the last 10 years) has always used these terms interchangeably - we all KNOW that these are the same things. However, I think it could cause confusion to people seeing Cloudstack for the first time and create negative impressions. Also, there is no consistency when searching documentation - one page uses one term, one the other (and some even use both on the same page) . I don't know of many other pieces of software that use 2/3 different names for their primary functional object My proposal is to move towards having consistency of this naming and would look something like this: 1. Choose the name to use going forwards (more on that later) 2. Undertake a remedial exercise: * Update UI elements to [new name] * Update documentation to [New Name] * Leave Global Settings names alone, but change their description to reflect [New Name] * Leave the API alone - theres no way of getting consistency there without breaking compatibility 3. Encourage contributors to use [new name] in all work going forwards The remedial exercise (hopefully) could be a find/replace (with some manual checking) - I'd be happy to take that on with some help from work colleagues As/when/if we do do Cloudstack 5.0, then look at the API, but IMO this is lower priority as people that's not usdually "first impression" So - first proposal point: any objections to me undertaking this work ? Second point: what to call these things ? It is my view that we should call them Instances. These are my reasons: * Nearly all Cloud computing platforms refer to them as instances (i.e. industry standard) . Yes, it is a VM "behind the scenes", but Instance is an accepted term that is slightly abstracted from VM * Our primary UI already uses Instance ns most prominent places, renaming top level nav and functionality is a step backwards IMO * Today, Cloudstack provides these through VMs , but that could change in the future (please don't read anything into that comment) - instance doesn't tie us to VMs (which is probably why most cloud providers use it) So, my proposal is to bring consistency and use the term Instance >From brief discussions, I know other people favour other terms and may have >objections to the term Instance (despite it having been in use in ACS for many >years) - but happy to take all inputs if people feel this is just wrong. Kind Regards Giles
