feat: CSE-based bootstrapping with bootstrapping client mode #527

comtalyst · 2024-10-16T03:27:47Z

Fixes #

Description

Using provision servers provide opportunities for us to delegate deterministic bootstrapping details away to keep our maintenance focus on autoscaling.
For the first mode introduced here—the bootstrapping client—will also switch back to CSE-based bootstrapping for general stability. The server is expected to provide custom data and CSE based on our inputs of ProvisionProfile. See swagger file for specifics.

This pathway will be supported by NAP only, for now.

How was this change tested?

NAP E2Es
Manual inspection of retrieved CSE values
K8s versions: 1.28.0, 1.29.9, 1.30.1, 1.31.1
ACRPull (on the above versions)

Does this change impact docs?

Yes, PR includes docs updates
Yes, issue opened: #
No

Release Note

NONE

Bryce-Soghigian · 2024-10-16T03:37:02Z

pkg/providers/imagefamily/azlinux.go

 		},
 	}
 }

 // UserData returns the default userdata script for the image Family
-func (u AzureLinux) UserData(kubeletConfig *corev1beta1.KubeletConfiguration, taints []v1.Taint, labels map[string]string, caBundle *string, _ *cloudprovider.InstanceType) bootstrap.Bootstrapper {
+func (u AzureLinux) SelfContainedUserData(kubeletConfig *corev1beta1.KubeletConfiguration, taints []v1.Taint, labels map[string]string, caBundle *string, _ *cloudprovider.InstanceType) bootstrap.Bootstrapper {


If we are going to rename this and change from the AWS Paradigm we should call this CustomData instead of UserData?

This ends up getting converted to custom data here https://github.com/Azure/karpenter-provider-azure/blob/main/pkg/providers/instance/instance.go#L336

The reason we called it user data was to align with AWS but if we are changing might as well go all the way.

According to self-contained feature owners, right now that is actually CustomData (yes, I think we've been mislabeling it). But there could be a switch soon. But we could just rename it for now.

Bryce-Soghigian · 2024-10-16T03:42:40Z

pkg/providers/imagefamily/ubuntu_2204.go

@@ -60,6 +62,7 @@ func (u Ubuntu2204) DefaultImages() []DefaultImageOutput {
 				scheduling.NewRequirement(v1.LabelArchStable, v1.NodeSelectorOpIn, corev1beta1.ArchitectureAmd64),
 				scheduling.NewRequirement(v1alpha2.LabelSKUHyperVGeneration, v1.NodeSelectorOpIn, v1alpha2.HyperVGenerationV1),
 			),
+			Distro: "aks-ubuntu-containerd-22.04",


nit: these should be constants

Bryce-Soghigian

First round of comments, still need to dig into core logic a bit more and think through the new launch template patterns and the new resolver patterns also I need to evaluate if we are passing in all the right KubeletConfiguration.

Bryce-Soghigian · 2024-10-16T03:44:58Z

pkg/operator/operator.go

 		azConfig.KubeletIdentityClientID,
 		azConfig.NodeResourceGroup,
 		azConfig.Location,
 		vnetGUID,
+		options.FromContext(ctx).ProvisionMode,


Do we need provision mode or would it be better to align on a NAP flag?

karpenter-provider-azure/pkg/operator/options/options.go

Line 97 in fc97633

fs.BoolVar(&o.ManagedKarpenter, "managed-karpenter", env.WithDefaultBool("MANAGED_KARPENTER", false), "Whether Karpenter is managed by AKS or not.")

There could be more than one provisioning mode (including within NAP)

#527 (comment) yeah I responded down here with similar arguement. We could have multiple provisioning modes, also we could have mulitple "types" of karpenter

self-hosted aks, managed aks, self-hosted azure, its arguable that even this boolean flag I am introducing in my PR would make more sense as a string with multiple options.

Bryce-Soghigian · 2024-10-16T03:47:46Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+	if p.KubeletConfig != nil && p.KubeletConfig.MaxPods != nil {
+		provisionProfile.MaxPods = p.KubeletConfig.MaxPods
+	} else {
+		provisionProfile.MaxPods = lo.ToPtr(int32(250)) // Delegatable defaulting?


We don't want to delegate defaulting until nap users can configure different limits for MaxPods.

If we default for azure cni without overlay to 30, without a way for customers to change that value one node will never be able to have more than 30 pods.

I suspect that will be a pain point.

MaxPods in AKSNodeClass is in the v1 migration PR, so CNI-based defaulting (client- or server-side) should work.

Bryce-Soghigian · 2024-10-16T03:48:25Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+		provisionProfile.MaxPods = lo.ToPtr(int32(250)) // Delegatable defaulting?
+	}
+
+	if modeString, ok := p.Labels["kubernetes.azure.com/mode"]; ok && modeString == "system" {


Can we move the labels like this into our api and the modeString into our constants?

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

Bryce-Soghigian · 2024-10-16T04:12:56Z

pkg/providers/launchtemplate/launchtemplate.go

+		template.AgentBakerCSE = cse
+	} else {
+		// render user data
+		userData, err := params.SelfContainedUserData.Script()


is self contained ever using userdata? why is it called this? Maybe im misunderstanding something?

Bryce-Soghigian · 2024-10-16T04:13:57Z

pkg/providers/launchtemplate/parameters/types.go

+	AgentBakerNodeBootstrapping agentbakerbootstrap.Bootstrapper
+	ImageID                     string
+	StorageProfile              string
+	IsWindows                   bool


Remove from here and resolve with helper function instead since we already know image family?

Bryce-Soghigian · 2024-10-16T04:14:22Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+	if resp.Payload == nil {
+		return "", "", fmt.Errorf("no payload in response")
+	}
+	if resp.Payload.Cse == nil || *resp.Payload.Cse == "" {


nit: CSE should be cased consistently across the code

Agreed, though some of this may be coming from Swagger etc.

All this come un-golang namings from the auto-generated client.

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

pkg/operator/options/options_validation.go

pkg/provisionclients/swagger/nodebootstrapping.json

Bryce-Soghigian · 2024-10-16T04:28:22Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+	if p.KubeletConfig != nil {
+		provisionProfile.CustomKubeletConfig = &models.CustomKubeletConfig{
+			// AllowedUnsafeSysctls: ..., // Unsupported as of now
+			CPUCfsQuota: p.KubeletConfig.CPUCFSQuota,
+		}
+	}
+


Can you leave some comments here on whats defaulted in NPS for KubeletConfig vs what is not? Its very confusing to understand what flags we are getting vs need to be passing in.

Required fields are marked in the swagger spec.

Bryce-Soghigian · 2024-10-16T04:34:18Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+	if p.KubeletConfig != nil {
+		provisionProfile.CustomKubeletConfig = &models.CustomKubeletConfig{
+			// AllowedUnsafeSysctls: ..., // Unsupported as of now
+			CPUCfsQuota: p.KubeletConfig.CPUCFSQuota,


Do we plan on adding official support for customers specifying kubelet configuration for GA?

Yes, first cut of a subset (essentially CustomKubeletConfig w/o CPU/MemoryReserved and Seccomp) is in v1 migration PR; we should pick this up when merging the two. (The set is relatively well-aligned, but minor adaptation will be needed.)

Bryce-Soghigian · 2024-10-16T04:37:09Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+type ProvisionClientBootstrap struct {
+	ClusterName                    string
+	KubeletConfig                  *corev1beta1.KubeletConfiguration
+	Taints                         []core.Taint      `hash:"set"`
+	StartupTaints                  []core.Taint      `hash:"set"`
+	Labels                         map[string]string `hash:"set"`
+	SubnetID                       string
+	Arch                           string
+	SubscriptionID                 string
+	ClusterResourceGroup           string
+	ResourceGroup                  string
+	KubeletClientTLSBootstrapToken string
+	KubernetesVersion              string
+	ImageDistro                    string
+	IsWindows                      bool
+	InstanceType                   *cloudprovider.InstanceType
+	StorageProfile                 string
+	ImageFamily                    string
+}
+


Most of these options are shared between self contained and agentbaker bootstrap. Can we share those values with struct embedding rather than copy pasting in both places?

Bryce-Soghigian · 2024-10-16T22:43:24Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+	if p.Arch == "amd64" {
+		provisionProfile.Architecture = lo.ToPtr("x64")
+	} else {
+		provisionProfile.Architecture = lo.ToPtr(p.Arch)
+	}


Could these be defaulted based on the instance type on the NPS side?

Bryce-Soghigian · 2024-10-16T22:43:59Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+	if utils.IsNvidiaEnabledSKU(p.InstanceType.Name) {
+		if utils.UseGridDrivers(p.InstanceType.Name) {
+			provisionProfile.GpuProfile = &models.GPUProfile{
+				DriverType:       lo.ToPtr(models.DriverType_GRID),
+				InstallGPUDriver: lo.ToPtr(true),
+			}
+		} else {
+			provisionProfile.GpuProfile = &models.GPUProfile{
+				DriverType:       lo.ToPtr(models.DriverType_CUDA),
+				InstallGPUDriver: lo.ToPtr(true),
+			}
+		}
+
+	}


Same here, all of this logic will resolve to the same static values based on the sku, if we have the sku NPS can resolve these values.

Bryce-Soghigian · 2024-10-16T22:45:14Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+	if p.IsWindows {
+		provisionProfile.OsType = lo.ToPtr(models.OSType_Windows)
+	} else {
+		provisionProfile.OsType = lo.ToPtr(models.OSType_Linux)
+	}


Seems odd we need this at all since we pass in OS SKU. This alongside some of these other values could be easily inferred in a more minimal AgentpoolProfile payload

Bryce-Soghigian · 2024-10-16T22:46:09Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+	provisionHelperValues := &models.ProvisionHelperValues{
+		SkuCPU:    lo.ToPtr(p.InstanceType.Capacity.Cpu().AsApproximateFloat64()),
+		SkuMemory: lo.ToPtr(p.InstanceType.Capacity.Memory().AsApproximateFloat64()),
+	}
+


Again would be nice to infer these based on the instance type. All values that are not user input probably don't need to be in the provision profile payload in the future. We can resolve them inside of NPS

This is an architectural gap that I am going to look into later. Basically, it is not as simple to be resolved as other values, for now.

Bryce-Soghigian · 2024-10-16T22:46:50Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+	if resp.Payload.CustomData == nil || *resp.Payload.CustomData == "" {
+		return "", "", fmt.Errorf("no CustomData in response")
+	}


If we get errors here would it make sense to fall back onto SelfContained bootstrap? Could we fall back on our bootstrapping logic if this fails?

Good question, but I think the answer is No

Could look into general retriability (e.g., from network/reliability issues) later.
But I don't think we should mix provision modes, for consistency.

Bryce-Soghigian · 2024-10-16T22:47:22Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+	nodeLabels["kubernetes.azure.com/role"] = "agent"
+	nodeLabels["kubernetes.azure.com/cluster"] = normalizeResourceGroupNameForLabel(nodeResourceGroup)
+}


Do we need to make the karpenter nodepool aware of these defaulted labels?

Maybe, though this would only be consequential if there are workloads targeting these, which is very unlikely. (More generally, it may be useful to develop a mechanism for letting Karpenter know Nodes will have certain labels - without having to specify them in NodePool.)

yeah I doubt role and cluster will be labels people use for scheduling, i was thinking a similar thing to have some providerLabels concept that allows core to know about injected values that are created in the code without requiring them on the nodepool.

FYI those are already there in self-contained.
The new one we will get from the provision server (and AgentBaker) will be the below.
The emptiness is intentional to prevent workload targeting them, for now.

agentpool= kubernetes.azure.com/agentpool=

Bryce-Soghigian · 2024-10-16T22:48:12Z

pkg/providers/imagefamily/azlinux.go

@@ -60,6 +62,7 @@ func (u AzureLinux) DefaultImages() []DefaultImageOutput {
 				scheduling.NewRequirement(v1.LabelArchStable, v1.NodeSelectorOpIn, corev1beta1.ArchitectureAmd64),
 				scheduling.NewRequirement(v1alpha2.LabelSKUHyperVGeneration, v1.NodeSelectorOpIn, v1alpha2.HyperVGenerationV1),
 			),
+			Distro: "aks-azurelinux-v2",


Can we make these consts, or can we import them from agentbaker?

Will consider that along with potential delegation of this field to the provision server.

Bryce-Soghigian · 2024-10-16T22:50:52Z

pkg/providers/instance/instance.go

+	if p.provisionMode == options.ProvisionModeBootstrappingClient {
+		err = p.createCSExtension(ctx, resourceName, launchTemplate.AgentBakerCSE, launchTemplate.IsWindows)
+		if err != nil {
+			// This should fall back to cleanupAzureResources


Should we be logging the CSE Failure at least? Or creating k8s events for CSE Failure?

Logged from within createCSExtension

tallaxes

Overall looks great for the first (and working) cut! I presume fixing CI & tests is coming, and further refactoring/cleanup can be expected later.

tallaxes · 2024-10-17T05:40:06Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+	if p.KubeletConfig != nil && p.KubeletConfig.MaxPods != nil {
+		provisionProfile.MaxPods = p.KubeletConfig.MaxPods
+	} else {
+		provisionProfile.MaxPods = lo.ToPtr(int32(250)) // Delegatable defaulting?


MaxPods in AKSNodeClass is in the v1 migration PR, so CNI-based defaulting (client- or server-side) should work.

tallaxes · 2024-10-17T05:49:35Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+	if p.KubeletConfig != nil {
+		provisionProfile.CustomKubeletConfig = &models.CustomKubeletConfig{
+			// AllowedUnsafeSysctls: ..., // Unsupported as of now
+			CPUCfsQuota: p.KubeletConfig.CPUCFSQuota,


Yes, first cut of a subset (essentially CustomKubeletConfig w/o CPU/MemoryReserved and Seccomp) is in v1 migration PR; we should pick this up when merging the two. (The set is relatively well-aligned, but minor adaptation will be needed.)

tallaxes · 2024-10-17T05:58:59Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+
+	provisionHelperValues := &models.ProvisionHelperValues{
+		SkuCPU:    lo.ToPtr(p.InstanceType.Capacity.Cpu().AsApproximateFloat64()),
+		SkuMemory: lo.ToPtr(p.InstanceType.Capacity.Memory().AsApproximateFloat64()),


Let's make sure units align

(see the update, there is an issue I found and a workaround)

tallaxes · 2024-10-17T06:00:28Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap.go

+	transport := httptransport.New(options.FromContext(ctx).NodeBootstrappingServerURL, "/", []string{"http"})
+	client := client.New(transport, strfmt.Default)


Assuming client reuse, scheme lookup etc. will come with refactoring ...

tallaxes · 2024-10-17T06:32:44Z

pkg/providers/launchtemplate/launchtemplate.go

+	ImageID               string
+	SubnetID              string
+	Tags                  map[string]*string
+	AgentBakerCustomData  string


Do we need to carry both? Or is this intended as UserData vs CustomData separation?

Apart from just that intention, I don't think we truly need to separate it.
But I would prefer to keep it separated this before we are more confident in that.

tallaxes · 2024-10-17T06:34:33Z

pkg/providers/launchtemplate/launchtemplate.go

+	Tags                  map[string]*string
+	AgentBakerCustomData  string
+	AgentBakerCSE         string
+	IsWindows             bool


Does not feel like it belongs in the template ...

I plan to spend more time on this category later. Will require a more thorough understanding of the abstraction intentions.

Bryce-Soghigian · 2024-10-17T07:58:30Z

pkg/utils/gpu.go

 func GetAKSGPUImageSHA(size string) string {
-	if useGridDrivers(size) {
+	if UseGridDrivers(size) {
 		return AKSGPUGridSHA
 	}


Do these values have to come from us? if we use the ones from agentbaker and default them in NPS we can have consistency and won't have to bump the shas for cves separately.

We are not using SHAs. Just that UseGridDrivers(). But could still be a candidate for that consideration.

coveralls · 2024-10-18T22:31:23Z

Pull Request Test Coverage Report for Build 11428938152

Details

178 of 1522 (11.7%) changed or added relevant lines in 33 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-3.4%) to 94.477%

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pkg/providers/imagefamily/resolver.go	30	32	93.75%
pkg/providers/imagefamily/image.go	4	7	57.14%
pkg/providers/launchtemplate/launchtemplate.go	18	26	69.23%
pkg/provisionclients/client/node_bootstrapping_client.go	26	42	61.9%
pkg/provisionclients/models/agent_pool_security_profile.go	0	18	0.0%
pkg/provisionclients/models/agent_pool_windows_profile.go	0	18	0.0%
pkg/provisionclients/models/artifact_streaming_profile.go	0	18	0.0%
pkg/provisionclients/models/azure_o_s_image_config.go	0	18	0.0%
pkg/provisionclients/models/custom_kubelet_config.go	0	18	0.0%
pkg/provisionclients/models/g_p_u_profile.go	0	18	0.0%

Totals
Change from base Build 11414974949:	-3.4%
Covered Lines:	36450
Relevant Lines:	38581

💛 - Coveralls

pkg/operator/options/options.go

tallaxes · 2024-10-19T05:42:33Z

pkg/operator/options/options.go

@@ -96,7 +97,7 @@ func (o *Options) AddFlags(fs *coreoptions.FlagSet) {
 	fs.StringVar(&o.SubnetID, "vnet-subnet-id", env.WithDefaultString("VNET_SUBNET_ID", ""), "The default subnet ID to use for new nodes. This must be a valid ARM resource ID for subnet that does not overlap with the service CIDR or the pod CIDR")
 	fs.Var(newNodeIdentitiesValue(env.WithDefaultString("NODE_IDENTITIES", ""), &o.NodeIdentities), "node-identities", "User assigned identities for nodes.")
 	fs.StringVar(&o.NodeResourceGroup, "node-resource-group", env.WithDefaultString("AZURE_NODE_RESOURCE_GROUP", ""), "[REQUIRED] the resource group created and managed by AKS where the nodes live")
-	fs.StringVar(&o.ProvisionMode, "provision-mode", env.WithDefaultString("PROVISION_MODE", ""), "[UNSUPPORTED] The provision mode for the cluster.")
+	fs.StringVar(&o.ProvisionMode, "provision-mode", env.WithDefaultString("PROVISION_MODE", "aksselfcontained"), "[UNSUPPORTED] The provision mode for the cluster.")
 	fs.StringVar(&o.NodeBootstrappingServerURL, "nodebootstrapping-server-url", env.WithDefaultString("NODEBOOTSTRAPPING_SERVER_URL", ""), "[UNSUPPORTED] The url for the node bootstrapping provider server.")


Suggested change

fs.StringVar(&o.NodeBootstrappingServerURL, "nodebootstrapping-server-url", env.WithDefaultString("NODEBOOTSTRAPPING_SERVER_URL", ""), "[UNSUPPORTED] The url for the node bootstrapping provider server.")

fs.StringVar(&o.NodeBootstrappingServerURL, "nodebootstrapping-server-url", env.WithDefaultString("NODEBOOTSTRAPPING_SERVER_URL", ""), "[UNSUPPORTED] The url for the node bootstrapping provider server")

I think most of our options have the full stop in their descriptions.
Is not having it a right way?

No, full stop seems correct. Just wanted it to be consistent, and looked at surrounding ones and not the full set.

I changed the other ones missing a full stop to have it.

tallaxes · 2024-10-19T05:56:48Z

pkg/providers/imagefamily/agentbakerbootstrap/provisionclientbootstrap_test.go

+	"github.com/Azure/karpenter-provider-azure/pkg/providers/instancetype"
+)
+
+func TestReverseVMMemoryOverhead(t *testing.T) {


Do we need to keep this?

Better than not having it?
In case someone change something and it matters. And it is not too burdening resource-wise IMO.

pkg/operator/options/options.go

tallaxes · 2024-10-19T06:08:08Z

pkg/provisionclients/swagger/nodebootstrapping.json

+        },
+        "podMaxPids": {
+          "type": "integer",
+          "format": "int32",


Note that actual kubelet podPidsLimit is int64. Something we likely need to fix on the AKS side, might as well type it correctly here.

I think we should change ours after to not misalign with AKS requirements...

tallaxes · 2024-10-19T07:10:05Z

Makefile-az.mk

@@ -358,3 +358,11 @@ az-helm-install-snapshot: az-configure-values ## Install Karpenter snapshot rele

 az-rmcrds: ## Delete Karpenter CRDs
 	kubectl delete crd nodepools.karpenter.sh nodeclaims.karpenter.sh aksnodeclasses.karpenter.azure.com
+
+az-swagger-generate-clients-raw:
+	cd pkg/provisionclients && swagger generate client -f swagger/*.json


A couple of thoughts:

You should be able to remove make targets / fold them into just "go generate" by creating e.g. provisionclients/generate.go with something like //go:generate swagger generate client ... etc.

Take a look at generate client options, consider maybe --keep-spec-order?

Could we maybe keep the spec in yaml instead of json?

comtalyst · 2024-10-19T08:33:53Z

pkg/consts/consts.go

@@ -28,4 +28,7 @@ const (
 	NetworkDataplaneAzure  = "azure"



IMO, most of these should be in options to not have knowledge coupling.
But for now, let's keep it in one place for consistency.

…align with AgentBaker

comtalyst requested review from tallaxes and Bryce-Soghigian October 16, 2024 03:27

Bryce-Soghigian reviewed Oct 16, 2024

View reviewed changes

Bryce-Soghigian requested changes Oct 16, 2024

View reviewed changes

Bryce-Soghigian reviewed Oct 16, 2024

View reviewed changes

pkg/provisionclients/swagger/nodebootstrapping.json Show resolved Hide resolved

Bryce-Soghigian reviewed Oct 16, 2024

View reviewed changes

tallaxes reviewed Oct 17, 2024

View reviewed changes

Bryce-Soghigian assigned comtalyst Oct 17, 2024

Bryce-Soghigian added the area/bootstrap Issues or PRs related to bootstrap label Oct 17, 2024

Bryce-Soghigian reviewed Oct 17, 2024

View reviewed changes

Bryce-Soghigian mentioned this pull request Oct 17, 2024

feat: support setting custom dns-service-ip via --dns-service-ip flag #329

Closed

3 tasks

comtalyst force-pushed the comtalyst/nap-cse-bootstrapping branch from 7b80a07 to 909007e Compare October 18, 2024 22:24

comtalyst force-pushed the comtalyst/nap-cse-bootstrapping branch from 3e891a2 to 9c691b3 Compare October 18, 2024 23:31

comtalyst marked this pull request as ready for review October 19, 2024 00:22

tallaxes reviewed Oct 19, 2024

View reviewed changes

comtalyst added 2 commits October 19, 2024 01:25

chore: swagger spec for nodebootstrapping GET and autogenerated client

cd66fd2

feat: bootstrapping client provision mode

06d9613

comtalyst added 11 commits October 19, 2024 01:25

chore: general code improvements

d8ff982

fix: required VnetCidrs wasn't populated

7169f33

chore: read error response as text

c6a76ba

fix: handle the issue of mismatched error format in response body/header

5743723

chore: more accurate overhead subtraction for instancetype

dc5f626

fix: correct VM memory passing

62e5c3b

test: some unit tests and improvements

8440647

chore: linter changes and small improvements

425a55a

feat: makefile command for swagger client generation

45cd0c0

chore: remove unused parameters in readResponse()

049640c

fix: swagger binary not found

ff4706a

comtalyst force-pushed the comtalyst/nap-cse-bootstrapping branch from 9c691b3 to ff4706a Compare October 19, 2024 08:25

chore: small improvements

a5c8403

comtalyst commented Oct 19, 2024

View reviewed changes

comtalyst added 2 commits October 20, 2024 11:58

chore: added missing fullstops in other env descriptions

a57bb00

chore: rename bootstrapping types to scriptless and customscripts to …

aadbe7b

…align with AgentBaker

		transport := httptransport.New(options.FromContext(ctx).NodeBootstrappingServerURL, "/", []string{"http"})
		client := client.New(transport, strfmt.Default)

	fs.StringVar(&o.NodeBootstrappingServerURL, "nodebootstrapping-server-url", env.WithDefaultString("NODEBOOTSTRAPPING_SERVER_URL", ""), "[UNSUPPORTED] The url for the node bootstrapping provider server.")
	fs.StringVar(&o.NodeBootstrappingServerURL, "nodebootstrapping-server-url", env.WithDefaultString("NODEBOOTSTRAPPING_SERVER_URL", ""), "[UNSUPPORTED] The url for the node bootstrapping provider server")

feat: CSE-based bootstrapping with bootstrapping client mode #527

Are you sure you want to change the base?

feat: CSE-based bootstrapping with bootstrapping client mode #527

Conversation

comtalyst commented Oct 16, 2024 • edited Loading

Choose a reason for hiding this comment

comtalyst Oct 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Bryce-Soghigian left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Bryce-Soghigian Oct 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Bryce-Soghigian Oct 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Bryce-Soghigian Oct 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tallaxes left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Bryce-Soghigian Oct 17, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coveralls commented Oct 18, 2024 • edited Loading

Pull Request Test Coverage Report for Build 11428938152

Details

💛 - Coveralls

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

comtalyst commented Oct 16, 2024 •

edited

Loading

comtalyst Oct 16, 2024 •

edited

Loading

Bryce-Soghigian Oct 16, 2024 •

edited

Loading

Bryce-Soghigian Oct 16, 2024 •

edited

Loading

Bryce-Soghigian Oct 16, 2024 •

edited

Loading

tallaxes left a comment •

edited

Loading

Bryce-Soghigian Oct 17, 2024 •

edited

Loading

coveralls commented Oct 18, 2024 •

edited

Loading