Change:
namedFlagSets := s.Flags(KnownControllers(), ControllersDisabledByDefault.List()) verflag.AddFlags(namedFlagSets.FlagSet("global")) globalflag.AddGlobalFlags(namedFlagSets.FlagSet("global"), cmd.Name()) <del> // hoist this flag from the global flagset to preserve the commandline until // the gce cloudprovider is removed. globalflag.Register(namedFlagSets.FlagSet("generic"), "cloud-provider-gce-lb-src-cidrs") </del> <ins> if flag.CommandLine.Lookup("cloud-provider-gce-lb-src-cidrs") != nil { // hoist this flag from the global flagset to preserve the commandline until // the gce cloudprovider is removed. globalflag.Register(namedFlagSets.FlagSet("generic"), "cloud-provider-gce-lb-src-cidrs") } </ins> for _, f := range namedFlagSets.FlagSets { fs.AddFlagSet(f) }

Discussion:
What happened: panic: failed to find flag in global flagset (flag): cloud-provider-gce-lb-src-cidrs goroutine 1 [running]: (0xc0000ba900, 0x17df195, 0x1f) +0x1a9 (0xc00008e150) +0x438 () /home/neil/Dev/brightbox-cloud-controller- +0x90 What you expected to happen: The controller should run and stop with a '--cloud-provider cannot be empty' message How to reproduce it (as minimally and precisely as possible): Follow the out of tree instructions here Comment out the "" import line and build the cloud-controller-manager Anything else we need to know?: This worked fine prior to 1.14.0 Environment: Kubernetes version (use ): lient Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-03-25T15:53:57Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-03-25T15:45:25Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Brightbox OS (e.g: ): Ubuntu 18.04.2 LTS Kernel (e.g. ): Linux bionic-vm 4.15.0-47-generic -Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x8664 x8664 x8664 GNU/Linu Install tools: kubeadm Others:
/sig cloud-provider
any updates?
we chatted about this the other day on Slack.
The GCE flag seems to be registered , with the panic eventually occurring .
Given some pointers on how to resolve the issue best, I'm happy to take a stab at a PR.
A workaround for external cloud providers seems to be to add a bogus version of the parameter before the call to , like this:
would it be better to do something like this in master? (and get it back ported to 1.14 branch?)

I think that should work, yeah. What I am wondering though is whether this is the way we want to go with long-term. It feels odd to me to have a specific GCE-only parameter be part of the generic bootstrapping process which we then need to handle in a special way. If it's about getting a fix out ASAP (and think about a possibly better design later), I'm all on-board with your patch. :+1:
the right thing to do is to get the sig-gcp folks to refactor that flag properly (and/or) remove the gce provider entirely (as a out of tree provider over time).
let's stop the bleeding where external providers have to make unnecessary changes like you mentioned (fake flag). can you please file a PR with the patch i proposed?
will do, thanks!
Thanks for reporting this issue and thanks for following-up Agreed with everything said. I can't recall why that flag was in there in the first place, I think it was required to get the reference CCM implementation working with GCE. Apologies that it broke other implementations. The proposed changes makes sense to me as well. We have some work coming up (likely in the next release cycle) to make more easily consumable as an external library which may involve moving into it's own repo. Let me know if anyone is interested in picking this up!
Submitted a fix at
in general, I'd be interested in helping on the move of . However, I likely won't have many cycles available until post-KubeCon EU. If the effort is low-priority and/or can wait until end of May / June though, I'd be happy to help.
I don't think we'll get to this until the v1.16 release cycle so I will loop you in then :)
oh please do then, that's a convenient timeline for me.
Sounds great Here's the backlog tracking issue