Re: [VOTE] Standard string lib

[Pearl d'Silva]

+1. Sounds like a good plan.

From: Gabriel Br?scher 
Sent: Monday, September 13, 2021 9:15 PM
To: dev 
Subject: Re: [VOTE] Standard string lib

+1

On Mon, Sep 13, 2021, 12:40 Sadi  wrote:

> +1
>
> Good idea.
>
> On 13/09/2021 12:02, Daniel Augusto Veronezi Salvador wrote:
> > Hi All,
> >
> > We had a discussion about standardizing the string libs we're using (
> https://lists.apache.org/thread.html/r806cd10b3de645c150e5e0e3d845c5a380a700197143f57f0834d758%40%3Cdev.cloudstack.apache.org%3E
> ).
> >
> > As I proposed, I'm opening this voting thread to see if all are in favor
> of using "commons.lang3" as the String standard library and for String
> operations not convered on "commons.lang3", we use our StringUtils. Then,
> if the vote passes, I will create the PR to address this change in the code
> base by removing unnecessary libraries, and changing the code to use
> "commons.lang3".
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> > Best regards,
> > Daniel
> >
>

 

[GitHub] [cloudstack-terraform-provider] manunolo closed issue #4: Problem creating a VM with custom offering

[GitBox]

manunolo closed issue #4:
URL: https://github.com/apache/cloudstack-terraform-provider/issues/4


   


-- 
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] manunolo opened a new issue #4: Problem creating a VM with custom offering

[GitBox]

manunolo opened a new issue #4:
URL: https://github.com/apache/cloudstack-terraform-provider/issues/4


   I have a problem when I want to build a virtual machine with a custom offer, 
I cannot set the custom values I need for Cpu, Ram and CPUSpeed. 
   
   ```
   Terraform will perform the following actions:
   
 # cloudstack_instance.web will be created
 + resource "cloudstack_instance" "web" {
 + display_name = (known after apply)
 + expunge  = false
 + group= (known after apply)
 + id   = (known after apply)
 + ip_address   = (known after apply)
 + name = "VMLab"
 + network_id   = "06cc48b7-2d66-4c03-8075-4059e04336a7"
 + project  = (known after apply)
 + root_disk_size   = (known after apply)
 + service_offering = "custom offering"
 + start_vm = true
 + tags = (known after apply)
 + template = "7e2ced7e-ae24-4631-8367-aebcf0652a25"
 + zone = "ZoneLab"
   }
   
   Plan: 1 to add, 0 to change, 0 to destroy.
   
   Do you want to perform these actions?
 Terraform will perform the actions described above.
 Only 'yes' will be accepted to approve.
   
 Enter a value: yes
   
   cloudstack_instance.web: Creating...
   ╷
   │ Error: Error creating the new instance server-1: CloudStack API error 431 
(CSExceptionErrorCode: 4350): Need to specify custom parameter values cpu, cpu 
speed and memory when using custom offering
   │ 
   │   with cloudstack_instance.web,
   │   on main.tf line 21, in resource "cloudstack_instance" "web":
   │   21: resource "cloudstack_instance" "web" {
   │ 
   ╵
   ```
   
   


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

4.16.0.0 release

[Nicolas Vazquez]

Hi All,

We are looking forward to cutting RC1 soon. Kindly share or ping me this week 
if there are any issues or pull requests that we should include in 4.16.0.0.


Regards,

Nicolas Vazquez

 

RE: Hi (Again)

[Paul Angus]

Thanks - it was good to find role with a chunk of CloudStack in it.



Kind regards

Paul Angus

-Original Message-
From: Andrija Panic  
Sent: 13 September 2021 14:39
To: dev 
Subject: Re: Hi (Again)

Welcome back, Paul :)

On Mon, 13 Sept 2021 at 14:40, Rohit Yadav 
wrote:

> Paul,
>
> Until the proper feature/changes are in, to pass any arbitrary 
> param/values to an API you can simply add them in the UI/URL.
>
> For example, as root admin:
> http://qa.cloudstack.cloud:8080/client/#/vm returns 11 VMs 
> http://qa.cloudstack.cloud:8080/client/#/vm?projectid=-1&listall=true
> returns 14 VMs (including all projects)
>
>
> Regards.
>
> 
> From: Pearl d'Silva 
> Sent: Monday, September 13, 2021 18:06
> To: dev@cloudstack.apache.org 
> Subject: Re: Hi (Again)
>
> Hi Paul,
>
> There's another PR inflight aiming towards achieving something similar:
> https://github.com/apache/cloudstack/pull/5207.
>
> Regards,
> Pearl
> 
> From: Paul Angus 
> Sent: Monday, September 13, 2021 5:23 PM
> To: dev@cloudstack.apache.org 
> Subject: RE: Hi (Again)
>
> Hi David,
>
> Harsh - But probably true
>
> Thanks for the link!
>
> Kind regards
>
> Paul Angus
>
>
>
>
>
>
>
> -Original Message-
> From: David Jumani 
> Sent: 13 September 2021 12:46
> To: dev@cloudstack.apache.org
> Subject: Re: Hi (Again)
>
> That doesn't seem like a big change from what you've already been 
> doing :D
>
> There's a PR for it https://github.com/apache/cloudstack/pull/4828
> 
> From: Paul Angus 
> Sent: Monday, September 13, 2021 4:50 PM
> To: us...@cloudstack.apache.org ; 
> dev@cloudstack.apache.org 
> Subject: Hi (Again)
>
> Hey All,
>
> So, I’ve moved over to the Dark Side, and I’m now purely a user of 
> CloudStack with Ticketmaster/Live Nation.  I’m mostly going to be all 
> about breaking things rather than fixing them 😊
>
> …Starting off with:  As root admin I can list all VMs including ones in
> projects via cmk -list virtualmachines projectid=-1
> Is there a way to do the same in the UI?
>
> Cheers!
>
> Paul.
>
> This message is confidential and may be legally privileged or 
> otherwise protected from disclosure. If you are not the intended 
> recipient, please telephone or email the sender and delete this 
> message and any attachment from your system; you must not copy or 
> disclose the contents of this message or any attachment to any other 
> person. We may monitor email traffic and the content of internal and 
> external messages sent to and from us to ensure compliance with internal 
> policies and for the purposes of security.
>
> Ticketmaster UK Limited. Registered Office: 30 St John Street, London 
> EC1M 4AY. Registered in England and Wales. Company Number 02662632.
>
>
>
>

-- 

Andrija Panić

Re: [VOTE] Standard string lib

[Gabriel Bräscher]

+1

On Mon, Sep 13, 2021, 12:40 Sadi  wrote:

> +1
>
> Good idea.
>
> On 13/09/2021 12:02, Daniel Augusto Veronezi Salvador wrote:
> > Hi All,
> >
> > We had a discussion about standardizing the string libs we're using (
> https://lists.apache.org/thread.html/r806cd10b3de645c150e5e0e3d845c5a380a700197143f57f0834d758%40%3Cdev.cloudstack.apache.org%3E
> ).
> >
> > As I proposed, I'm opening this voting thread to see if all are in favor
> of using "commons.lang3" as the String standard library and for String
> operations not convered on "commons.lang3", we use our StringUtils. Then,
> if the vote passes, I will create the PR to address this change in the code
> base by removing unnecessary libraries, and changing the code to use
> "commons.lang3".
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> > Best regards,
> > Daniel
> >
>

