/kind bug
./scripts/* -> ./hack (or ./build?)
./cloud/aws -> ./pkg/cloud/aws
./clusterctl -> ./cmd/clusterctl
go get sigs.k8s.io/cluster-api-provider-aws should install clusterctl
./images -> ./build/amis
What upstream are we talking about?
I don't think there is really an upstream for this repository. We copy/pasta'd from a skeleton repo and these patterns don't match cluster-api so I'm curious what 'upstream' is referenced in this ticket.
followup: upstream referenced here is kubernetes/kubernetes.
This is a trade off. Either the repo becomes a bit easier to understand for folks coming from k/k or we keep it as is and keep it consistent for folks coming from other cluster-providers. I'd prefer the latter but don't care too much. What I do care about is that we make sure the time invested in moving code is worth the effort.
This is important for the general migration from AAs to CRDs. A number of providers have been created using https://github.com/davidewatson/cluster-api-provider-skeleton @chuckha has updated this repo for CRDs. We should consider standardizing on a workflow for creating new providers which makes it easy to follow the conventions.
Personally, I am mostly in favor of the k/k layout. There are already significant changes required for the migration to CRDs so we might as well bite the bullet now.
/assign @vincepri
/unassign @timothysc
More stuffz, careful what you wish for.
Most helpful comment
/assign @vincepri
/unassign @timothysc
More stuffz, careful what you wish for.