Re: [PR] Add hostname annotation to set loadbalancer ingress hostname [cloudstack-kubernetes-provider]

[via GitHub]

vishesh92 commented on PR #48:
URL: 
https://github.com/apache/cloudstack-kubernetes-provider/pull/48#issuecomment-2125262104

   @weizhouapache I am not able to reproduce the issue, but I can verify the 
functionality is working as expected. For why hostname is required as part of 
the loadbalancerStatus, check: 
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#loadbalanceringress-v1-core


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

CloudStack Collaboration Conference 2024 Registration

[Ivet Petrova]

Hi all,

A kind reminder that the registration for CloudStack Collaboration Conference 
2024 is open.
All committers and PMC members can register with the promo code for 100% 
discount below:
https://www.eventbrite.com/e/cloudstack-collaboration-conference-2024-tickets-879401903767

Code: CommitterFREE24

People who are not committers, can get the Super Early Bird discount.

Hint: Sponsors also have a discount code, so you might get in touch with them 
also :)
Best regards,


 

RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC networks

[Alex Mattioli]

Thanks for the input Wido,

> That said, you could also opt that you can specify BGP peers are zone level 
> and override them at network level if one prefers. Nothing specified at >the 
> network? The zone-level peers are used. If you do >specify them at the 
> network level those are used. Again, think about multihop.

That's exactly what I had in mind, the same way we set DNS for the zone but can 
specify at network level as well. This way we keep self-service intact for when 
end-users simply want a routed network that peers with whatever the provider 
has setup upstream but also give the ability to either peer with an user 
managed VNF upstream or an operator provided router.

I hope this way we can cater for most use cases, at least with a first simple 
implementation.

Will definitely keep multihop in mind.

Cheers,
Alex


 


-Original Message-
From: Wido den Hollander  
Sent: Monday, May 20, 2024 8:22 PM
To: dev@cloudstack.apache.org; Alex Mattioli ; 
us...@cloudstack.apache.org; adietr...@ussignal.com
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks



Op 20/05/2024 om 14:45 schreef Alex Mattioli:
> Hi Alex,
> 
> In this scenario:
> 
>> I think adding the ability to add network specific peers as mentioned in one 
>> of >your prior replies would still allow the level of control some operators 
>> (myself >included) may desire.
> 
> How do you propose network specific peers to be implemented?
> 

I do agree with Alex (Dietrich) that I think BGP peers should be configured per 
network. There is no guarantee that every VLAN/VNI
(VXLAN) ends up at the same pair of routers. Technically there is also no need 
to do so.

Let's say I have two VNI (VXLAN):

VNI 500:
Router 1: 192.168.153.1 / 2001:db8::153:1 Router 2: 192.168.153.2 / 
2001:db8::153:2

VNI 600:
Router 1: 192.168.155.1 / 2001:db8::155:1 Router 2: 192.168.155.2 / 
2001:db8::155:2

In these case you would say that the upstream BGP peers are .153.1/2,
.155.1/2 (and their IPv6 addresses). No need for BGP multihop.

Talking about multihop, I would make that optional, people might want to have 
two central BGP routers where each VR peers with (multihop) and those routers 
distribute the routes into the network again.

Per network you create you also provide the ASN range, but even better would be 
to refer to a pool. You can use one pool for your zone by referencing every 
network to the same pool are simply use multiple pools if your network requires 
so.

That said, you could also opt that you can specify BGP peers are peer level and 
override them at network level if one prefers. Nothing specified at the 
network? The zone-level peers are used. If you do specify them at the network 
level those are used. Again, think about multihop.

Wido

