[GitHub] [cloudstack-documentation] sureshanaparti commented on pull request #217: Added vmware disk provisioning types

[GitBox]

sureshanaparti commented on pull request #217:
URL: 
https://github.com/apache/cloudstack-documentation/pull/217#issuecomment-882373926


   Code PR (apache/cloudstack#4640) merged, merging the doc changes


-- 
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] sureshanaparti merged pull request #217: Added vmware disk provisioning types

[GitBox]

sureshanaparti merged pull request #217:
URL: https://github.com/apache/cloudstack-documentation/pull/217


   


-- 
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: IPV6 in Isolated/VPC networks

[Wido den Hollander]

Op 16-07-2021 om 21:46 schreef Kristaps Cudars:

Hi Wido,

Your proposal is to sacrifice ability to reassign IPv6 to instance, have 
internal domain prefix, and list/db in ACS what IPv6 has been assigned to what 
instance and go with RA and SLAAC. For route signaling to switch use BGP/OSPFv3 
or manual pre-creation.



You can still list the IPs which have been assigned. You'll know exactly 
what IPv6 address a VM has because of the prefix + MAC. Privacy 
Extensions need to be disabled in the VM.


This already works in CloudStack in Shared Networks in this way.

Using secondary IPs you can always have 'floating' IPv6 addressess.

Wido


Option with RA and managed flag that DHCPv6 is in use to support preset 
information and ability to create route information from ACS is not an option 
as DHCPv6 its failing?


On 2021/07/16 15:17:42, Wido den Hollander  wrote:



Op 16-07-2021 om 16:42 schreef Hean Seng:

Hi Wido,

In current setup,  each Cloudstack have own VR, so in this new  IPv6 subnet
allocation , each VR (which have Frr) will need to have peering with ISP
router (and either BGP or Static Route) , and there is 1000 Acocunts,  it
will 1000 BGP session with ISP router ,  Am I right for this ? or I
understand wrong .



Yes, that is correct. A /56 would also be sufficient or a /60 which is
enough to allocate a few /64 subnets.

1000 BGP connections isn't really a problem for a proper router at the
ISP. OSPF(v3) would be better, but as I said that's poorly supported.

The ISP could also install 1000 static routes, but that means that the
ISP's router needs to have those configured.

http://docs.frrouting.org/en/latest/ospf6d.html
(While looking up this URL I see that Frr recently put in a lot of work
in OSPFv3, seems better now)


I understand IPv6 is different then IPv4, and in IPv6 it suppose each
devices have own IP. It just how to realize in easy way.









On Fri, Jul 16, 2021 at 8:17 PM Wido den Hollander  wrote:




Op 16-07-2021 om 05:54 schreef Hean Seng:

Hi Wido,

My initial thought is not like this,  it is the /48 at ISP router, and

/64

subnet assign to AdvanceZoneVR,   AdvanceZoneVR responsible is
distribule IPv6 ip (from the assigned /64 sunet) to VM,  and not routing
the traffic,   in the VM that get the IPv6 IP will default route to ISP
router as gw.   It can may be a bridge over via Advancezone-VR.



How would you bridge this? That sounds like NAT?

IPv6 is meant to be routed. Not to be translated or bridged in any way.

The way a made the drawing is exactly how IPv6 should work in a VPC
environment.

Traffic flows through the VR where it can do firewalling of the traffic.


However, If do as the way described in the drawing, then i suppose will

be

another kind of virtual router going to introduce , to get hold the /48

in

this virtual router right ?



It can be the same VR. But keep in mind that IPv6 != IPv4.

The VR will get Frr as a new daemon which can talk BGP with the upper
network to route traffic.


After this,  The Advance Zone, NAT's  VR will peer with this new IPv6 VR
for getting the IPv6 /64 prefix ?



IPv4 will be behind NAT, but IPv6 will not be behind NAT.