Re: [VOTE] Standard string lib

[Sadi]

+1

Good idea.

On 13/09/2021 12:02, Daniel Augusto Veronezi Salvador wrote:

Hi All,

We had a discussion about standardizing the string libs we're using 
(https://lists.apache.org/thread.html/r806cd10b3de645c150e5e0e3d845c5a380a700197143f57f0834d758%40%3Cdev.cloudstack.apache.org%3E).

As I proposed, I'm opening this voting thread to see if all are in favor of using "commons.lang3" 
as the String standard library and for String operations not convered on "commons.lang3", we use 
our StringUtils. Then, if the vote passes, I will create the PR to address this change in the code base by 
removing unnecessary libraries, and changing the code to use "commons.lang3".

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Best regards,
Daniel

Re: [VOTE] Standard string lib

[Daan Hoogland]

+1

On Mon, Sep 13, 2021 at 5:02 PM Daniel Augusto Veronezi Salvador <
gutoveron...@apache.org> wrote:

> Hi All,
>
> We had a discussion about standardizing the string libs we're using (
> https://lists.apache.org/thread.html/r806cd10b3de645c150e5e0e3d845c5a380a700197143f57f0834d758%40%3Cdev.cloudstack.apache.org%3E
> ).
>
> As I proposed, I'm opening this voting thread to see if all are in favor
> of using "commons.lang3" as the String standard library and for String
> operations not convered on "commons.lang3", we use our StringUtils. Then,
> if the vote passes, I will create the PR to address this change in the code
> base by removing unnecessary libraries, and changing the code to use
> "commons.lang3".
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Best regards,
> Daniel
>
>

-- 
Daan

[VOTE] Standard string lib

[Daniel Augusto Veronezi Salvador]

Hi All,

We had a discussion about standardizing the string libs we're using 
(https://lists.apache.org/thread.html/r806cd10b3de645c150e5e0e3d845c5a380a700197143f57f0834d758%40%3Cdev.cloudstack.apache.org%3E).

As I proposed, I'm opening this voting thread to see if all are in favor of 
using "commons.lang3" as the String standard library and for String operations 
not convered on "commons.lang3", we use our StringUtils. Then, if the vote 
passes, I will create the PR to address this change in the code base by 
removing unnecessary libraries, and changing the code to use "commons.lang3".

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Best regards,
Daniel

[GitHub] [cloudstack-go] pdion891 commented on pull request #7: Fix generator for map parameters that are lists of objects

[GitBox]

pdion891 commented on pull request #7:
URL: https://github.com/apache/cloudstack-go/pull/7#issuecomment-918280122


   nice, good to know ! 
   thanks ! 


-- 
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-go] psycofdj commented on pull request #7: Fix generator for map parameters that are lists of objects

[GitBox]

psycofdj commented on pull request #7:
URL: https://github.com/apache/cloudstack-go/pull/7#issuecomment-918272979


   like a charm, thank you !
   
   ```
   go get github.com/apache/cloudstack-go/v2@v2.10.0
   go: downloading github.com/apache/cloudstack-go/v2 v2.10.0
   go get: upgraded github.com/apache/cloudstack-go/v2 
v2.0.0-20210831123014-8290b0373f69 => v2.10.0
   ```
   
   ```diff
module github.com/terraform-providers/terraform-provider-cloudstack

require (
   -   github.com/apache/cloudstack-go/v2 v2.0.0-20210831123014-8290b0373f69
   +   github.com/apache/cloudstack-go/v2 v2.10.0
   github.com/hashicorp/go-multierror v1.1.1
   github.com/hashicorp/terraform-plugin-sdk v1.17.0
   github.com/smartystreets/goconvey v1.6.4 // indirect
   ```


-- 
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: [Discussion] Release Cycle

[Gabriel Bräscher]

Thanks for raising the bylaws, Paul.

You are absolutely right regarding point 2 being covered by 3.4.3 bylaws.
That's the idea indeed; keep the "extra" release aligned with the current
release plan.
Therefore, we would still hold the flexibility for having more releases if
that fits the community's desire. Combined with a "fixed" release.

To make it clear, this discussion's main goal is to find what would be the
ideal release period for the project (if there is any ideal), as well as
the LTS vs Regular topic.
"Point 1" would be added into the bylaws, and then "point 2", as you
correctly addressed, would keep the current bylaws. It would just need to
be updated with regards to being an "extra" release.

Considering the fact that the project is already releasing at least 1 LTS
per year -- and even releasing 2 LTSs/year in some cases -- I don't see why
not doing such formalization/bylaw changes.
We could also create a "point 3" which would cover a case where there is no
need in releasing a new LTS in the year, which I doubt will happen anytime
soon. Such a case would require a discussion/vote in order to cancel the
LTS of the year.

 Release roadmap
I notice that there are some doubts regarding this topic. Sorry for not
making myself clear with regard to this topic.

> On point 1, "...a roadmap would be defined to guide the community through
> the year." Is this something ridged or a fluid list of things people think
> they'll be putting in as they go along?


The proposal is to not be too rigid, and it would not cover features nor
bug fixes but mainly the releases themselves (4.15, 4.16, 4.X ... 5.0,...).
As an example, we could define the following:
- LTS
Begin of Q4 - 20XY: Raise a discussion looking for volunteers for the next
LTS
End of Q4 - 20XY: the volunteer RM proposes freeze dates and is already
working towards the release process
Q1 - 20XY+1: branch is in the freeze state, RCs will be raised for a vote
Q1/Q2 - 20XY+1: LTS is released when passes on RC vote

- Regular
Begin of Q2 - 20XY+1: Raise a discussion looking for volunteers for the
next Regular
End of Q2 - 20XY+1: RM proposes freeze dates and is already working towards
the release
Q3 - 20XY+1: branch is in the frozen state, RCs will be raised for a vote
Q3/Q4 - 20XY+1: LTS is released when passes on RC vote

- LTS maintenance (X.Y.0.0, X.Y.1.0, ...)
For the LTS maintenance releases, it would stay as currently. Someone
volunteers at any time following "3.4.3. Release Plan" and "3.4.4. Product
Release".

As an example for Releases roadmap to be presented for users:

+-+-+--+-+
| Release | Type| Release date | EOL |
+-+-+--+-+
| Y.C | Regular | Q3 - 2023| N/A | <- we can go up to
a reasonable future date and update with the time (1,2 years)
+-+-+--+-+
| Y.B | LTS | Q1 - 2023| Q1 - 2024   |
+-+-+--+-+
| Y.A | Regular | Q3 - 2022| N/A |
+-+-+--+-+
| X.B | LTS | Q1 - 2022| Q1 - 2023   |
+-+-+--+-+
| X.A | Regular | Q3 - 2022| N/A |
+-+-+--+-+
| 4.16| LTS | Q4 - 2021| Q4 - 2022   | <- to be released,
so we have a plan with the quarter and year
+-+-+--+-+
| 4.15| LTS | 19 Jan 2021  | 1 July 2022 | <- released, so we
have the exact date of release and EOL
+-+-+--+-+
| 4.14| LTS | 26 May 2020  | 1 Jan 2022  |
+-+-+--+-+
| 4.13| LTS | 24 Sep. 2019 | 1 May 2021  |
+-+-+--+-+
| 4.12| Regular | 4 April 2019 | N/A |
+-+-+--+-+
| 4.11| LTS | 12 Feb. 2018 | 1 July 2019 |
+-+-+--+-+