> Regards
> Alex
> 
> 
>   
> 
> 
> -Original Message-
> From: Dietrich, Alex 
> Sent: Monday, May 20, 2024 2:21 PM
> To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
> Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated 
> and VPC networks
> 
> Hi Alex,
> 
> This may be a difference in perspective in implementation of BGP at the 
> tenant level. I see the ability this would provide to seamlessly establishing 
> those peering relationships with minimal intervention (helping scalability).
> 
> I think adding the ability to add network specific peers as mentioned in one 
> of your prior replies would still allow the level of control some operators 
> (myself included) may desire.
> 
> Thanks,
> Alex
> 
> [photo]
> 
> Alex Dietrich
> Senior Network Engineer, US Signal
> 
> 616-233-5094  |  
> www.ussignal.com  |  
> adietr...@ussignal.com
> 
> 201 Ionia Ave SW, Grand Rapids, MI 
> 49503 ids,%20MI%2049503>
> 
> [linkedin]
> 
> [facebook]
> 
> [youtube]
> 
> IMPORTANT: The contents of this email are confidential. Information is 
> intended for the named recipient(s) only. If you have received this email by 
> mistake, please notify the sender immediately and do not disclose the 
> contents to anyone or make copies thereof.
> 
> [__tpx__]
> From: Alex Mattioli 
> Date: Monday, May 20, 2024 at 7:51 AM
> To: us...@cloudstack.apache.org , 
> dev@cloudstack.apache.org 
> Subject: RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated 
> and VPC networks EXTERNAL
> 
> Hi Alex,
> 
>> I am not convinced that specifying BGP peers at the zone level is a good 
>> idea given the impacts BGP can have on a given network. I would much rather 
>> see both peer and AS specification handled at the >network configuration, or 
>> another more specific level.
> 
> I don't see how else end users would be able to automatically create routed 
> networks without 

Re: [I] Implement persistent volume support [cloudstack-kubernetes-provider]

[via GitHub]

weizhouapache closed issue #14: Implement persistent volume support
URL: https://github.com/apache/cloudstack-kubernetes-provider/issues/14


-- 
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: [I] Support static public ip address as a Load balancer IP [cloudstack-kubernetes-provider]

[via GitHub]

weizhouapache commented on issue #51:
URL: 
https://github.com/apache/cloudstack-kubernetes-provider/issues/51#issuecomment-2124288747

   this could be implemented via annotation, for example 
`service.beta.kubernetes.io/cloudstack-load-balancer-external-ip`


-- 
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: [I] feat: Cluster API support [cloudstack-kubernetes-provider]

[via GitHub]

weizhouapache closed issue #37: feat: Cluster API support
URL: https://github.com/apache/cloudstack-kubernetes-provider/issues/37


-- 
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: Unable to download DevCloud image file

[Rohit Yadav]

Hi Lohit,

DevCloud isn't maintained or used anymore, the apache folder was removed long 
back.

You can try mbx https://github.com/shapeblue/mbx or Simulator based development 
(https://github.com/shapeblue/hackerbook/blob/main/2-dev.md#simulator-based-development)
 instead.



Regards.

 



From: Lohit S 
Sent: Wednesday, May 22, 2024 11:23
To: dev@cloudstack.apache.org 
Subject: Unable to download DevCloud image file

Hi I had tried to download the DevCloud image file from this URL  
https://people.apache.org/~bhaisaab/cloudstack/devcloud/devcloud2.ova

[image.png]
But it shows 404 error.

Re: [PR] Add hostname annotation to set loadbalancer ingress hostname [cloudstack-kubernetes-provider]

[via GitHub]

weizhouapache commented on PR #48:
URL: 
https://github.com/apache/cloudstack-kubernetes-provider/pull/48#issuecomment-2124138528

   > Did some manual testing. After this change, I have verified that the 
service created has external IP equal to hostname set in 
`service.beta.kubernetes.io/cloudstack-load-balancer-hostname`. And the same 
hostname is also set in the status of the service.
   
   cool, thanks @vishesh92 
   can you test ipvs mode if the issue can be reproduced and fixed by this 
change ?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [PR] Add hostname annotation to set loadbalancer ingress hostname [cloudstack-kubernetes-provider]

[via GitHub]

vishesh92 commented on PR #48:
URL: 
https://github.com/apache/cloudstack-kubernetes-provider/pull/48#issuecomment-2124115258

   Did some testing. After this change, I have verified that the service 
created has external IP equal to hostname set in 
`service.beta.kubernetes.io/cloudstack-load-balancer-hostname`. And the same 
hostname is also set in the status of the service.


-- 
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: [I] Unable to auto-scale Kubernetes cluster [cloudstack-kubernetes-provider]

[via GitHub]

weizhouapache commented on issue #52:
URL: 
https://github.com/apache/cloudstack-kubernetes-provider/issues/52#issuecomment-2124110440

   I notice @saffronjam used a regular user to deploy the CKS cluster, would it 
be related to the issue ?


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