If do in this way, then I guess  you just only need Static route, with
peering ip both end  as one /48 can have a lot of /64 on it.  And

hardware

budgeting for new IPv6-VR will become very important, as all traffic will
need to pass over it .



Routing or NAT is the same for the VR. You don't need a very beefy VR
for this.


It will be like

ISP Router  -- >  (new IPV6-VR )  > AdvanceZone-VR > VM

Relationship of (new IPv6 VR) and AdvanceZone-VR , may be considering on
OSPF instead of  BGP , otherwise few thousand of AdvanceZone-VR wil have
few thousand of BGP session. on new-IPv6-VR

Also, I suppose we cannot do ISP router. -->. Advancezone VR direct,   ,
otherwise ISP router will be full of /64 prefix route either on BGP( Many
BGP Session) , or  Many Static route .   If few thousand account, ti will
be few thousand of BGP session with ISP router or few thousand static

route

which  is not possible .






On Thu, Jul 15, 2021 at 10:47 PM Wido den Hollander 

wrote:



But you still need routing. See the attached PNG (and draw.io XML).

You need to route the /48 subnet TO the VR which can then route it to
the Virtual Networks behind the VR.

There is no other way then routing with either BGP or a Static route.

Wido

Op 15-07-2021 om 12:39 schreef Hean Seng:

Or explain like this :

1) Cloudstack generate list of /64 subnet from /48 that Network admin
assigned to Cloudstack
2) Cloudsack allocated the subnet (that generated from step1) to

Virtual

Router, one Virtual Router have one subniet /64
3) Virtual Router allocate single IPv6 (within the range of /64
allocated to VR)  to VM






On Thu, Jul 15, 2021 at 6:25 PM Hean Seng mailto:heans...@gmail.com>> wrote:

   Hi Wido,

   I think the /48 is at physical router as gateway , and subnet of

/64

   at VR of Cloudstack.   C

Re: IPV6 in Isolated/VPC networks

[Wido den Hollander]

Op 17-07-2021 om 06:28 schreef Hean Seng:

I think if doing this way ,  since you were to implement on peering ip
between vr and phsical router , then would need keep /56 or 48 at
Clodustack ?  We can only add /64 subnet to Cloudstack only (instead of
keep the /56 or 48 there).



We can have a /64 at CloudStack in which all VRs talk with the router of 
the ISP.


That is large enough as a interconnect subnet between the VRs and routers.

From there you can route /56, /48 or which size you want towards the VR.

From the interconnect /64 you can also grab IPs which you use for 
loadbalancing purposes over different VMs.




I  saw other software provider do is adding /64 subnet to their system,
and  after that allocate subnet to the VM (from the previous added list).

May be considering the OSPF if really on this.  It really a nightmare for
maintaining 1000 or few thousand of BGP session.   You can imagine your
Cisco Router list of few thousand BGP session there.



Yes, but I would suggest that both OSPFv3 and BGP should work. Not 
everybody will have 1000 accounts on their environment.


Even static routes should be supported.

Wido






On Fri, Jul 16, 2021 at 11:17 PM Wido den Hollander  wrote:




Op 16-07-2021 om 16:42 schreef Hean Seng:

Hi Wido,

In current setup,  each Cloudstack have own VR, so in this new  IPv6

subnet

allocation , each VR (which have Frr) will need to have peering with ISP
router (and either BGP or Static Route) , and there is 1000 Acocunts,  it
will 1000 BGP session with ISP router ,  Am I right for this ? or I
understand wrong .



Yes, that is correct. A /56 would also be sufficient or a /60 which is
enough to allocate a few /64 subnets.

1000 BGP connections isn't really a problem for a proper router at the
ISP. OSPF(v3) would be better, but as I said that's poorly supported.

The ISP could also install 1000 static routes, but that means that the
ISP's router needs to have those configured.