Regards,
Gabriel.

Em sáb., 11 de set. de 2021 às 17:26, Paul Angus 
escreveu:

> Gabriel,
>
> FYI  point 2 is covered in the community bylaws (Section 3.4.3)
>
> 3.4.3. Release Plan
> - Defines the timetable and work items for a release. The plan also
> nominates a Release Manager.
> - A lazy majority of active committers is required for approval.
> - Any active committer or PMC member may call a vote. The vote must occur
> on the project development mailing list.
>
> On point 1, "...a roadmap would be defined to guide the community through
> the year." Is this something ridged or a fluid list of things people think
> they'll be putting in as they go along?
>
> Also, you haven't covered WHO is doing these releases that the community
> is committing to.  Otherwise a +1 means that the voter was committing
> themselves to working on the release.
>
> 3.1.2. Voting may take four flavors:
>   3.1.2.1.+1 "Yes," "Agree," or "the 

[GitHub] [cloudstack-go] pdion891 commented on pull request #7: Fix generator for map parameters that are lists of objects

[GitBox]

pdion891 commented on pull request #7:
URL: https://github.com/apache/cloudstack-go/pull/7#issuecomment-918268464


   release 4.15.1.0 deleted and a new one created 
https://github.com/apache/cloudstack-go/releases/tag/v2.10.0
   


-- 
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: [Discussion] String libs

[Daniel Augusto Veronezi Salvador]

Thanks all for the replies.

To summarize what we discussed till now:

- Devs are inclined to use facade, as it may ease the upgrade and 
maintenance process of 3rd party libs.
- We should standardize the libs we're using. "commons.lang3" is a solid 
candidate, as it provides all we need, has more than 10 years in the 
wild, is open-source, and maintained by Apache.


My opinion:

I do understand the pros of adopting a facade approach; however, I don't 
see the necessity of it in this case.
- We're inclined to use "commons.lang3" to all the implementations, 
which would make a facade of 1 to 1, which does not seem to make much sense.
- If we need to upgrade any lib, as "commons.lang" to "commons.lang3", a 
simple "find/replace" would solve most of the cases. Also, it's not like 
we will have to upgrade the lib every week; therefore, it will be a 
once/twice in a lifetime job (this one would be the first).
- If we create a facade, we should also create unit tests to ensure that 
the behavior is equal to the lib and redirect the javadocs to the 
underlying lib javadocs. Therefore, it adds a complexity level to our 
code and makes us responsible for the lib's operation.


Having said that, I would not be in favor of facade approach. I 
understand its pros, but just don't see the need for it in this case.


I will open a voting thread to see if all are in favor of using 
"commons.lang3" as the String standard library. Then, if the vote 
passes, I will create the PR to address this change in the code base by 
removing unnecessary libraries, and changing the code to use 
"commons.lang3".


Best regards,
Daniel

On 13/09/2021 09:59, Daan Hoogland wrote:

@Gabriel Beims Bräscher , I would agree that just
standardising could work as well, but only if we sanction just a single
implementation. This has proven to be hard in the past. I say, let's do
both;
- Let's make a facade. If names are good, do a transparent passthrough, if
not the best let's use our own, as Rohit suggested.
- If lang3 indeed provides all that we need from any library, let's
standardise on it.
Note that stringutils are just a simple albeit annoying example. We have
some more similar jobs to do, some of which involve message format or other
things and are quite risky.



On Mon, Sep 13, 2021 at 10:13 AM Suresh Anaparti <
suresh.anapa...@shapeblue.com> wrote:


It's always good to move to the updated libraries, and I agree on
upgrading to lang3 library (from lang).

We can continue use/improve our facade 'com.cloud.utils.StringUtils' for
readability, custom utils from third party libs, this will be a single
point of update whenever any util library is upgraded in future.

Regards,
Suresh

On 10/09/21, 11:00 PM, "Gabriel Bräscher"  wrote:

 I do understand that a facade adds great value in many situations.

 However, I am afraid that this could escalate up to a point of us
 maintaining multiple facades of well-known libraries that in the end
 already offer us what we need.
 Such libraries tend to be stable; as an example, lang3 was launched in
2011
 and has been rock solid since then.
 If we get into upgrading, at least in the "apache.commons.lang3"
example,
 wpiçd be a "find and replace" operation [see:
 https://commons.apache.org/proper/commons-lang/article3_0.html].

 I am inclined into adopting "apache.commons.lang3" and then upgrading
all
 occurrences of "apache.commons.lang" (as mentioned, "find and replace"
 operation). But I would be OK in moving into a facade.
 My main concern/goal is to adopt a pattern ASAP, and I would be +1 both
 ways as long as we ensure a standard in the current and future
codebase.

 Em qua., 8 de set. de 2021 às 12:21, Daan Hoogland <
daan.hoogl...@gmail.com>
 escreveu:

 > Daniel et al,
 > I've no preference and don't mind multiple dependencies when they
supply
 > overlapping features. I do want to keep 3rd party libraries in facade
 > projects at all times. It keeps maintenance surface small and it is
easier
 > to see conflicts happening (a good reason to reduce dependencies
btw, me
 > contradicting me).
 > Both your and Rohit's points make sense to me.
 >
 > On Wed, Sep 8, 2021 at 2:36 PM Nicolas Vazquez <
 > nicolas.vazq...@shapeblue.com> wrote:
 >
 > > Hi Daniel,
 > >
 > > I don't have a preference either, but the work you are proposing
on your
 > > PR makes sense to me.
 > >
 > >
 > > Regards,
 > >
 > > Nicolas Vazquez
 > >
 > > 
 > > From: Rohit Yadav 
 > > Sent: Wednesday, September 8, 2021 5:05 AM
 > > To: dev@cloudstack.apache.org 
 > > Subject: Re: [Discussion] String libs
 > >
 > > I don't have any specific inclination, I would use whatever
becomes a
 > > standard.
 > >
 > > However, I prefer the readability of a utility method that is
readable
 > and
 > > easy to understand such

[GitHub] [cloudstack-go] psycofdj commented on pull request #7: Fix generator for map parameters that are lists of objects

[GitBox]

psycofdj commented on pull request #7:
URL: https://github.com/apache/cloudstack-go/pull/7#issuecomment-918260351


   yes, that's how gomodules works from my experience and from what I 
understand of the linked documentation.
   
   With the current tag, I have to use pseudo-versioning, like this:
   ```
require (
  github.com/apache/cloudstack-go/v2 v2.0.0-20210831123014-8290b0373f69
   )
   ```
   
   many tools are will no longer be usable with pseudo-versions, eg. simple 
update command like `go get ...` or more sophiticated ones like github's 
dependabot.


-- 
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-go] pdion891 commented on pull request #7: Fix generator for map parameters that are lists of objects

