-
Notifications
You must be signed in to change notification settings - Fork 20
Conversation
0337fa4
to
58c425c
Compare
) | ||
|
||
// Interface defines functions that need to be implemented by cloudproviders. | ||
type Interface interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's too early to have a cloud provider interface. Best we could probably do is create boundaries between the Kubernetes client code and the cloud provider code.
Can we build something first, then try to figure out what interfaces we need? Interfaces usually make more sense when the fall out naturally from the use cases rather than trying to define them up front.
I would have imagined something like:
|
Then as we want to expand our use-cases and extend to different cloud, we can figure out a more detailed package structure and interfaces. |
When was testing with approver in #1 , And I think an interface like
gives the required functionality for approver to match CN to instanceid in csr.spec.Username and a valid ASG. With atleast the interface down for a minute I can test nodeapprover functions with unit tests... |
If it makes more sense I can change the dir structure to look like
|
58c425c
to
97eb161
Compare
Package APIs are waaaaay harder to design than just writing code. My general recommendation is:
I've never seen someone do a cloud provider package well. I would imagine that the package API would look something like: package aws
type Config struct {
Kubernetes rest.Config
AWS aws.Config
// other options like what autoscaling groups you're allowing
}
type Approver struct {
// all fields un-exported
}
func New(c *Config) (*Approver, error) {
}
func (a *Approver) Run(ctx context.Context) {
} Then after we build that, we can figure out what parts are re-usable from a general sense. |
closing in favor of #5 |
Add an pkg cloudprovider.
Also tests travisci.
/cc: @ericchiang