http://docs.frrouting.org/en/latest/ospf6d.html
(While looking up this URL I see that Frr recently put in a lot of work
in OSPFv3, seems better now)


I understand IPv6 is different then IPv4, and in IPv6 it suppose each
devices have own IP. It just how to realize in easy way.









On Fri, Jul 16, 2021 at 8:17 PM Wido den Hollander 

wrote:





Op 16-07-2021 om 05:54 schreef Hean Seng:

Hi Wido,

My initial thought is not like this,  it is the /48 at ISP router, and

/64

subnet assign to AdvanceZoneVR,   AdvanceZoneVR responsible is
distribule IPv6 ip (from the assigned /64 sunet) to VM,  and not

routing

the traffic,   in the VM that get the IPv6 IP will default route to ISP
router as gw.   It can may be a bridge over via Advancezone-VR.



How would you bridge this? That sounds like NAT?

IPv6 is meant to be routed. Not to be translated or bridged in any way.

The way a made the drawing is exactly how IPv6 should work in a VPC
environment.

Traffic flows through the VR where it can do firewalling of the traffic.


However, If do as the way described in the drawing, then i suppose will

be

another kind of virtual router going to introduce , to get hold the /48

in

this virtual router right ?



It can be the same VR. But keep in mind that IPv6 != IPv4.

The VR will get Frr as a new daemon which can talk BGP with the upper
network to route traffic.


After this,  The Advance Zone, NAT's  VR will peer with this new IPv6

VR

for getting the IPv6 /64 prefix ?



IPv4 will be behind NAT, but IPv6 will not be behind NAT.


If do in this way, then I guess  you just only need Static route, with
peering ip both end  as one /48 can have a lot of /64 on it.  And

hardware

budgeting for new IPv6-VR will become very important, as all traffic

will

need to pass over it .



Routing or NAT is the same for the VR. You don't need a very beefy VR
for this.


It will be like

ISP Router  -- >  (new IPV6-VR )  > AdvanceZone-VR > VM

Relationship of (new IPv6 VR) and AdvanceZone-VR , may be considering

on

OSPF instead of  BGP , otherwise few thousand of AdvanceZone-VR wil

have

few thousand of BGP session. on new-IPv6-VR

Also, I suppose we cannot do ISP router. -->. Advancezone VR direct,

  ,

otherwise ISP router will be full of /64 prefix route either on BGP(

Many

BGP Session) , or  Many Static route .   If few thousand account, ti

will

be few thousand of BGP session with ISP router or few thousand static

route

which  is not possible .






On Thu, Jul 15, 2021 at 10:47 PM Wido den Hollander 

wrote:



But you still need routing. See the attached PNG (and draw.io XML).

You need to route the /48 subnet TO the VR which can then route it to
the Virtual Networks behind the VR.

There is no other way then routing with either BGP or a Static route.

Wido

Op 15-07-2021 om 12:39 schreef Hean Seng:

Or explain like this :

