Cluster-api-provider-aws: More closely align repository structure to upstream

Created on 27 Sep 2018  路  5Comments  路  Source: kubernetes-sigs/cluster-api-provider-aws

/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

kinbug

Most helpful comment

/assign @vincepri
/unassign @timothysc

More stuffz, careful what you wish for.

All 5 comments

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.

286 moves clusterctl

/assign @vincepri
/unassign @timothysc

More stuffz, careful what you wish for.

Was this page helpful?
0 / 5 - 0 ratings