Re: [PR] Document advance DRS settings [cloudstack-documentation]
DaanHoogland commented on PR #374: URL: https://github.com/apache/cloudstack-documentation/pull/374#issuecomment-1910017237 @vishesh92 is this for 4.19? or next release? -- 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: [PR] Document advance DRS settings [cloudstack-documentation]
vishesh92 commented on PR #374: URL: https://github.com/apache/cloudstack-documentation/pull/374#issuecomment-1910028475 > @vishesh92 is this for 4.19? or next release? I was thinking of getting this in 4.19.1. -- 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: [PR] added cluster_id parameter and modified hostid to host_id [cloudstack-terraform-provider]
sureshanaparti commented on code in PR #79:
URL:
https://github.com/apache/cloudstack-terraform-provider/pull/79#discussion_r1466261875
##
cloudstack/resource_cloudstack_instance.go:
##
@@ -144,7 +144,12 @@ func resourceCloudStackInstance() *schema.Resource {
Optional: true,
},
- "hostid": {
+ "host_id": {
Review Comment:
this can impact existing users using hostid param, doc/release notes update
needed. cc @kiranchavala
--
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: [PR] Document advance DRS settings [cloudstack-documentation]
sureshanaparti commented on code in PR #374: URL: https://github.com/apache/cloudstack-documentation/pull/374#discussion_r1466263602 ## source/adminguide/clusters.rst: ## @@ -74,6 +74,30 @@ Following are the configuration parameters for DRS. Very high value for ``drs.max.migrations`` can result in management server using up all of it's workers for DRS tasks and not being able to execute other tasks. +There are some advanced parameters that can be configured for DRS. These paramters impact the way imbalance is calculated Review Comment: ```suggestion There are some advanced parameters that can be configured for DRS. These parameters impact the way imbalance is calculated ``` -- 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: [PR] Document advance DRS settings [cloudstack-documentation]
sureshanaparti commented on code in PR #374: URL: https://github.com/apache/cloudstack-documentation/pull/374#discussion_r1466265505 ## source/adminguide/clusters.rst: ## @@ -74,6 +74,30 @@ Following are the configuration parameters for DRS. Very high value for ``drs.max.migrations`` can result in management server using up all of it's workers for DRS tasks and not being able to execute other tasks. +There are some advanced parameters that can be configured for DRS. These paramters impact the way imbalance is calculated +for a cluster. Do not change these parameters unless you know what you are doing. + +.. list-table:: Advanced DRS related cluster parameters + :header-rows: 1 + + * - Parameter + - Default + - Description + * - ``drs.metric.type`` + - `used` + - The metric type used to measure imbalance in a cluster. This can completely change the imbalance value. + Possible values are free, used. + * - ``drs.metric.use.ratio`` + - `true` + - Whether to use ratio of selected metric & total. Useful when the cluster has hosts with different capacities. + * - ``drs.imbalance.condensed.skip.threshold`` + - `0.95` + - Threshold to ignore the metric for a host while calculating the imbalance to decide whether DRS is required for + a cluster.This is to avoid cases when the calculated imbalance gets skewed due to a single host having a very Review Comment: ```suggestion a cluster. This is to avoid cases when the calculated imbalance gets skewed due to a single host having a very ``` -- 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: [PR] Document advance DRS settings [cloudstack-documentation]
sureshanaparti commented on code in PR #374: URL: https://github.com/apache/cloudstack-documentation/pull/374#discussion_r1466265836 ## source/adminguide/clusters.rst: ## @@ -74,6 +74,30 @@ Following are the configuration parameters for DRS. Very high value for ``drs.max.migrations`` can result in management server using up all of it's workers for DRS tasks and not being able to execute other tasks. +There are some advanced parameters that can be configured for DRS. These paramters impact the way imbalance is calculated +for a cluster. Do not change these parameters unless you know what you are doing. + +.. list-table:: Advanced DRS related cluster parameters + :header-rows: 1 + + * - Parameter + - Default + - Description + * - ``drs.metric.type`` + - `used` + - The metric type used to measure imbalance in a cluster. This can completely change the imbalance value. + Possible values are free, used. + * - ``drs.metric.use.ratio`` + - `true` + - Whether to use ratio of selected metric & total. Useful when the cluster has hosts with different capacities. + * - ``drs.imbalance.condensed.skip.threshold`` + - `0.95` + - Threshold to ignore the metric for a host while calculating the imbalance to decide whether DRS is required for + a cluster.This is to avoid cases when the calculated imbalance gets skewed due to a single host having a very + high/low metric value resulting in imbalance being higher than 1. If ``drs.metric.type`` is ``free``, set a lower Review Comment: ```suggestion high/low metric value resulting in imbalance being higher than 1. If ``drs.metric.type`` is ``free``, set a lower ``` -- 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: [PR] added cluster_id parameter and modified hostid to host_id [cloudstack-terraform-provider]
kiranchavala commented on code in PR #79:
URL:
https://github.com/apache/cloudstack-terraform-provider/pull/79#discussion_r1466273040
##
cloudstack/resource_cloudstack_instance.go:
##
@@ -144,7 +144,12 @@ func resourceCloudStackInstance() *schema.Resource {
Optional: true,
},
- "hostid": {
+ "host_id": {
Review Comment:
@sureshanaparti, I think existing users are not affected as the hostid param
was not present in 0.4.0 release.
hostid fix is also planned for 0.5.0 release, I just changed it from hostid
to host_id to follow the convention
https://github.com/apache/cloudstack-terraform-provider/pull/52
--
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: [PR] added cluster_id parameter and modified hostid to host_id [cloudstack-terraform-provider]
sureshanaparti commented on code in PR #79:
URL:
https://github.com/apache/cloudstack-terraform-provider/pull/79#discussion_r1466275228
##
cloudstack/resource_cloudstack_instance.go:
##
@@ -144,7 +144,12 @@ func resourceCloudStackInstance() *schema.Resource {
Optional: true,
},
- "hostid": {
+ "host_id": {
Review Comment:
ok @kiranchavala
--
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: [PR] Fixup drs docs [cloudstack-documentation]
DaanHoogland merged PR #376: URL: https://github.com/apache/cloudstack-documentation/pull/376 -- 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
[VOTE] drop first version number and continue with semantic versioning
LS, As previously discussed [1] there is a growing wish to no longer carry the version number 4 in future versions. The proposal is to proceed as usual but just drop the first number. This means the next version will be called 20.0, in addition to a possible 4.18.2 and/or 4.19.1 +1 for agree 0 for no strong opinion or objects either way -1 for disagree (add your reason to be counted) [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87 -- Daan
Re: [PROPOSAL] version naming : drop the 4.
Hello guys, It is nice that we are discussing this topic; however, what is the point? Is it just a semantic change? Or we will be able to introduce changes that cause incompatibility between versions (although some incompatibilities are already introduced even when they should not)? By the way, I already have in mind some changes that would cause incompatibilities between versions; some of they are: - unifying duplicated APIs, like the "list*Metrics" APIs; it should be a single parameter in the existing API, not a whole new API; - renaming misleading APIs, like "createCondition" and others from the AutoScale group that are not intuitive; - standardize the APIs' response names, vide PR #7022 [1]; - and so many other disruptive changes. If it is just a semantic change, then it does not make sense. We would just make a show off to the community, but nothing would change at all. What are the technical reasons between the proposal? Best regards, Daniel Salvador (gutoveronezi) [1] https://github.com/apache/cloudstack/pull/7022 On 1/24/24 09:45, Wido den Hollander wrote: Op 24/01/2024 om 10:47 schreef Daan Hoogland: personally I don't like the months too much. They tie us down to a release schedule that we have proven not to be able to maintain. a year as number restricts us to just one major release that year, i.e. only one moment for new integrations or major features. S I am for the more liberal 20.x and if we make a second one some year we can freely add a number. Our mails just crossed :-) Timing! Does .MM tie you down to a specific schedule? You can release whenever you want, right? The version depends on when you release. But I'm ok with just going with an number. 24, then 25, then 26, etc. Something else then 4.x for ever. Wido On Wed, Jan 24, 2024 at 12:27 AM Wei ZHOU wrote: Yes, the ubuntu version naming is the best in my opinion. Other than the version naming, we need to decide the frequency of major releases and minor releases, which version will be LTS, how long the LTS/normal version will be supported, etc. Maybe a vote in the dev/users/pmc mailing list? 在 2024年1月23日星期二，Nicolas Vazquez 写道： I like this idea as well, even if its .MM or YY.MM. Would we want to define delivery months for releases similar to Ubuntu .04 and .10? Regards, Nicolas Vazquez From: Nux Sent: Tuesday, January 23, 2024 6:11 PM To: dev@cloudstack.apache.org Cc: Wei ZHOU Subject: Re: [PROPOSAL] version naming : drop the 4. An interesting proposition, I like it. It would also relieve us from having to come up with any over-the-top feature or change for a major version change. On 2024-01-23 14:49, Wido den Hollander wrote: We could look at Ubuntu, and other projects, and call it 2025.01 if we release it in Jan 2025. A great post on the website, mailinglists and social media could explain the change in versioning, but that the code doesn't change that much. Project has matured, etc, etc.
Re: [VOTE] drop first version number and continue with semantic versioning
Hello guys, I just replied the discussion thread and I would like to discuss it a little bit further before voting. Best regards, Daniel Salvador (gutoveronezi) On 1/25/24 11:47, Daan Hoogland wrote: LS, As previously discussed [1] there is a growing wish to no longer carry the version number 4 in future versions. The proposal is to proceed as usual but just drop the first number. This means the next version will be called 20.0, in addition to a possible 4.18.2 and/or 4.19.1 +1 for agree 0 for no strong opinion or objects either way -1 for disagree (add your reason to be counted) [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
Re: [VOTE] drop first version number and continue with semantic versioning
Agree with Daniel, I would prefer to discuss this further too. I think we're moving too fast with the voting. Regards. From: Guto Veronezi Sent: Thursday, January 25, 2024 20:25 To: dev@cloudstack.apache.org Subject: Re: [VOTE] drop first version number and continue with semantic versioning Hello guys, I just replied the discussion thread and I would like to discuss it a little bit further before voting. Best regards, Daniel Salvador (gutoveronezi) On 1/25/24 11:47, Daan Hoogland wrote: > LS, > > As previously discussed [1] there is a growing wish to no longer carry > the version number 4 in future versions. The proposal is to proceed as > usual but just drop the first number. This means the next version will > be called 20.0, in addition to a possible 4.18.2 and/or 4.19.1 > > +1 for agree > 0 for no strong opinion or objects either way > -1 for disagree (add your reason to be counted) > > [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87 >
Re: [VOTE] drop first version number and continue with semantic versioning
happy to discuss further (not agreeing at all with the arguments). This vote is closed without conclusion. On Thu, Jan 25, 2024 at 5:28 PM Rohit Yadav wrote: > > Agree with Daniel, I would prefer to discuss this further too. I think we're > moving too fast with the voting. > > > Regards. > > > > > > From: Guto Veronezi > Sent: Thursday, January 25, 2024 20:25 > To: dev@cloudstack.apache.org > Subject: Re: [VOTE] drop first version number and continue with semantic > versioning > > Hello guys, > > I just replied the discussion thread and I would like to discuss it a > little bit further before voting. > > Best regards, > Daniel Salvador (gutoveronezi) > > On 1/25/24 11:47, Daan Hoogland wrote: > > LS, > > > > As previously discussed [1] there is a growing wish to no longer carry > > the version number 4 in future versions. The proposal is to proceed as > > usual but just drop the first number. This means the next version will > > be called 20.0, in addition to a possible 4.18.2 and/or 4.19.1 > > > > +1 for agree > > 0 for no strong opinion or objects either way > > -1 for disagree (add your reason to be counted) > > > > [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87 > > -- Daan