[GitBox]

pdion891 commented on pull request #7:
URL: https://github.com/apache/cloudstack-go/pull/7#issuecomment-918254644


   oh, so you think creating release version that match cloudstack version such 
as the one I did this morning is bad from a go lib perspective? we had a 
discussion in dev@cloudstack.apache.org about using versioning same as 
cloudstack releases, nobody raised that point.
   
   So from your perspective, we should use v2.x.y because our GO module  is v2 
at the moment ?


-- 
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-go] psycofdj commented on pull request #7: Fix generator for map parameters that are lists of objects

[GitBox]

psycofdj commented on pull request #7:
URL: https://github.com/apache/cloudstack-go/pull/7#issuecomment-918225329


   Thanks @pdion891 for the release
   
   Unless I'm mistaken, the release tag should be `v2..` as long as the 
library declares itself as `module github.com/apache/cloudstack-go/v2`
   - https://go.dev/blog/publishing-go-modules
   - https://go.dev/blog/v2-go-modules
   
   Another way could be to modify the `go.mod` file and declare the library as 
`v4` but since the new release is mostly bugfixes I'm afraid that it will break 
the semantic meaning of the major version.


-- 
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: Hi (Again)

[Andrija Panic]

Welcome back, Paul :)

On Mon, 13 Sept 2021 at 14:40, Rohit Yadav 
wrote:

> Paul,
>
> Until the proper feature/changes are in, to pass any arbitrary
> param/values to an API you can simply add them in the UI/URL.
>
> For example, as root admin:
> http://qa.cloudstack.cloud:8080/client/#/vm returns 11 VMs
> http://qa.cloudstack.cloud:8080/client/#/vm?projectid=-1&listall=true
> returns 14 VMs (including all projects)
>
>
> Regards.
>
> 
> From: Pearl d'Silva 
> Sent: Monday, September 13, 2021 18:06
> To: dev@cloudstack.apache.org 
> Subject: Re: Hi (Again)
>
> Hi Paul,
>
> There's another PR inflight aiming towards achieving something similar:
> https://github.com/apache/cloudstack/pull/5207.
>
> Regards,
> Pearl
> 
> From: Paul Angus 
> Sent: Monday, September 13, 2021 5:23 PM
> To: dev@cloudstack.apache.org 
> Subject: RE: Hi (Again)
>
> Hi David,
>
> Harsh - But probably true
>
> Thanks for the link!
>
> Kind regards
>
> Paul Angus
>
>
>
>
>
>
>
> -Original Message-
> From: David Jumani 
> Sent: 13 September 2021 12:46
> To: dev@cloudstack.apache.org
> Subject: Re: Hi (Again)
>
> That doesn't seem like a big change from what you've already been doing :D
>
> There's a PR for it https://github.com/apache/cloudstack/pull/4828
> 
> From: Paul Angus 
> Sent: Monday, September 13, 2021 4:50 PM
> To: us...@cloudstack.apache.org ;
> dev@cloudstack.apache.org 
> Subject: Hi (Again)
>
> Hey All,
>
> So, I’ve moved over to the Dark Side, and I’m now purely a user of
> CloudStack with Ticketmaster/Live Nation.  I’m mostly going to be all about
> breaking things rather than fixing them 😊
>
> …Starting off with:  As root admin I can list all VMs including ones in
> projects via cmk -list virtualmachines projectid=-1
> Is there a way to do the same in the UI?
>
> Cheers!
>
> Paul.
>
> This message is confidential and may be legally privileged or otherwise
> protected from disclosure. If you are not the intended recipient, please
> telephone or email the sender and delete this message and any attachment
> from your system; you must not copy or disclose the contents of this
> message or any attachment to any other person. We may monitor email traffic
> and the content of internal and external messages sent to and from us to
> ensure compliance with internal policies and for the purposes of security.
>
> Ticketmaster UK Limited. Registered Office: 30 St John Street, London EC1M
> 4AY. Registered in England and Wales. Company Number 02662632.
>
>
>
>

-- 

Andrija Panić

[GitHub] [cloudstack-go] pdion891 commented on pull request #7: Fix generator for map parameters that are lists of objects

[GitBox]

pdion891 commented on pull request #7:
URL: https://github.com/apache/cloudstack-go/pull/7#issuecomment-918180372


   Release v4.15.1 build and available. 


-- 
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-go] psycofdj edited a comment on pull request #7: Fix generator for map parameters that are lists of objects

[GitBox]

psycofdj edited a comment on pull request #7:
URL: https://github.com/apache/cloudstack-go/pull/7#issuecomment-918167857


   I was waiting the release to bump it in 
