New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limit length of load balancer names #6812
Comments
Thanks for filing this Alex. My suggestion would be to use a simple UID, as per utils.NewUID(). We'll need to store the mapping from {clustername, namespace, servicename} -> UID somewhere stable like etcd. Using anything based directly on {cluster, namespace, name}, for example a stable hash of each, has the problem that the aforementioned tuple is not unique over time. This raises the possibility of e.g. the following scenario:
|
Assigning to Chao Xu, as this makes for a good starter bug. |
Hmmmm.... can't seem to assign to caesarxuchao yet. Not sure why. |
He has to have write privileges on the repo before issues/PRs can be assigned to him. |
But we have many contributors with issues assigned to them that are not in the kubernetes-write group (that only has 48 members). I must be missing something. How do I grant him write privileges on the repo? |
We do? That's not how I understand it to work: https://help.github.com/articles/permission-levels-for-an-organization-repository/ If you want to add him, go here. |
@caesarxuchao: #7145 has been causing issues for a user because the load balancer name changes if the service's UID changes (e.g. if it's deleted and recreated). Think we can change this? A hash of cluster name, namespace, and service name should get around it, but there may be better ideas as well. |
Sure. I'm not confident that I can fix this quickly. If it's urgent, maybe you can assign some one more experienced to fix it? One question: |
I think I'm the guilty party here. I was unaware that when we create a new We can quite safely roll back the change while we decide on the best Q On Mon, Apr 27, 2015 at 6:46 PM, Chao Xu notifications@github.com wrote:
|
I think the real breakage is that we don't have any way to claim an LB-IP On Mon, Apr 27, 2015 at 7:09 PM, Quinton Hoole notifications@github.com
|
Will do. Even if the name is kept consistent as it was before, with the way everything currently works the IP won't be consistent. |
yeah, I'm not positive that the name has to be consistent. What we need is a way to claim the same public IP address, and we already have that (at least for GCE) Assigning to me, and I'll validate the length requirements, make sure public ip assignment works for AWS and close out this issue. |
Note there are two separate things here: (1) a purely-name-based construction can exceed length limits given a single service and (2) some form of across-service consistency is apparently needed. (1) is trivially solvable by either always using a hash or alternatively using a two-stage process where you generate a desired name and only hashify if it's longer than the length limits by truncating it and appending a hash of said name. |
AWS's load balancer hasn't been merged yet, so there's not much to check out there. I'm going to be reducing the churn of load balancers later today, which should help prevent IP address changes for services that are modified. |
I think we need to be able to figure out which Service an LB is attached to @justinsb regarding being able to claim an LB IP. I don't think that is On Thu, Apr 30, 2015 at 10:11 AM, Brendan Burns notifications@github.com
|
I think that we need to roll back #7609 and think this issue through a bit better. See comment on that PR. |
GCE has a length limit of 63 characters for its load balancer components (target pools and forwarding rules), and AWS has a length limit of 32 characters. Our current load balancer name construction of clustername-namespace-servicename can exceed both limits, especially AWS's. We should use a shorter name construction method less likely to hit these limits.
The text was updated successfully, but these errors were encountered: