-
Notifications
You must be signed in to change notification settings - Fork 207
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
Add an AgentBaker interface for RP to use. #926
Add an AgentBaker interface for RP to use. #926
Conversation
This is the preparation step to separate AgentBaker into a standalone service. RP will call the API provided by AgentBaker to get CustomData, CSE, and VHD image to provision nodes. We'll use protocol buffer and gRPC for the API definition. For now, use straight Go interface as API to help testing the end to end flow.
"github.com/Azure/agentbaker/pkg/agent/datamodel" | ||
) | ||
|
||
type AgentBaker 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.
does the agentbaker pkg itself need to define the interface contract that it implements? In go it's more common to define the interface at the consuming pkg (i.e our backend rp code)
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.
In our code base, do we have an example with interface being defined at the consuming side? I saw more examples with interfaces defined at the library code. For example, our core/clients defined all the interfaces. Another example is the Azure SDK for Go library we use: it defines the interfaces: https://github.com/Azure/azure-sdk-for-go/blob/main/services/compute/mgmt/2021-03-01/compute/computeapi/interfaces.go
} | ||
} | ||
|
||
return nodeBootstrapping, nil |
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.
do we need to return an error if the input distro doesn't have a corresponding AzureCloudOSImage?
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.
actually do we need to move SIG configs here as well? Will that be done in a separate PR?
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 changed the code to return an error when cloud is not found.
Not returning an error if image is not found yet because for some cases the image is only found in SIG.
I'll prepare a new PR to move over the SIG settings. When that is done, if the image is not found in both places, I'll make the function return an error.
pkg/agent/datamodel/osimageconfig.go
Outdated
ImageVersion: "latest", | ||
} | ||
|
||
CoreOSImageConfig = AzureOSImageConfig{ |
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 doubt this os config is used at all
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.
Yeah, you are right. I just copied the whole thing. CoreOS has been removed now.
* Add an AgentBaker interface for RP to use. This is the preparation step to separate AgentBaker into a standalone service. RP will call the API provided by AgentBaker to get CustomData, CSE, and VHD image to provision nodes. We'll use protocol buffer and gRPC for the API definition. For now, use straight Go interface as API to help testing the end to end flow. * Return error if cloud is not found in the OS image settings. * Remove setting for CoreOS. It's not used.
This is the preparation step to separate AgentBaker into a standalone service. RP will call the API provided by AgentBaker to get CustomData, CSE, and VHD image to provision nodes.
We'll use protocol buffer and gRPC for the API definition. For now, use straight Go interface as API to help testing the end to end flow.