https://github.com/orange-cloudfoundry/terraform-provider-cloudstack. I see 
that @rhtyd has already talked with my colleague @ArthurHlt 
[here](orange-cloudfoundry/terraform-provider-cloudstack#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

[GitHub] [cloudstack-go] psycofdj commented on pull request #7: Fix generator for map parameters that are lists of objects

[GitBox]

psycofdj commented on pull request #7:
URL: https://github.com/apache/cloudstack-go/pull/7#issuecomment-918167857


   I was watting the release to bump it in 
https://github.com/orange-cloudfoundry/terraform-provider-cloudstack. I see 
that @rhtyd has already talked with my colleague @ArthurHlt 
[here](orange-cloudfoundry/terraform-provider-cloudstack#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: [Discussion] String libs

[Daan Hoogland]

@Gabriel Beims Bräscher , I would agree that just
standardising could work as well, but only if we sanction just a single
implementation. This has proven to be hard in the past. I say, let's do
both;
- Let's make a facade. If names are good, do a transparent passthrough, if
not the best let's use our own, as Rohit suggested.
- If lang3 indeed provides all that we need from any library, let's
standardise on it.
Note that stringutils are just a simple albeit annoying example. We have
some more similar jobs to do, some of which involve message format or other
things and are quite risky.



On Mon, Sep 13, 2021 at 10:13 AM Suresh Anaparti <
suresh.anapa...@shapeblue.com> wrote:

> It's always good to move to the updated libraries, and I agree on
> upgrading to lang3 library (from lang).
>
> We can continue use/improve our facade 'com.cloud.utils.StringUtils' for
> readability, custom utils from third party libs, this will be a single
> point of update whenever any util library is upgraded in future.
>
> Regards,
> Suresh
>
> On 10/09/21, 11:00 PM, "Gabriel Bräscher"  wrote:
>
> I do understand that a facade adds great value in many situations.
>
> However, I am afraid that this could escalate up to a point of us
> maintaining multiple facades of well-known libraries that in the end
> already offer us what we need.
> Such libraries tend to be stable; as an example, lang3 was launched in
> 2011
> and has been rock solid since then.
> If we get into upgrading, at least in the "apache.commons.lang3"
> example,
> wpiçd be a "find and replace" operation [see:
> https://commons.apache.org/proper/commons-lang/article3_0.html].
>
> I am inclined into adopting "apache.commons.lang3" and then upgrading
> all
> occurrences of "apache.commons.lang" (as mentioned, "find and replace"
> operation). But I would be OK in moving into a facade.
> My main concern/goal is to adopt a pattern ASAP, and I would be +1 both
> ways as long as we ensure a standard in the current and future
> codebase.
>
> Em qua., 8 de set. de 2021 às 12:21, Daan Hoogland <
> daan.hoogl...@gmail.com>
> escreveu:
>
> > Daniel et al,
> > I've no preference and don't mind multiple dependencies when they
> supply
> > overlapping features. I do want to keep 3rd party libraries in facade
> > projects at all times. It keeps maintenance surface small and it is
> easier
> > to see conflicts happening (a good reason to reduce dependencies
> btw, me
> > contradicting me).
> > Both your and Rohit's points make sense to me.
> >
> > On Wed, Sep 8, 2021 at 2:36 PM Nicolas Vazquez <
> > nicolas.vazq...@shapeblue.com> wrote:
> >
> > > Hi Daniel,
> > >
> > > I don't have a preference either, but the work you are proposing
> on your
> > > PR makes sense to me.
> > >
> > >
> > > Regards,
> > >
> > > Nicolas Vazquez
> > >
> > > 
> > > From: Rohit Yadav 
> > > Sent: Wednesday, September 8, 2021 5:05 AM
> > > To: dev@cloudstack.apache.org 
> > > Subject: Re: [Discussion] String libs
> > >
> > > I don't have any specific inclination, I would use whatever
> becomes a
> > > standard.
> > >
> > > However, I prefer the readability of a utility method that is
> readable
> > and
> > > easy to understand such as isNullOrEmpty (which suggests it's
> doing a
> > null
> > > check) versus isEmpty.
> > >
> > > I suppose a refactoring exercise can be done by picking whatever
> > favourite
> > > dependency community consensus is built for (if at all) and then
> write a
> > > utility method in something like StringsUtil in cloud-utils and
> use it
> > > throughout the codebase so in future if we want to move to
> something
> > else -
> > > all you do is replace your favourite dependency with something new
> only
> > in
> > > StringsUtils of cloud-utils.
> > >
> > > ... and update the cloudstack-checkstyle to enforce the new agreed
> upon
> > > rule and also update -
> > >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Coding+conventions
> > >
> > >
> > > Regards.
> > >
> > > 
> > > From: Daniel Augusto Veronezi Salvador 
> > > Sent: Tuesday, September 7, 2021 04:37
> > > To: dev@cloudstack.apache.org 
> > > Subject: [Discussion] String libs
> > >
> > > Hi all,
> > >
> > > Currently, the main String libs we are using are "commons.lang" and
> > > "commons.lang3" (either directly or by our facade,
> "com.cloud.utils"). We
> > > have a current discussion about using them directly or via a
> facade (such
> > > as "com.cloud.utils"); however, a third implementation has been
> added
> > > (google.common.base), which adds more to the discussion.
> "commons.lang"
> > > already implement all we n

[GitHub] [cloudstack-go] rhtyd commented on pull request #7: Fix generator for map parameters that are lists of objects

[GitBox]

rhtyd commented on pull request #7:
URL: https://github.com/apache/cloudstack-go/pull/7#issuecomment-918151370


   Thanks for volunteering @pdion891 - I suppose we'll also need to check/make 
a list of known users so we don't accidentally break them. The two I know are: 
https://github.com/apache/cloudstack-terraform-provider and 
https://github.com/apache/cloudstack-kubernetes-provider cc @davidjumani 
@Pearl1594 - anything to add/suggest?


-- 
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: Hi (Again)

[Rohit Yadav]

Paul,

Until the proper feature/changes are in, to pass any arbitrary param/values to 
an API you can simply add them in the UI/URL.

For example, as root admin:
http://qa.cloudstack.cloud:8080/client/#/vm returns 11 VMs
http://qa.cloudstack.cloud:8080/client/#/vm?projectid=-1&listall=true returns 
14 VMs (including all projects)


Regards.


From: Pearl d'Silva 
Sent: Monday, September 13, 2021 18:06
To: dev@cloudstack.apache.org 
Subject: Re: Hi (Again)

Hi Paul,

There's another PR inflight aiming towards achieving something similar: 
https://github.com/apache/cloudstack/pull/5207.

Regards,
Pearl

From: Paul Angus 
Sent: Monday, September 13, 2021 5:23 PM
To: dev@cloudstack.apache.org 
Subject: RE: Hi (Again)

Hi David,

Harsh - But probably true

Thanks for the link!

Kind regards

Paul Angus




 


-Original Message-
From: David Jumani 
Sent: 13 September 2021 12:46
To: dev@cloudstack.apache.org
Subject: Re: Hi (Again)

That doesn't seem like a big change from what you've already been doing :D

There's a PR for it https://github.com/apache/cloudstack/pull/4828

From: Paul Angus 
Sent: Monday, September 13, 2021 4:50 PM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Hi (Again)

Hey All,

So, I’ve moved over to the Dark Side, and I’m now purely a user of CloudStack 
with Ticketmaster/Live Nation.  I’m mostly going to be all about breaking 
things rather than fixing them 😊

…Starting off with:  As root admin I can list all VMs including ones in 
projects via cmk -list virtualmachines projectid=-1
Is there a way to do the same in the UI?

Cheers!

Paul.

This message is confidential and may be legally privileged or otherwise 
protected from disclosure. If you are not the intended recipient, please 
telephone or email the sender and delete this message and any attachment from 
your system; you must not copy or disclose the contents of this message or any 
attachment to any other person. We may monitor email traffic and the content of 
internal and external messages sent to and from us to ensure compliance with 
internal policies and for the purposes of security.

Ticketmaster UK Limited. Registered Office: 30 St John Street, London EC1M 4AY. 
Registered in England and Wales. Company Number 02662632.

Re: Hi (Again)

[Pearl d'Silva]

Hi Paul,

There's another PR inflight aiming towards achieving something similar: 
https://github.com/apache/cloudstack/pull/5207.

Regards,
Pearl

From: Paul Angus 
Sent: Monday, September 13, 2021 5:23 PM
To: dev@cloudstack.apache.org 
Subject: RE: Hi (Again)

Hi David,

Harsh - But probably true

Thanks for the link!

Kind regards

Paul Angus

 


-Original Message-
From: David Jumani 
Sent: 13 September 2021 12:46
To: dev@cloudstack.apache.org
Subject: Re: Hi (Again)

That doesn't seem like a big change from what you've already been doing :D

There's a PR for it https://github.com/apache/cloudstack/pull/4828

From: Paul Angus 
Sent: Monday, September 13, 2021 4:50 PM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Hi (Again)

Hey All,

So, I’ve moved over to the Dark Side, and I’m now purely a user of CloudStack 
with Ticketmaster/Live Nation.  I’m mostly going to be all about breaking 
things rather than fixing them 😊

…Starting off with:  As root admin I can list all VMs including ones in 
projects via cmk -list virtualmachines projectid=-1
Is there a way to do the same in the UI?

Cheers!

Paul.

This message is confidential and may be legally privileged or otherwise 
protected from disclosure. If you are not the intended recipient, please 
telephone or email the sender and delete this message and any attachment from 
your system; you must not copy or disclose the contents of this message or any 
attachment to any other person. We may monitor email traffic and the content of 
internal and external messages sent to and from us to ensure compliance with 
internal policies and for the purposes of security.

Ticketmaster UK Limited. Registered Office: 30 St John Street, London EC1M 4AY. 
Registered in England and Wales. Company Number 02662632.

Zones and regions in CloudStack

[Jonas Porsche]

Hi All, @Hoang,

I have a short question. In the old CloudStack UI were a separation between 
regions and zones. But I don't find it in the new UI. Is this change intended?

Kind regards
Jonas Porsche

__

Jonas Porsche
BA-Student der Informatik

EWERK DIGITAL GmbH
Br?hl 24, D-04109 Leipzig
P
F +49 341 42649 - 98
j.pors...@ewerk.com
www.ewerk.com

Gesch?ftsf?hrer:
Dr. Erik Wende, Hendrik Schubert, Tassilo M?schke
Registergericht: Leipzig HRB 9065

Support:
+49 341 42649 555

Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 2-1:2018

ISAE 3402 Typ II Assessed

EWERK-Blog | 
LinkedIn | 
Xing | 
Twitter | 
Facebook


Ausk?nfte und Angebote per Mail sind freibleibend und unverbindlich.

Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschlie?lich etwaiger beigef?gter Dateien) ist 
vertraulich und nur f?r den Empf?nger bestimmt. Sollten Sie nicht der 
bestimmungsgem??e Empf?nger sein, ist Ihnen jegliche Offenlegung, 
Vervielf?ltigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte 
informieren Sie in diesem Fall unverz?glich den Absender und l?schen Sie die 
E-Mail (einschlie?lich etwaiger beigef?gter Dateien) von Ihrem System. Vielen 
Dank.

The contents of this e-mail (including any attachments) are confidential and 
may be legally privileged. If you are not the intended recipient of this 
e-mail, any disclosure, copying, distribution or use of its contents is 
strictly prohibited, and you should please notify the sender immediately and 
then delete it (including any attachments) from your system. Thank you.

[GitHub] [cloudstack-go] psycofdj commented on pull request #7: Fix generator for map parameters that are lists of objects

[GitBox]

psycofdj commented on pull request #7:
URL: https://github.com/apache/cloudstack-go/pull/7#issuecomment-918126448


   Thanks a lot


-- 
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-go] pdion891 commented on pull request #7: Fix generator for map parameters that are lists of objects

[GitBox]

pdion891 commented on pull request #7:
URL: https://github.com/apache/cloudstack-go/pull/7#issuecomment-918125968


   Hi @psycofdj, we will create a new release this week ! 


-- 
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: Hi (Again)

[Paul Angus]

Hi David,

Harsh - But probably true

Thanks for the link!

Kind regards

Paul Angus

-Original Message-
From: David Jumani  
Sent: 13 September 2021 12:46
To: dev@cloudstack.apache.org
Subject: Re: Hi (Again)

That doesn't seem like a big change from what you've already been doing :D

There's a PR for it https://github.com/apache/cloudstack/pull/4828

From: Paul Angus 
Sent: Monday, September 13, 2021 4:50 PM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Hi (Again)

Hey All,

So, I’ve moved over to the Dark Side, and I’m now purely a user of CloudStack 
with Ticketmaster/Live Nation.  I’m mostly going to be all about breaking 
things rather than fixing them 😊

…Starting off with:  As root admin I can list all VMs including ones in 
projects via cmk -list virtualmachines projectid=-1
Is there a way to do the same in the UI?

Cheers!

Paul.

This message is confidential and may be legally privileged or otherwise 
protected from disclosure. If you are not the intended recipient, please 
telephone or email the sender and delete this message and any attachment from 
your system; you must not copy or disclose the contents of this message or any 
attachment to any other person. We may monitor email traffic and the content of 
internal and external messages sent to and from us to ensure compliance with 
internal policies and for the purposes of security.

Ticketmaster UK Limited. Registered Office: 30 St John Street, London EC1M 4AY. 
Registered in England and Wales. Company Number 02662632.

 

Re: Hi (Again)

[David Jumani]

That doesn't seem like a big change from what you've already been doing :D

There's a PR for it https://github.com/apache/cloudstack/pull/4828

From: Paul Angus 
Sent: Monday, September 13, 2021 4:50 PM
To: us...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 
Subject: Hi (Again)

Hey All,

So, I’ve moved over to the Dark Side, and I’m now purely a user of CloudStack 
with Ticketmaster/Live Nation.  I’m mostly going to be all about breaking 
things rather than fixing them 😊

…Starting off with:  As root admin I can list all VMs including ones in 
projects via cmk -list virtualmachines projectid=-1
Is there a way to do the same in the UI?

Cheers!

Paul.

This message is confidential and may be legally privileged or otherwise 
protected from disclosure. If you are not the intended recipient, please 
telephone or email the sender and delete this message and any attachment from 
your system; you must not copy or disclose the contents of this message or any 
attachment to any other person. We may monitor email traffic and the content of 
internal and external messages sent to and from us to ensure compliance with 
internal policies and for the purposes of security.

Ticketmaster UK Limited. Registered Office: 30 St John Street, London EC1M 4AY. 
Registered in England and Wales. Company Number 02662632.

 

Hi (Again)

[Paul Angus]

Hey All,

So, I’ve moved over to the Dark Side, and I’m now purely a user of CloudStack 
with Ticketmaster/Live Nation.  I’m mostly going to be all about breaking 
things rather than fixing them 😊

…Starting off with:  As root admin I can list all VMs including ones in 
projects via cmk -list virtualmachines projectid=-1
Is there a way to do the same in the UI?

Cheers!

Paul.

This message is confidential and may be legally privileged or otherwise 
protected from disclosure. If you are not the intended recipient, please 
telephone or email the sender and delete this message and any attachment from 
your system; you must not copy or disclose the contents of this message or any 
attachment to any other person. We may monitor email traffic and the content of 
internal and external messages sent to and from us to ensure compliance with 
internal policies and for the purposes of security.

Ticketmaster UK Limited. Registered Office: 30 St John Street, London EC1M 4AY. 
Registered in England and Wales. Company Number 02662632.

Re: IPV6 in Isolated/VPC networks

[Rohit Yadav]

Thanks Alex, Wei. I've updated the docs here: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+Support+in+Isolated+Network+and+VPC+with+Static+Routing

I'll leave the thread open for futher discussion/ideas/feedback. I think we've 
completed the phase1 design doc including all feedback comments for adding IPv6 
support in CloudStack and some initial poc/work can be started. My colleagues 
and I will keep everyone posted on this thread and/or on a Github PR as and 
when we're able to start our work on the same (after 4.16, potentially towards 
4.17).


Regards.


From: Wei ZHOU 
Sent: Friday, September 10, 2021 20:22
To: dev@cloudstack.apache.org 
Subject: Re: IPV6 in Isolated/VPC networks

Agree with Alex.
We only need to know how many /64 are allocated. We do not care how many
ipv6 addresses are used by VMs.

-Wei

On Fri, 10 Sept 2021 at 16:36, Alex Mattioli 
wrote:

> Hi Rohit,
>
> I'd go for option 2, don't see a point tracking anything smaller than a
> /64 tbh.
>
> Cheers
> Alex
>
>
>
>
> -Original Message-
> From: Rohit Yadav 
> Sent: 09 September 2021 12:44
> To: dev@cloudstack.apache.org
> Subject: Re: IPV6 in Isolated/VPC networks
>
> Thanks Alex, Kristaps. I've updated the design doc to reflect two
> agreements:
>
>   *   Allocate /64 for both isolated network and VPC tiers, no large
> allocation of prefixes to VPC (cons: more static routing rules for upstream
> router/admins)
>   *   All systemvms (incl. ssvm, cpvm, VRs) get IPv6 address if zone has a
> dedicated /64 prefix/block for systemvms
>
> The only outstanding question now is:
>
>   *   How do we manage IPv6 usage? Can anyone advise how we do IPv6 usage
> for shared network (design, implementation and use-cases?)
> Option1: We don't do it, all user VMs nics have ipv4 address which whose
> usage we don't track. For public VR/nics/networks, we can simply add the
> IPv6 details for a related IPv4 address.
> Option2: Implement a separate, first-class IPv6 address or /64 prefix
> tracking/management and usage for all VMs and systemvms nic (this means
> account/domain level limits and new billing/records)
> Option3: other thoughts?
>
>
> Regards.
>
> 
> From: Alex Mattioli 
> Sent: Wednesday, September 8, 2021 23:24
> To: dev@cloudstack.apache.org 
> Subject: RE: IPV6 in Isolated/VPC networks
>
> Hi Rohit, Kristaps,
>
> I'd say option 1 as well,  it does create a bit more overhead with static
> routes but if that's automated for a VPC it can also be easily automated
> for several tiers of a VPC.  We also don't constrain the amount of tiers in
> a  VPC.
> It has the added advantage to be closer to the desired behaviour with
> dynamic routing in the future, where a VPC VR can announce several subnets
> upstream.
>
> Cheers
> Alex
>
>
>
>
>
>
>
>
>
>
> -Original Message-
> From: Rohit Yadav 
> Sent: 08 September 2021 19:04
> To: dev@cloudstack.apache.org
> Subject: Re: IPV6 in Isolated/VPC networks
>
> Hi Kristaps,
>
> Thanks for sharing, I suppose that means individual tiers should be
> allocated /64 instead of larger ipv6 blocks to the whole VPC which could
> cause wastage.
>
> Any objection from anybody?
>
> Regards.
> 
> From: Kristaps Cudars 
> Sent: Wednesday, September 8, 2021 9:24:01 PM
> To: dev@cloudstack.apache.org 
> Subject: Re: IPV6 in Isolated/VPC networks
>
> Hello,
>
> I asked networking team to comment on "How should the IPv6
> block/allocation work in VPCs?"
> Option1: They haven't seen lately devices with limits on how many static
> routes can be created.
> Option2: With /60 and /62 assignments and big quantity of routers IPv6
> assignment from RIPE NNC can be drained fast.
>
> /48 contains 64000 /64
> /60 contains 16 /64
> 64000 / 16 = 4000 routers
>
>
> On 2021/09/07 11:59:09, Rohit Yadav  wrote:
> > All,
> >
> > After another iteration with Alex, I've updated the design doc. Kindly
> review:
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+Support+in
> > +Isolated+Network+and+VPC+with+Static+Routing
> >
> >
> > ... and advise on some outstanding questions:
> >
> >   *   How should the IPv6 block/allocation work in VPCs?
> > Option1: Should this be simply /64 allocation on any new tier, the
> > cons of this option is one static route/rule per VPC tier. (many
> > upstream routers may have limit on no. of static routes?)
> > Option2: Let user ask/specify tier size, say /60 (for 16 tiers) or /62
> (4 tiers) for the VPC, this can be filtered based on the vpc.max.networks
> global setting (3 is default). The pros of this option are less no. of
> static route/rule and easy programming, but potential wastage of multiple
> /64 prefix blocks for unused/uncreated tiers.
> >   *   How do we manage IPv6 usage? Can anyone advise how we do IPv6
> usage for shared network (design, implementation and use-cases?)
> > Option1: We don't do it, all user VMs nics have ipv4 address which whose
> usage we don't

Re: [VOTE] Apache CloudStack 4.15.2.0 (RC2)

[Rohit Yadav]

+1 (binding)

With help from my colleagues Bobby and Vladi, I performed the following tests:

  *   Fresh installation + smoketests (RC1 & RC2):
 *   CentOS7 ms  + CentOS 7 kvm - all pass
 *   CentOS7 ms + XCP-ng 8.2 - all pass
 *   Ubuntu 18.04 ms + Ubuntu 20.04 kvm - all pass except failures in few 
vm_lifecycle test cases around vm migration with storage (env specific, they 
passed in other KVM-combinations)
 *   CentOS 7 ms + VMware6.7 - all pass
 *   CentOS7 ms + XenServer71 - all pass
  *   Manual tests: (RC2)
 *   CentOS8 ms + Vmware 7 + SSL enabled UI+systemvms - all pass, manually 
tested VM lifecycle + novnc
 *   Ubuntu 20.04 ms + CentOS 8 KVM + SSL enabled UI+systemvms  + CKS - all 
pass, manually tested VM lifecycle, CKS cluster deployment + kubectl listing 
etc., novnc+ssl
 *   Execute high-level 4.15.2 UI smoketests 
https://github.com/apache/cloudstack-primate/blob/master/.github/ISSUE_TEMPLATE/smoke_test_plan.md
 (with VMware env) as admin and user accounts - pass
  *   Upgrade tests: (manual, RC1)
 *   Pre-upgrade: deploy resources (vm, volumes, templates, project, vpc, 
network+rules etc) and register 4.15.1 systemvmtemplate as necessary
 *   Post-upgrade: switch to JRE11 in case of very old releases wherever 
necessary + restart services, repeat basic resource lifecycles (VM, volumes, 
network, template etc); test ssh access to guest VM pre&post upgrade with 
old/new VRs + novnc/console
 *   Upgrades covered:
*   CentOS7 ms + ACS 4.15.1 + VMware6.5 (no systemvmtemplate 
registeration required pre-upgrade)
*   CentOS7 ms + ACS 4.14.1 + XenServer 7.1
*   CentOS7 ms + ACS 4.13.1 + CentOS7 KVM
*   Ubuntu 18.04 ms + ACS 4.13.1 + XCP-ng 7.4
*   CentOS7 ms + ACS 4.11.3 + VMware 6.5
  *   Changes since RC1: Only UI changes, five UI bugfix PRs manually tested, 
and manually tested-confirmed in RC2 
(https://github.com/apache/cloudstack/commits/4.15)
All backend smoke tests were repeated with RC2. Since RC2 had no backend 
changes, upgrade tests were not repeated.

Regards.


From: Rohit Yadav 
Sent: Friday, September 10, 2021 21:26
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack 4.15.2.0 (RC2)

Typo and correction:

For users convenience, the packages from this release candidate (RC2) will be 
available here shortly:
https://download.cloudstack.org/testing/4.15.2.0-RC2/


Regards.


From: Rohit Yadav 
Sent: Friday, September 10, 2021 21:21
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: [VOTE] Apache CloudStack 4.15.2.0 (RC2)

All,

I've created a 4.15.2.0 release, with the following artifacts up for a vote:

Git Branch and Commit SHA:
https://github.com/apache/cloudstack/tree/4.15.2.0-RC20210910T2119
Commit: 4aaa850b63c34e0f312002f79bf9e4f699bf314a

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.15.2.0/

PGP release keys (signed using 5ED1E1122DC5E8A4A45112C2484248210EE3D884):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

The vote will be open for a week until 17 September 2021.

For sanity in tallying the vote, can PMC members please be sure to indicate
"(binding)" with their vote?

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

For users convenience, the packages from this release candidate (RC1)
will be available here shortly:
https://download.cloudstack.org/testing/4.15.2.0-RC2/

There is no new systemvmtemplate for 4.15.2, the 4.15.1
systemvmtemplate can be used from here:
https://download.cloudstack.org/systemvm/4.15/

Docs are not published yet but upgrade notes are similar to the one
below without the requirement of registering a new systemvmtemplate:
https://github.com/apache/cloudstack-documentation/tree/4.15/source/upgrading/upgrade

Regards.




 

Re: [Discussion] String libs

[Suresh Anaparti]

It's always good to move to the updated libraries, and I agree on upgrading to 
lang3 library (from lang).

We can continue use/improve our facade 'com.cloud.utils.StringUtils' for 
readability, custom utils from third party libs, this will be a single point of 
update whenever any util library is upgraded in future. 

Regards,
Suresh

On 10/09/21, 11:00 PM, "Gabriel Bräscher"  wrote:

I do understand that a facade adds great value in many situations.

However, I am afraid that this could escalate up to a point of us
maintaining multiple facades of well-known libraries that in the end
already offer us what we need.
Such libraries tend to be stable; as an example, lang3 was launched in 2011
and has been rock solid since then.
If we get into upgrading, at least in the "apache.commons.lang3" example,
wpiçd be a "find and replace" operation [see:
https://commons.apache.org/proper/commons-lang/article3_0.html].

I am inclined into adopting "apache.commons.lang3" and then upgrading all
occurrences of "apache.commons.lang" (as mentioned, "find and replace"
operation). But I would be OK in moving into a facade.
My main concern/goal is to adopt a pattern ASAP, and I would be +1 both
ways as long as we ensure a standard in the current and future codebase.

Em qua., 8 de set. de 2021 às 12:21, Daan Hoogland 
escreveu:

> Daniel et al,
> I've no preference and don't mind multiple dependencies when they supply
> overlapping features. I do want to keep 3rd party libraries in facade
> projects at all times. It keeps maintenance surface small and it is easier
> to see conflicts happening (a good reason to reduce dependencies btw, me
> contradicting me).
> Both your and Rohit's points make sense to me.
>
> On Wed, Sep 8, 2021 at 2:36 PM Nicolas Vazquez <
> nicolas.vazq...@shapeblue.com> wrote:
>
> > Hi Daniel,
> >
> > I don't have a preference either, but the work you are proposing on your
> > PR makes sense to me.
> >
> >
> > Regards,
> >
> > Nicolas Vazquez
> >
> > 
> > From: Rohit Yadav 
> > Sent: Wednesday, September 8, 2021 5:05 AM
> > To: dev@cloudstack.apache.org 
> > Subject: Re: [Discussion] String libs
> >
> > I don't have any specific inclination, I would use whatever becomes a
> > standard.
> >
> > However, I prefer the readability of a utility method that is readable
> and
> > easy to understand such as isNullOrEmpty (which suggests it's doing a
> null
> > check) versus isEmpty.
> >
> > I suppose a refactoring exercise can be done by picking whatever
> favourite
> > dependency community consensus is built for (if at all) and then write a
> > utility method in something like StringsUtil in cloud-utils and use it
> > throughout the codebase so in future if we want to move to something
> else -
> > all you do is replace your favourite dependency with something new only
> in
> > StringsUtils of cloud-utils.
> >
> > ... and update the cloudstack-checkstyle to enforce the new agreed upon
> > rule and also update -
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Coding+conventions
> >
> >
> > Regards.
> >
> > 
> > From: Daniel Augusto Veronezi Salvador 
> > Sent: Tuesday, September 7, 2021 04:37
> > To: dev@cloudstack.apache.org 
> > Subject: [Discussion] String libs
> >
> > Hi all,
> >
> > Currently, the main String libs we are using are "commons.lang" and
> > "commons.lang3" (either directly or by our facade, "com.cloud.utils"). 
We
> > have a current discussion about using them directly or via a facade 
(such
> > as "com.cloud.utils"); however, a third implementation has been added
> > (google.common.base), which adds more to the discussion. "commons.lang"
> > already implement all we need; therefore, adding a third one does not
> seem
> > to add/improve/help with anything, but adding more moving parts and
> > libraries that we need to watch out for (managing versions, checking for
> > security issues, and so on).
> >
> > I created a PR (https://github.com/apache/cloudstack/pull/5386) to
> > replace "google.common.base" with "commons.lang3". However, and as Daan
> > suggested too, I'd like to go forward and revisit this discussion to
> > standardize our code. To guide it, I'd like to start with what I think 
is
> > the main topic:
> >
> > - Should we use a facade to "commons.lang"? Which are the pros and cons,
> > according to your perspective?
> >
> > Best regards,
> > Daniel.
> >
> >
> >
> >
> >
> >
> >
>
> --
> Daan
>


 

Invitation to Register for the CloudStack Collaboration Conference

[Ivet Petrova]

Hi all,

As September arrived, we are in now all back to work. The CloudStack 
Collaboration Conference organisation is going as planned and I am happy to 
announce we have first sponsors of the event. Two reminders from me:
- May I ask you all to register for the event here: 
https://events.hubilo.com/cloudstack-collaboration-conference/register
- The CFP closes at September 20th, so if you still have not submitted a talk, 
you have 10 final days to do it.

If someone has ideas for the conference or has any questions, I will be happy 
to answer.

Enjoy the upcoming weekend!

Kind regards,


 

Re: For Advanced Zone

[Vivek Kumar]

Yes, you can create Advance Zone without having any actual public IP range. You 
can use your exiting LAN range and setup CloudStack. Then obviously you can 
only access from that network only. ( I hope this is for testing purpose or 
in-house deployment )


Vivek Kumar
Sr. Manager - Cloud & DevOps 
IndiQus Technologies
M +91 7503460090 
www.indiqus.com




> On 09-Sep-2021, at 6:12 PM, technologyrss.mail  
> wrote:
> 
> Hi,
> 
> I have one query like can I create Advanced Zone without public ip range only 
> LAN?
> 
> 
> ---
> Alamin
>