Re: [Discussion] String libs
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 >
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.
[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: 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 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) > > * Enable IPv6 on systemvms (specifically SSVM and CPVM) by default > if zone has a IPv6 address block allocated/assigned for use for systemvms > (this was mainly thought for VRs, but why no ssvm and cpvms too - any cons > of this?) > > * > > > > Regards. > > > > > > From: Rohit Yadav > > Sent: Thursday, August 19, 2021 15:45 > > To: dev@cloudstack.apache.org > > Subject: Re: IPV6 in
RE: IPV6 in Isolated/VPC networks
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 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) > * Enable IPv6 on systemvms (specifically SSVM and CPVM) by default if > zone has a IPv6 address block allocated/assigned for use for systemvms (this > was mainly thought for VRs, but why no ssvm and cpvms too - any cons of this?) > * > > Regards. > > > From: Rohit Yadav > Sent: Thursday, August 19, 2021 15:45 > To: dev@cloudstack.apache.org > Subject: Re: IPV6 in Isolated/VPC networks > > Hi all, > > I've taken feedback from this thread and wrote this design doc: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+Support+in > +Isolated+Network+and+VPC+with+Static+Routing > > Kindly review and advise if I missed anything or anything that needs to be > changed/updated. You may comment on the wiki directly too. > > Kindly suggest your
Re: CVE-2021-40346 (haproxy 2.x)
Thanks for the heads up Gregor, we'll rebuild systemvmtemplates for 4.16/main branch. Regards. From: Wei ZHOU Sent: Friday, September 10, 2021 18:28 To: dev@cloudstack.apache.org Subject: Re: CVE-2021-40346 (haproxy 2.x) Hi Greg, Thanks for the info. It is good that our systemvm templates are not impacted. CloudStack 4.15.1 systemvm template uses haproxy 1.8.19. CloudStack 4.16 systemvm template uses haproxy 2.2.9, but it is not officially released yet. -Wei On Fri, 10 Sept 2021 at 14:22, Riepl, Gregor (SWISS TXT) < gregor.ri...@swisstxt.ch> wrote: > Hi, > > Are you aware of https://nvd.nist.gov/vuln/detail/CVE-2021-40346 ? > Haproxy 2.0 through 2.5 has a vulnerability that can be exploited to > smuggle requests to backend systems. > > If the CloudStack VR is using one of these versions, it should be patched > everywhere ASAP. > > Regards, > Greg >
Re: [Discussion] Release Cycle
Hi all, Looks like we are moving forward and raising important points. Summing some key factors pointed in this discussion: - CloudStack is getting stable. - From the developers' side, the costs of releasing and maintaining an LTS are high. There is a "human" limitation in terms of how many releases the community can spin per year. - From the users' perspective, upgrading CloudStack infrastructures has its costs (Pierre also raised this and I totally agree). Many users end up upgrading their infra once a year (or once in 2 years). With that said, I would like to propose the following: 1. The project compromises in having 1 LTS per year, and eventually one 1 Regular. For that, a roadmap would be defined to guide the community through the year. 2. It should be no problem to have an "extra" release in a specific year. For that, a volunteer would propose such release raising the reasons behind it. Each "extra" release proposed would require a VOTE. Please let me know if the proposed points look good. If that's the case, then I will move forward to present a draft to be added to the wiki. If you think it would be better to kick a separate VOTE thread for it I can also raise it. Regards, Gabriel. Em qui., 9 de set. de 2021 às 07:52, Rohit Yadav escreveu: > Hi Gabriel, > > Agree with your conclusion - let's go with (at least) two major releases > in a year. > > I would add that there's no real logistical difference between a regular > vs LTS release, so for example someone could propose and work on a > "regular" release but it can become LTS if there are > volunteers/contributors who want to maintain a release. That said - by all > means just go ahead, propose and do release management! > > ps. And on a ".0" being stable I suppose it is somewhat stable in last few > years as we've got our CI/CD systems quite robust for a subset of > smoketests, all our releases thankfully at least go through a round of > smoketests across three hypervisors - that is not to say no release has no > reported issues (in fact they all do ). > > > Regards. > > > From: Gabriel Bräscher > Sent: Wednesday, September 8, 2021 18:39 > To: dev > Subject: Re: [Discussion] Release Cycle > > Thanks all for helping with the discussion. > > Yes, Rohit. I need to answer a few pings, sorry for the delay :-) > I totally agree with you and Paul, the costs of releasing are high, > especially for the release manager(s) which dedicates a lot of energy and > time to it. > This is one of the reasons behind this discussion; when we formalize and > document the release pace it is easier to plan a year knowing how things > will roll out, from the perspective of RMs, devs, or users. > > Going in the same direction as Rohit, I also agree that we are getting each > year stabler, maybe one LTS per year is better than the current pace of 2. > Therefore, I would propose 1 LTS and 1 Regular per year; I see it as a good > balance between stability and agility. > Additionally, most users do not upgrade from an LTS to another twice a > year, it takes time to plan and execute such tasks (and they always have > some risks). > From my experience, an LTS per year would perfectly match the needs of most > users. > > I do understand that many adopt ".0" as an "unstable"/"Regular" LTS. > However, I don't think this is the best approach. > Additionally, many users do not see a ".0" LTS (which is how we brand in > documentation, website, and release announcement) as a "Regular". > I think that LTS, regardless of being the first spin or not, should be as > stable as it can get. Having a Regular release could avoid the idea of ".0" > not being a stable release. > > As an example, I've seen 4.12.0.0 (Regular) running in production with no > issues regarding stability, while also bringing features that otherwise > would be available only in 3-5 months. > It was as stable as many ".0" LTS and I do believe that it also provided > crucial feedback for the 4.13.0.0 (LTS). > > Regards, > Gabriel. > > Em qua., 8 de set. de 2021 às 04:58, Rohit Yadav < > rohit.ya...@shapeblue.com> > escreveu: > > > Gabriel, all, > > > > I suppose it depends, there's no right answer just trade-offs. Here's my > > lengthy brain dump; > > > > 0. our LTS definition is really to tag a set of releases and show intent > > that they are "stable" and will be supported and get maintenance > releases. > > We don't really do LTS releases like larger projects whose support lasts > > multi-years (3-5yrs, sometimes 7-10yrs). Fundamentally all our major .0 > > releases are just regular releases, with really the minor/maintenance > > releases making them stable or LTS-que. I like what Pierre-Luc is > > suggesting, but then say a 2-year "LTS" release means users don't get to > > consume features as they would only use "LTS" releases and wait for 2 > years > > which may not be acceptable trade-off. > > > > 1. so if we leave what makes a release regular vs LTS for a moment, the > >
Re: CVE-2021-40346 (haproxy 2.x)
Hi Greg, Thanks for the info. It is good that our systemvm templates are not impacted. CloudStack 4.15.1 systemvm template uses haproxy 1.8.19. CloudStack 4.16 systemvm template uses haproxy 2.2.9, but it is not officially released yet. -Wei On Fri, 10 Sept 2021 at 14:22, Riepl, Gregor (SWISS TXT) < gregor.ri...@swisstxt.ch> wrote: > Hi, > > Are you aware of https://nvd.nist.gov/vuln/detail/CVE-2021-40346 ? > Haproxy 2.0 through 2.5 has a vulnerability that can be exploited to > smuggle requests to backend systems. > > If the CloudStack VR is using one of these versions, it should be patched > everywhere ASAP. > > Regards, > Greg >
CVE-2021-40346 (haproxy 2.x)
Hi, Are you aware of https://nvd.nist.gov/vuln/detail/CVE-2021-40346 ? Haproxy 2.0 through 2.5 has a vulnerability that can be exploited to smuggle requests to backend systems. If the CloudStack VR is using one of these versions, it should be patched everywhere ASAP. Regards, Greg
Re: [VOTE] Apache CloudStack 4.15.2.0 (RC1)
All, We've found a UI blocker that fails login for non-admin accounts. I'll cut another RC shortly as soon as we've a working fix. Due to this I'm closing this vote thread. Regards. From: Daan Hoogland Sent: Wednesday, September 8, 2021 21:01 To: dev Cc: users Subject: Re: [VOTE] Apache CloudStack 4.15.2.0 (RC1) signing correct, archive contents sane (no further testing done) +1 (binding) On Tue, Sep 7, 2021 at 2:53 PM Rohit Yadav wrote: > 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-RC20210907T1815 > Commit: 5ba2867598ecf7ce16807e78d5033c342a2a52d7 > > 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 13 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-RC1/ > > 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. > -- Daan
[GitHub] [cloudstack-documentation] andrijapanicsb commented on pull request #226: Quick install guide update
andrijapanicsb commented on pull request #226: URL: https://github.com/apache/cloudstack-documentation/pull/226#issuecomment-916811407 @wido @GabrielBrascher @weizhouapache @kiwiflyer @rhtyd @davidjumani @Pearl1594 @shwstppr @sureshanaparti @borisstoyanov @DennisKonrad @harikrishna-patnala @mike-tutkowski @nathanejohnson @nvazquez - feel free to review (high-level) the changes to the Quick Install Guide - - it's NO MORE with BASIC zone/security groups - it's now an advanced zone, where one can spin everything on a single server/VM/virtualbox (as before), on their (home) network - and the same network is used for both the Pod (i.e. lower part of CIDR range) and for the Public (upper part of CIDR range) - a bit "crazy" setup, but perfectly valid for test/demo purposes on one's laptop/server - this way they can taste the Advanced Zone - AND can access (TCP access) Public side of VR/CPVM/SSVM to test all features of ACS, etc - there are numerous warnings that this network setup is purely for demo/test and NOT for production, etc. I've been running through this guide 2 times, verified every step (blindly following it) - anyone else is also welcome to quickly test, especially that you can spin i.e. VirtualBox with a VM and use it for ACS (this is what I did during my testing) -- 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-documentation] blueorangutan commented on pull request #226: Quick install guide update
blueorangutan commented on pull request #226: URL: https://github.com/apache/cloudstack-documentation/pull/226#issuecomment-916782095 Doc build preview: http://qa.cloudstack.cloud/docs/WIP-PROOFING/pr/226. (SL-JID 142) -- 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-documentation] blueorangutan commented on pull request #226: Quick install guide update
blueorangutan commented on pull request #226: URL: https://github.com/apache/cloudstack-documentation/pull/226#issuecomment-916781671 @andrijapanicsb a Jenkins job has been kicked to build the document. I'll keep you posted as I make progress. -- 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-documentation] blueorangutan removed a comment on pull request #226: Quick install guide update
blueorangutan removed a comment on pull request #226: URL: https://github.com/apache/cloudstack-documentation/pull/226#issuecomment-916763318 -- 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-documentation] andrijapanicsb commented on pull request #226: Quick install guide update
andrijapanicsb commented on pull request #226: URL: https://github.com/apache/cloudstack-documentation/pull/226#issuecomment-916780510 @blueorangutan docbuild -- 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-documentation] andrijapanicsb removed a comment on pull request #226: Quick install guide update
andrijapanicsb removed a comment on pull request #226: URL: https://github.com/apache/cloudstack-documentation/pull/226#issuecomment-916763082 @blueorangutan docbuild -- 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-documentation] blueorangutan commented on pull request #226: Quick install guide update
blueorangutan commented on pull request #226: URL: https://github.com/apache/cloudstack-documentation/pull/226#issuecomment-916763894 Doc build preview: http://qa.cloudstack.cloud/docs/WIP-PROOFING/pr/226. (SL-JID 141) -- 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-documentation] blueorangutan commented on pull request #226: Quick install guide update
blueorangutan commented on pull request #226: URL: https://github.com/apache/cloudstack-documentation/pull/226#issuecomment-916763318 @andrijapanicsb a Jenkins job has been kicked to build the document. I'll keep you posted as I make progress. -- 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-documentation] andrijapanicsb commented on pull request #226: Quick install guide update
andrijapanicsb commented on pull request #226: URL: https://github.com/apache/cloudstack-documentation/pull/226#issuecomment-916763082 @blueorangutan docbuild -- 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-documentation] andrijapanicsb removed a comment on pull request #226: Quick install guide update
andrijapanicsb removed a comment on pull request #226: URL: https://github.com/apache/cloudstack-documentation/pull/226#issuecomment-888398807 -- 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