1) Cloudstack generate list of /64 subnet from /48 that Network admin
assigned to Cloudstack
2) Cloudsack allocated the subnet (that generated from s

[GitHub] [cloudstack-documentation] wido commented on pull request #231: network: note on shared networks with IPv6

[GitBox]

wido commented on pull request #231:
URL: 
https://github.com/apache/cloudstack-documentation/pull/231#issuecomment-882406619


   That is correct. IPv6-only networks are not yet supported with CloudStack.
   
   IPv4 is always needed at the moment. For example cloud-init requires it.


-- 
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: Triage Permission

[Darrin Hüsselmann]

Hi Guys,

May I please have the triage permission on the cloudstack-documentation 
repo for Spaceman1984?

Cheers,
Darrin


From: David Jumani 
Sent: Tuesday, October 20, 2020 10:44 AM
To: dev@cloudstack.apache.org 
Subject: Re: Triage Permission

Hi All,

A big thanks to everyone who supported this idea. It's working out quite well 
allowing community members contribute further.
I'd like to suggest that others who would like the triage permission to boldly 
request it. It requires community / PMC approval followed by an infra ticket 
raised on the apache Jira, similar to this 
https://issues.apache.org/jira/browse/INFRA-20855
Request and approval can be gotten by shooting out a mail mentioning your 
GitHub handle in the mailing list, preferably as part of this mail chain to 
make it easier to pass on a consolidated to the infrastructure team to reduce 
complications and to speed up the process.

Thanks and happy Triaging!
David

From: Paul Angus 
Sent: Monday, September 21, 2020 3:11 PM
To: dev@cloudstack.apache.org 
Subject: RE: Triage Permission

Speaking with my Apache Member's hat on, the Apache ethos is to try to 'police' 
things through social controls rather than technically.

This exact topic has been discussed at Members level, and this (above) is the 
current consensus.  [sorry I'm not at liberty to share Member's email chains].  
However, this hasn't been ratified as an 'official' position, so infra are 
understandably playing it safe and only giving permissions to named people who 
have asked and been granted permission by the relevant project.

You can see this being actioned by infra here for another project:
https://issues.apache.org/jira/browse/INFRA-20853?jql=project%20%3D%20INFRA%20AND%20text%20~%20%22triage%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

[CloudStack hat back on]

I am massive +1 on removing a barrier to people's participation.  And whatever 
controls are eventually deemed appropriate, I'm petty Zen about.


Paul

paul.an...@shapeblue.com
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue




david.jum...@shapeblue.com
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue




 


-Original Message-
From: Daan Hoogland 
Sent: 21 September 2020 10:18
To: dev 
Subject: Re: Triage Permission

In general, I'm fine with giving karma to any user on request for those 
abilities. I don't think a trial for a limited set of users makes sense.
And I don't think the PMC or committers will be able to control and revert on 
abuse. we'll need infra for both awarding and retracting.

On Mon, Sep 21, 2020 at 11:05 AM David Jumani 
wrote:

> Hi,
>
> While working with the CloudStack repository, logging issues and
> contributing, I've noticed a long turnaround time for issues and pull
> requests. I guess that it might have to do with the fact that only
> committers can modify and manage them.
> To alleviate this, I'd like to propose the granting the Triage
> permission<
> https://docs.github.com/en/github/setting-up-and-managing-organization
> s-and-teams/repository-permission-levels-for-an-organization>
> on GitHub to some of the active members of our community.
>
>
> They can manage issues / pull requests, and add bots to automate
> mundane tasks, without having write access to the repository.
> This would be a great stepping stone for growing the community,
> reducing the workload on Committers and would help in keeping
> community members and developers engaged in the project!
>
> As a trial, I'd propose the following users be granted it and based on
> the result / feedback we can continue to add more members @shwstppr
> @davidjumani @Pearl1594 @ACSGitBot @Spaceman1984 @sureshanaparti
> @vladimirpetrov
>
> Thanks,
> David
>
>
> david.jum...@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
> @shapeblue
>
>
>
>

--
Daan

Re: Triage Permission

[Daan Hoogland]

yes you may @Spaceman1984 (binding?) please create an infra ticket for it.

On Mon, Jul 19, 2021 at 11:59 AM Darrin Hüsselmann <
darrin.husselm...@shapeblue.com> wrote:

> Hi Guys,
>
> May I please have the triage permission on the cloudstack-documentation
> repo for Spaceman1984?
>
> Cheers,
> Darrin

Re: Triage Permission

[Darrin Hüsselmann]

Thanks Daan.

Regards
Darrin

From: Daan Hoogland 
Sent: Monday, July 19, 2021 12:12 PM
To: dev 
Subject: Re: Triage Permission

yes you may @Spaceman1984 (binding?) please create an infra ticket for it.

On Mon, Jul 19, 2021 at 11:59 AM Darrin Hüsselmann <
darrin.husselm...@shapeblue.com> wrote:

> Hi Guys,
>
> May I please have the triage permission on the cloudstack-documentation
> repo for Spaceman1984?
>
> Cheers,
> Darrin

 

[GitHub] [cloudstack-documentation] shwstppr commented on a change in pull request #223: Host ha and multiple management server internal load balancing

[GitBox]

shwstppr commented on a change in pull request #223:
URL: 
https://github.com/apache/cloudstack-documentation/pull/223#discussion_r672205178



##
File path: source/adminguide/reliability.rst
##
@@ -126,6 +183,107 @@ that you want to dedicate to HA-enabled VMs.
a crash.
 
 
+HA-Enabled Hosts
+
+
+The user can specify a host as HA-enabled, In the event of a host 
+failure, attemps will be made to recover the failed host by first 
+issuing some OOBM commands. If the host recovery fails the host will be
+fenced and placed into maintenance mode. To restore the host to normal 
+operation, manual intervention would then be required.
+
+Out of band management is a requirement of HA-Enabled hosts and has to be 
+confiured on all intended participating hosts.
+(see `“Out of band management” `_).
+
+Host-HA has granular configuration on a host/cluster/zone level. In a large 
+environment, some hosts from a cluster can be HA-enabled and some not, 
+
+Host-HA uses a state machine design to manage the operations of recovering
+and fencing hosts. The current status of a host is reported when quering a 
+specific host.
+
+Timely health investigations are done on HA-Enabled hosts to monitor for
+any failures. Specific thersholds can be set for failed investigations,

Review comment:
   ```suggestion
   any failures. Specific thresholds can be set for failed investigations,
   ```




-- 
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 #223: Host ha and multiple management server internal load balancing

[GitBox]

andrijapanicsb commented on pull request #223:
URL: 
https://github.com/apache/cloudstack-documentation/pull/223#issuecomment-882492162


   Will do after my vacation pls, yes. On my to-do list (among other doc update 
reviews) 


-- 
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: [PROPOSE] RM for 4.16

[Nicolas Vazquez]

Thank you for your support. Please find the proposed timeline below for 
discussion:

4.16.0.0 release - target for end Q3 2021
(6 weeks) Ongoing - End of August 2021: accept all bugs, issues, improvements 
allowed in LTS [1]
(2 weeks) Mid-September 2021: accept only critical/blocker fixes
(1 week) Stabilise 4.16 branch, accept only blocker issues if any
End of September 2021: Cut 4.16.0.0 RC1 and further RCs if necessary, 
start/conclude vote, and finish release work

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS

Any thoughts/objections?


Regards,

Nicolas Vazquez



 

From: Nicolas Vazquez
Sent: Wednesday, June 23, 2021 10:32 AM
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: [PROPOSE] RM for 4.16

Dear All,

I’d like to put myself forward as the release manager for 4.16.0.0 and my 
colleagues Suresh Anaparti and Rohit Yadav as the co-RMs.

For 4.16.0.0 my colleague Suresh will assist me during the process for 
reviewing/testing/merging the PRs, others will be welcome to support as well.

I propose we have a window of at least 8 weeks (2 months) to allow community 
and users to test and report issues and aim to cut RC1 in Q3 2021 (September or 
onwards). I'll propose timeline and details by the end of July.

I hope to have your support. Any thoughts, feedback, comments? Thanks.


Regards,

Nicolas Vazquez

RE: Triage Permission

[Paul Angus]

+1

Don't forget to include a link in Pony Mail [1] of the 'agreement' to the 
request

[1] https://lists.apache.org/list.html?dev@cloudstack.apache.org


Kind regards

Paul Angus

-Original Message-
From: Daan Hoogland  
Sent: Monday, July 19, 2021 11:12 AM
To: dev 
Subject: Re: Triage Permission

yes you may @Spaceman1984 (binding?) please create an infra ticket for it.

On Mon, Jul 19, 2021 at 11:59 AM Darrin Hüsselmann < 
darrin.husselm...@shapeblue.com> wrote:

> Hi Guys,
>
> May I please have the triage permission on the 
> cloudstack-documentation 
> repo for Spaceman1984?
>
> Cheers,
> Darrin

Re: IPV6 in Isolated/VPC networks

[Kristaps Cudars]

Hi Wido,

I assume that flouting ip will not work grate with ingress/egress acl on VR.

>From regular ACS user perspective:
I have Instance with dualstack its running web app on 443. 
I want to swap instances for whatever reason.
In case of IPv4 change d-nat rule.
In case of IPv6 if flouting IP was not created upfront he will need to change 
dns entry that usually has 24h ttl. Inconvenience degradation in experience.

>From ACS admin perspective:
I don’t want to have these tickets in helpdesk.
You needed to create another flouting IP that it would be seamless- will not 
work as answer.


On 2021/07/19 09:05:54, Wido den Hollander  wrote: 
> 
> 
> Op 16-07-2021 om 21:46 schreef Kristaps Cudars:
> > Hi Wido,
> > 
> > Your proposal is to sacrifice ability to reassign IPv6 to instance, have 
> > internal domain prefix, and list/db in ACS what IPv6 has been assigned to 
> > what instance and go with RA and SLAAC. For route signaling to switch use 
> > BGP/OSPFv3 or manual pre-creation.
> > 
> 
> You can still list the IPs which have been assigned. You'll know exactly 
> what IPv6 address a VM has because of the prefix + MAC. Privacy 
> Extensions need to be disabled in the VM.
> 
> This already works in CloudStack in Shared Networks in this way.
> 
> Using secondary IPs you can always have 'floating' IPv6 addressess.
> 
> Wido
> 
> > Option with RA and managed flag that DHCPv6 is in use to support preset 
> > information and ability to create route information from ACS is not an 
> > option as DHCPv6 its failing?
> > 
> > 
> > On 2021/07/16 15:17:42, Wido den Hollander  wrote:
> >>
> >>
> >> Op 16-07-2021 om 16:42 schreef Hean Seng:
> >>> Hi Wido,
> >>>
> >>> In current setup,  each Cloudstack have own VR, so in this new  IPv6 
> >>> subnet
> >>> allocation , each VR (which have Frr) will need to have peering with ISP
> >>> router (and either BGP or Static Route) , and there is 1000 Acocunts,  it
> >>> will 1000 BGP session with ISP router ,  Am I right for this ? or I
> >>> understand wrong .
> >>>
> >>
> >> Yes, that is correct. A /56 would also be sufficient or a /60 which is
> >> enough to allocate a few /64 subnets.
> >>
> >> 1000 BGP connections isn't really a problem for a proper router at the
> >> ISP. OSPF(v3) would be better, but as I said that's poorly supported.
> >>
> >> The ISP could also install 1000 static routes, but that means that the
> >> ISP's router needs to have those configured.
> >>
> >> http://docs.frrouting.org/en/latest/ospf6d.html
> >> (While looking up this URL I see that Frr recently put in a lot of work
> >> in OSPFv3, seems better now)
> >>
> >>> I understand IPv6 is different then IPv4, and in IPv6 it suppose each
> >>> devices have own IP. It just how to realize in easy way.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Jul 16, 2021 at 8:17 PM Wido den Hollander  wrote:
> >>>
> 
> 
>  Op 16-07-2021 om 05:54 schreef Hean Seng:
> > Hi Wido,
> >
> > My initial thought is not like this,  it is the /48 at ISP router, and
>  /64
> > subnet assign to AdvanceZoneVR,   AdvanceZoneVR responsible is
> > distribule IPv6 ip (from the assigned /64 sunet) to VM,  and not routing
> > the traffic,   in the VM that get the IPv6 IP will default route to ISP
> > router as gw.   It can may be a bridge over via Advancezone-VR.
> >
> 
>  How would you bridge this? That sounds like NAT?
> 
>  IPv6 is meant to be routed. Not to be translated or bridged in any way.
> 
>  The way a made the drawing is exactly how IPv6 should work in a VPC
>  environment.
> 
>  Traffic flows through the VR where it can do firewalling of the traffic.
> 
> > However, If do as the way described in the drawing, then i suppose will
>  be
> > another kind of virtual router going to introduce , to get hold the /48
>  in
> > this virtual router right ?
> >
> 
>  It can be the same VR. But keep in mind that IPv6 != IPv4.
> 
>  The VR will get Frr as a new daemon which can talk BGP with the upper
>  network to route traffic.
> 
> > After this,  The Advance Zone, NAT's  VR will peer with this new IPv6 VR
> > for getting the IPv6 /64 prefix ?
> >
> 
>  IPv4 will be behind NAT, but IPv6 will not be behind NAT.
> 
> > If do in this way, then I guess  you just only need Static route, with
> > peering ip both end  as one /48 can have a lot of /64 on it.  And
>  hardware
> > budgeting for new IPv6-VR will become very important, as all traffic 
> > will
> > need to pass over it .
> >
> 
>  Routing or NAT is the same for the VR. You don't need a very beefy VR
>  for this.
> 
> > It will be like
> >
> > ISP Router  -- >  (new IPV6-VR )  > AdvanceZone-VR > VM
> >
> > Relationship of (new IPv6 VR) and AdvanceZone-VR , may be considering on
> > OSPF instead of  BGP , otherwise few thous

Re: IPV6 in Isolated/VPC networks

[Kristaps Cudars]

Hi Wido,

In context of size I would recommend sticking with RIPE guidelines.
https://www.ripe.net/publications/docs/ripe-690

Reminder:
/56 256 LAN segments
/48 65,536 LAN segments

Maybe it will sound counter intuitive but I’m also not excited about OSPFv3 or 
BGP on VR.
As in our case it will be around 300 to 500 potential problems where networking 
department must be involved if it fails.

One of the things I like about VR “isolated/vpc” now is that its stateless, all 
things that it must know coms from ACS. There is little to non decision making 
on it. By introducing dynamic routing it will start making decisions- important 
decisions that will bypass ACS.

Now when you reboot VR you do it without hesitation and doubt that it will not 
work. With dynamics routing you probably will need to confirm that routing is 
up and its working as it was working before reboot. Also have some one 
available that can actually fix dynamic routing problems if they appear. You 
will need to handle dynamic routing problems as daily operations.

I’m not saying no to OSPFv3 and BGP in my opinion manual mode also should be 
treated as first class citizen. 

On 2021/07/19 09:08:10, Wido den Hollander  wrote: 
> 
> 
> Op 17-07-2021 om 06:28 schreef Hean Seng:
> > I think if doing this way ,  since you were to implement on peering ip
> > between vr and phsical router , then would need keep /56 or 48 at
> > Clodustack ?  We can only add /64 subnet to Cloudstack only (instead of
> > keep the /56 or 48 there).
> > 
> 
> We can have a /64 at CloudStack in which all VRs talk with the router of 
> the ISP.
> 
> That is large enough as a interconnect subnet between the VRs and routers.
> 
>  From there you can route /56, /48 or which size you want towards the VR.
> 
>  From the interconnect /64 you can also grab IPs which you use for 
> loadbalancing purposes over different VMs.
> 
> 
> > I  saw other software provider do is adding /64 subnet to their system,
> > and  after that allocate subnet to the VM (from the previous added list).
> > 
> > May be considering the OSPF if really on this.  It really a nightmare for
> > maintaining 1000 or few thousand of BGP session.   You can imagine your
> > Cisco Router list of few thousand BGP session there.
> > 
> 
> Yes, but I would suggest that both OSPFv3 and BGP should work. Not 
> everybody will have 1000 accounts on their environment.
> 
> Even static routes should be supported.
> 
> Wido
> 
> > 
> > 
> > 
> > 
> > On Fri, Jul 16, 2021 at 11:17 PM Wido den Hollander  wrote:
> > 
> >>
> >>
> >> Op 16-07-2021 om 16:42 schreef Hean Seng:
> >>> Hi Wido,
> >>>
> >>> In current setup,  each Cloudstack have own VR, so in this new  IPv6
> >> subnet
> >>> allocation , each VR (which have Frr) will need to have peering with ISP
> >>> router (and either BGP or Static Route) , and there is 1000 Acocunts,  it
> >>> will 1000 BGP session with ISP router ,  Am I right for this ? or I
> >>> understand wrong .
> >>>
> >>
> >> Yes, that is correct. A /56 would also be sufficient or a /60 which is
> >> enough to allocate a few /64 subnets.
> >>
> >> 1000 BGP connections isn't really a problem for a proper router at the
> >> ISP. OSPF(v3) would be better, but as I said that's poorly supported.
> >>
> >> The ISP could also install 1000 static routes, but that means that the
> >> ISP's router needs to have those configured.
> >>
> >> http://docs.frrouting.org/en/latest/ospf6d.html
> >> (While looking up this URL I see that Frr recently put in a lot of work
> >> in OSPFv3, seems better now)
> >>
> >>> I understand IPv6 is different then IPv4, and in IPv6 it suppose each
> >>> devices have own IP. It just how to realize in easy way.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Jul 16, 2021 at 8:17 PM Wido den Hollander 
> >> wrote:
> >>>
> 
> 
>  Op 16-07-2021 om 05:54 schreef Hean Seng:
> > Hi Wido,
> >
> > My initial thought is not like this,  it is the /48 at ISP router, and
>  /64
> > subnet assign to AdvanceZoneVR,   AdvanceZoneVR responsible is
> > distribule IPv6 ip (from the assigned /64 sunet) to VM,  and not
> >> routing
> > the traffic,   in the VM that get the IPv6 IP will default route to ISP
> > router as gw.   It can may be a bridge over via Advancezone-VR.
> >
> 
>  How would you bridge this? That sounds like NAT?
> 
>  IPv6 is meant to be routed. Not to be translated or bridged in any way.
> 
>  The way a made the drawing is exactly how IPv6 should work in a VPC
>  environment.
> 
>  Traffic flows through the VR where it can do firewalling of the traffic.
> 
> > However, If do as the way described in the drawing, then i suppose will
>  be
> > another kind of virtual router going to introduce , to get hold the /48
>  in
> > this virtual router right ?
> >
> 
>  It can be the same VR. But keep in mind that IPv6 != IPv4.
> 
>  The VR will 

[GitHub] [cloudstack-cloudmonkey] Pearl1594 opened a new pull request #85: Use local profile if present

[GitBox]

Pearl1594 opened a new pull request #85:
URL: https://github.com/apache/cloudstack-cloudmonkey/pull/85


   Fixes: https://github.com/apache/cloudstack-cloudmonkey/issues/69
   Use local profile, if present (in case of older versions of cloudmonkey) 
   
    Test Performed:
   ```
go run cmk.go -p local
   Apache CloudStack 🐵 CloudMonkey 6.1.0
   Report issues: https://github.com/apache/cloudstack-cloudmonkey/issues
   
   (local) 🐱 >  
   ```
   
   And the corresponding cmk config has only local profile:
   ```
   cat .cmk/config
   prompt = 🐱
   asyncblock = true
   timeout= 1800
   output = json
   verifycert = true
   profile= local
   
   [local]
   url   = http://localhost:8080/client/api
   username  = admin
   password  = password
   domain= /
   apikey= 
   secretkey = 
   
   ```


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