Use nocloud when specified #212

BobyMCbobs · 2022-11-29T02:30:56Z

What this PR does / why we need it:

Allows for CloudInitNoCloud volume type to be used and filled in when a volume is specified with the given type and the name "cloudinitvolume" and doesn't insert a CloudInitConfigDrive volume and disk.

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #200

Special notes for your reviewer:

Release notes:

NONE

coveralls · 2022-11-29T02:33:26Z

Pull Request Test Coverage Report for Build 3654098425

43 of 69 (62.32%) changed or added relevant lines in 2 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.3%) to 51.163%

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pkg/kubevirt/machine.go	2	4	50.0%
pkg/kubevirt/utils.go	41	65	63.08%

Files with Coverage Reduction	New Missed Lines	%
pkg/kubevirt/utils.go	2	70.78%

Totals
Change from base Build 3565380590:	-0.3%
Covered Lines:	968
Relevant Lines:	1892

💛 - Coveralls

davidvossel · 2022-11-29T16:15:25Z

/ok-to-test

davidvossel · 2022-11-29T20:51:00Z

pkg/kubevirt/utils.go

+				CDRom: &kubevirtv1.CDRomTarget{
+					Bus: kubevirtv1.DiskBusSATA,
+					ReadOnly: func() *bool {
+						b := true
+						return &b
+					}(),
+				},


is there a reason why noCloud should use a cdrom instead of a disk with virtio?

To some tests the CDROM type appears to work better with Talos

How about we default to the disk approach that we already have today, but only create that disk if there's not already a disk with the name cloudinitvolume

So this would allow you to create a disk however you want and our controllers won't touch it. But if the cloudinit disk doesn't exist, our controllers will give one as a default.

I tried it with Disk again and it appears to work fine.
I like the flow of providing a disk/volume with a given name and it fills in the rest using your changes on top.

Made it so it adds to if it doesn't already exist 57d40f5

davidvossel · 2022-11-29T20:51:51Z

pkg/kubevirt/utils.go

-				Bus: "virtio",
-			},
-		},
+	cloudInitType, index := noCloudVolume(template)


instead of calling this function noCloudVolume, could it instead be something like, detectCloudInitVolume

davidvossel · 2022-11-29T21:06:48Z

pkg/kubevirt/utils.go

+	cloudInitType, index := noCloudVolume(template)
+	cloudInitVolume := cloudinitVolume(template, ctx, cloudInitType)
+	cloudInitDisk := cloudinitDisk(template, cloudInitType)
+	if cloudInitType == "CloudInitNoCloud" {


instead of keying off the "CloudInitNoCloud" type here, could we instead detect if a previous cloudinit volume existed and use that index... So maybe have the detectCloudInitVolume function return either an index >= 0 if a volume already exists, or maybe -1 if no previous volume exists. Then with this if/def we'd just have if index >= 0 {

I think while that would make it less, I believe that would require extra explaining and documentation.
It might be clearer with outputs like exists and index.

In any case, the goal is to have it default to CloudInitConfigDrive, unless there's an non-nil CloudInitNoCloud volume named cloudinitvolume

yeah, an exists bool with an index makes sense as well.

I think i'd rather avoid detection logic that keys for the CloudInitNoCloud type directly, and instead have one that simply returns the cloud init type found in the volume. Right now we only have CloudInitNoCloud, and ConfigDrive, but in the future there might be more options. It would be nice if this logic naturally worked if the cloud init types are added to in the future

Using a different method based on the type detected, such as CloudInitNoCloud or CloudInitConfigDrive, will future proof it more than detecting only CloudInitNoCloud.

I'm sure there's some way to add more support another way

davidvossel

/approve
/lgtm

k8s-ci-robot · 2022-12-02T21:52:21Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: BobyMCbobs, davidvossel

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~OWNERS~~ [davidvossel]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

davidvossel · 2022-12-02T21:52:29Z

/lgtm cancel

davidvossel · 2022-12-02T21:53:22Z

@BobyMCbobs the PR looks good now, but can you check why the go-linter unit test is failing?

nunnatsa · 2022-12-04T19:38:01Z

pkg/kubevirt/utils.go

+		if err != nil {
+			panic(err)
+		}
+		break


Please remove. Not needed on golang. It will aldo solve the linter warning.

Updated in e58acaa

nunnatsa · 2022-12-04T19:38:15Z

pkg/kubevirt/utils.go

+		break
+	case "CloudInitConfigDrive":
+		template.Spec.Volumes = append(template.Spec.Volumes, cloudInitVolume)
+		break


Updated in e58acaa

nunnatsa · 2022-12-04T19:40:16Z

pkg/kubevirt/utils.go

+	case "CloudInitNoCloud":
+		err := mergo.Merge(&template.Spec.Volumes[index], cloudInitVolume)
+		if err != nil {
+			panic(err)


Panic will kill the whole process. Are uou sure this is the behaviour we want here?

buildVirtualMachineInstanceTemplate doesn't return an error.
Which behaviour would you suggest here?

I'm unsure how the behaviour would be if it were unhandled, like

_ = mergo.Merge(&template.Spec.Volumes[index], cloudInitVolume)

but perhaps that's an option?

After reading the code of mergo.Merge, I think it's too risky to ignore the error. I'm afraid there is no other option but change the signature of the buildVirtualMachineInstanceTemplate function, to add an error return value, and to do the same for the calling function, newVirtualMachineFromKubevirtMachine, then check this error in the Machine::Create methods (that does return error). These functions are also called from unit tests, so there is no choice but fixing these test as well.

Fair evaluation!
Updated in bb66a2d

BobyMCbobs · 2022-12-05T21:50:35Z

@davidvossel, @nunnatsa looking for lgtm

nunnatsa

Thank for the fixes. I added few more comments...

Also, a general comment for the whole PR: the "CloudInitConfigDrive" and "CloudInitNoCloud" strings are only used to get logic decisions. Not sure string is the best option for that. Please consider using integer constants with iota. For example:

type cloudInitType int

const (
	cloudInitConfigDrive cloudInitType = iota
	cloudInitNoCloud
)

nunnatsa · 2022-12-06T06:23:02Z

pkg/kubevirt/machine_test.go

@@ -309,7 +309,8 @@ var _ = Describe("util functions", func() {
 		machineContext.KubevirtMachine.Spec.VirtualMachineTemplate.Spec.DataVolumeTemplates = dataVolumeTemplates
 		machineContext.KubevirtMachine.Spec.VirtualMachineTemplate.Spec.Template.Spec.Volumes = volumes

-		newVM := newVirtualMachineFromKubevirtMachine(machineContext, "default")
+		newVM, err := newVirtualMachineFromKubevirtMachine(machineContext, "default")
+		Expect(err).To(BeNil())


Nit: Please consider using the dedicated gomega error assertion.

Suggested change

Expect(err).To(BeNil())

Expect(err).ToNot(HaveOccurred())

Updated in 6a8fd2b

nunnatsa · 2022-12-06T06:26:38Z

pkg/kubevirt/machine_test.go

@@ -453,7 +454,8 @@ var _ = Describe("util functions", func() {
 		machineContext.KubevirtMachine.Spec.VirtualMachineTemplate.Spec.DataVolumeTemplates = dataVolumeTemplates
 		machineContext.KubevirtMachine.Spec.VirtualMachineTemplate.Spec.Template.Spec.Volumes = volumes

-		newVM := newVirtualMachineFromKubevirtMachine(machineContext, "default")
+		newVM, err := newVirtualMachineFromKubevirtMachine(machineContext, "default")
+		Expect(err).To(BeNil())


Nit: Please consider using the dedicated gomega error assertion.

Suggested change

Expect(err).To(BeNil())

Expect(err).ToNot(HaveOccurred())

Updated in 6a8fd2b

nunnatsa · 2022-12-06T06:36:35Z

pkg/kubevirt/utils.go

+func detectCloudInitVolumeType(vmi *kubevirtv1.VirtualMachineInstanceTemplateSpec) (preferredType string, index int) {
+	preferredType = "CloudInitConfigDrive"
+	for i, v := range vmi.Spec.Volumes {
+		if v.CloudInitNoCloud != nil && v.Name == cloudInitVolumeName {
+			preferredType, index = "CloudInitNoCloud", i
+			break
+		}
+	}
+	return preferredType, index
 }



Personally, I don't like named return values and I find them confusing. If there is no reason to use them, please consider to drop them.

Also, I think we could write a shorter, simpler version of this function. How do you feel about this suggestion?

Suggested change

func detectCloudInitVolumeType(vmi *kubevirtv1.VirtualMachineInstanceTemplateSpec) (preferredType string, index int) {

preferredType = "CloudInitConfigDrive"

for i, v := range vmi.Spec.Volumes {

if v.CloudInitNoCloud != nil && v.Name == cloudInitVolumeName {

preferredType, index = "CloudInitNoCloud", i

break

}

}

return preferredType, index

}

func detectCloudInitVolumeType(vmi *kubevirtv1.VirtualMachineInstanceTemplateSpec) (string, int) {

for i, v := range vmi.Spec.Volumes {

if v.CloudInitNoCloud != nil && v.Name == cloudInitVolumeName {

return "CloudInitNoCloud", i

}

}

return "CloudInitConfigDrive", 0

}

The suggested function does look tidier, I've updated it to that in a621d12

Personally, I don't like named return values and I find them confusing. If there is no reason to use them, please consider to drop them.

The named return values make it clearing what is expected to be returned and I think are useful.
However, if you mean that the specific names are not helpful I would suggest preferredCloudInitVolumeType and existingCloudInitVolumeIndex

As I wrote, it's a personal preference. I'm not a fan of the named return values feature. But I'll won't block the PR for that.

Updated in dc49cec

nunnatsa · 2022-12-06T06:58:39Z

pkg/kubevirt/utils.go

+func detectCloudInitDisk(vmi *kubevirtv1.VirtualMachineInstanceTemplateSpec) (found bool, index int) {
+	for i, v := range vmi.Spec.Domain.Devices.Disks {
+		if v.Disk != nil && v.Name == cloudInitVolumeName {
+			found, index = true, i
+			break
+		}
 	}
-	return constants.WorkerNodeRoleValue
+	return found, index


Please consider removing the named return values. Also, the index return value is not in use and can be dropped. This function can be simplified a bit; for example:

Suggested change

func detectCloudInitDisk(vmi *kubevirtv1.VirtualMachineInstanceTemplateSpec) (found bool, index int) {

for i, v := range vmi.Spec.Domain.Devices.Disks {

if v.Disk != nil && v.Name == cloudInitVolumeName {

found, index = true, i

break

}

}

return constants.WorkerNodeRoleValue

return found, index

func detectCloudInitDisk(vmi *kubevirtv1.VirtualMachineInstanceTemplateSpec) bool {

for _, v := range vmi.Spec.Domain.Devices.Disks {

if v.Disk != nil && v.Name == cloudInitVolumeName {

return true

}

}

return false

}

Updated in acd5d10.

The named return values in the signature will be useful when reading documentation and for maintaining the functions in the future

nunnatsa · 2022-12-06T07:04:58Z

pkg/kubevirt/utils.go

+func cloudinitVolume(vmi *kubevirtv1.VirtualMachineInstanceTemplateSpec, ctx *context.MachineContext, preferredType string) kubevirtv1.Volume {
+	switch preferredType {
+	case "CloudInitNoCloud":
+		return kubevirtv1.Volume{
+			Name: cloudInitVolumeName,
+			VolumeSource: kubevirtv1.VolumeSource{
+				CloudInitNoCloud: &kubevirtv1.CloudInitNoCloudSource{
+					UserDataSecretRef: &corev1.LocalObjectReference{
+						Name: *ctx.Machine.Spec.Bootstrap.DataSecretName + "-userdata",
+					},
 				},
 			},
-		},
+		}
+	default:
+		return kubevirtv1.Volume{
+			Name: cloudInitVolumeName,
+			VolumeSource: kubevirtv1.VolumeSource{
+				CloudInitConfigDrive: &kubevirtv1.CloudInitConfigDriveSource{
+					UserDataSecretRef: &corev1.LocalObjectReference{
+						Name: *ctx.Machine.Spec.Bootstrap.DataSecretName + "-userdata",
+					},
+				},
+			},
+		}


Not sure about this function. Another way to implement this logic will be to split it to two functions, each generating one version of cloud init volume. Then use each one of them in the matching case in the switch sentence in the buildVirtualMachineInstanceTemplate function above, where we already know the volume type.

The reason I'm not comfortable with the current implementation is that we ask the same question again and again (what is the volume type?), while we already know the answer.

BobyMCbobs · 2022-12-07T20:01:23Z

Thank for the fixes. I added few more comments...

@nunnatsa, thanks for your review.

Also, a general comment for the whole PR: the "CloudInitConfigDrive" and "CloudInitNoCloud" strings are only used to get logic decisions. Not sure string is the best option for that. Please consider using integer constants with iota. For example:
type cloudInitType int

const (
	cloudInitConfigDrive cloudInitType = iota
	cloudInitNoCloud
)

I'm not sure why integer constants are preferred when strings provide immediate readability of what we're checking for.
Please help me to understand why integers are better.

nunnatsa · 2022-12-07T21:18:08Z

Please help me to understand why integers are better.

Integer constants are as readable as strings, I think. But comparing ints is much more efficient than comparing strings. Since the only usage of this values is for branches (if/switch), and there is no use at the actual value (e.g. print it out), then we can use the golang iota feature - this is why it exist for.

nunnatsa · 2022-12-08T05:21:39Z

pkg/kubevirt/utils.go

+			return "CloudInitNoCloud", i
+		}
+	}
+	return "CloudInitConfigDrive", 0


After thinking about it again, 0 is a valid slice index, and returning it is misleading, even if we don't actually using it in the case of CloudInitConfigDrive. Let's change it to -1, to be more clear about not finding the volume in the slice. What do you think?

Good thought! Updated in c2123db

BobyMCbobs · 2022-12-08T21:49:52Z

Please help me to understand why integers are better.

Integer constants are as readable as strings, I think. But comparing ints is much more efficient than comparing strings. Since the only usage of this values is for branches (if/switch), and there is no use at the actual value (e.g. print it out), then we can use the golang iota feature - this is why it exist for.

I must admit I haven't used this feature before, but it seems to work fine just tested it.
Updated in dc49cec

BobyMCbobs · 2022-12-09T02:15:23Z

Currently experiencing a runtime panic, no experienced before recent changes

I1209 02:08:45.979323       1 machine.go:156] controller/kubevirtmachine/coder-workspaces/talos66-cp-scfrf "msg"="Creating VM with role 'control-plane'..." "name"="talos66-cp-scfrf" "namespace"="coder-workspaces" "reconciler group"="infrastructure.cluster.x-k8s.io" "reconciler kind"="KubevirtMachine"
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x2d8 pc=0x153bf8c]

goroutine 579 [running]:
sigs.k8s.io/cluster-api-provider-kubevirt/pkg/kubevirt.prefixDataVolumeTemplates(0xc000436200, {0xc000a1a920, 0x10})
        /workspace/pkg/kubevirt/utils.go:65 +0x26c
sigs.k8s.io/cluster-api-provider-kubevirt/pkg/kubevirt.newVirtualMachineFromKubevirtMachine(0xc000620730, {0xc000a1a990, 0x10})
        /workspace/pkg/kubevirt/utils.go:118 +0x60f
sigs.k8s.io/cluster-api-provider-kubevirt/pkg/kubevirt.(*Machine).Create(0xc0000a9630, {0x1d00cd8, 0xc000701b60})
        /workspace/pkg/kubevirt/machine.go:158 +0x106
sigs.k8s.io/cluster-api-provider-kubevirt/controllers.(*KubevirtMachineReconciler).reconcileNormal(0xc000730000, 0xc000620730)
        /workspace/controllers/kubevirtmachine_controller.go:268 +0x486
sigs.k8s.io/cluster-api-provider-kubevirt/controllers.(*KubevirtMachineReconciler).Reconcile(0xc000730000, {0x1d00cd8?, 0xc000701b60}, {{{0xc000a1a930?, 0x19a3560?}, {0xc000a1a920?, 0x30?}}})
        /workspace/controllers/kubevirtmachine_controller.go:177 +0xebb
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile(0xc0000e22c0, {0x1d00cd8, 0xc000701b30}, {{{0xc000a1a930?, 0x19a3560?}, {0xc000a1a920?, 0x4041f4?}}})
        /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.0-beta.0.0.20211110210527-619e6b92dab9/pkg/internal/controller/controller.go:114 +0x27e
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler(0xc0000e22c0, {0x1d00c30, 0xc0003ec080}, {0x18b2620?, 0xc00009ca60?})
        /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.0-beta.0.0.20211110210527-619e6b92dab9/pkg/internal/controller/controller.go:311 +0x349
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem(0xc0000e22c0, {0x1d00c30, 0xc0003ec080})
        /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.0-beta.0.0.20211110210527-619e6b92dab9/pkg/internal/controller/controller.go:266 +0x1d9
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2()
        /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.0-beta.0.0.20211110210527-619e6b92dab9/pkg/internal/controller/controller.go:227 +0x85
created by sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2
        /go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.0-beta.0.0.20211110210527-619e6b92dab9/pkg/internal/controller/controller.go:223 +0x31c

Update

e5b4bbb has appeared to have resolved

davidvossel

Looks great to me. I made one more comment inline, and my only other comment is to please squash the commits down to a single commit, or at most two commits, one for logic and one for the tests. We don't always require that, but 16 commits for this pr is a little excessive.

davidvossel · 2022-12-09T22:03:45Z

pkg/kubevirt/utils.go

+		err := mergo.Merge(&template.Spec.Volumes[index], cloudInitVolume)
+		if err != nil {
+			return nil, err
+		}
+		return template, nil


I don't think there is any value in the mergo logic here. There's only one possible solution for how the CloudIniitNoCloud volume source can be configured. All we need to do is preserve the volume name, and override whatever is in the CloudInitNoCloud volume source. Anything else can result in an unusable configuration.

This also removes the need to perform any error checking in this function.

@davidvossel, this is the simpler method than doing a manual three-way merge.
The logic right now is, if there is a volume called "cloudinitvolume" with a non-nil cloudInitNoCloud volume source it will merge the existing one, which has whatever properties configured, with the one setting the same for the bootstrap secret name.

I'm happy to update if you are really sure. The team is requiring this feature as soon as it's possible.

This should be all we need.

if index >= 0 { template.Spec.Volumes[index] = cloudInitVolume } else { template.Spec.Domain.Devices.Disks = append(template.Spec.Domain.Devices.Disks, cloudInitDisk) }

I'm unsure whether that would work, the logic is stating to have either a volume added or a disk.

The current way things work means that

you can bring your custom cloudInitNoCloud and we'll provide the secret, so that current behaviour is preserved but you can optionally use cloudInitNoCloud

e.g: providing custom noCloud networkData

a cloudInit disk will be only added if one doesn't already exist, so that you can specify the type of disk that it is (if I wanted CDROM instead)

and i think that is useful

i'm not following how the mergo usage is necessary to achieve what you previously replied with. I just recommending that the volume be overwritten if the index is known, or appended otherwise.

davidvossel · 2022-12-13T21:11:02Z

pkg/kubevirt/utils.go

+		err := mergo.Merge(&template.Spec.Volumes[index], cloudInitVolume)
+		if err != nil {
+			return nil, err
+		}
+		return template, nil


This should be all we need.

if index >= 0 { template.Spec.Volumes[index] = cloudInitVolume } else { template.Spec.Domain.Devices.Disks = append(template.Spec.Domain.Devices.Disks, cloudInitDisk) }

davidvossel · 2022-12-13T21:13:49Z

pkg/kubevirt/utils.go

+	for i, v := range vmi.Spec.Volumes {
+		if v.CloudInitNoCloud != nil && v.Name == cloudInitVolumeName {
+			return cloudInitNoCloud, i
+		}
+	}
+	return cloudInitConfigDrive, -1


someone could theoretically set a CloudInitConfigDrive volume too. I don't like that this logic is assuming that only a CloudInitNoCloud volume get's the special behavior.

making the default cloudInitConfigDrive is good though

this was the way to provide difference, since there's only two types implement currently.
the logic is extend able to show that other cloudInit types are found. it can be adapted when those are implement

davidvossel · 2023-01-11T22:20:12Z

I'm comfortable merging this once the mergo logic is replaced.

BobyMCbobs · 2023-01-11T23:26:28Z

I'm comfortable merging this once the mergo logic is replaced.

Thank you @davidvossel.
I'm no longer contributing to the project which this relates to, so I'll close it for now.
It may be picked up at a later date by someone else.

k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Nov 29, 2022

k8s-ci-robot requested review from agradouski and qinqon November 29, 2022 02:31

k8s-ci-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Nov 29, 2022

Use nocloud when specified

bbffc37

BobyMCbobs force-pushed the use-nocloud-when-specified branch from d9ac625 to bbffc37 Compare November 29, 2022 03:15

BobyMCbobs added 2 commits November 29, 2022 16:47

Tidy up calling of functions

462b852

Fix default preferred type return

ac04af4

k8s-ci-robot added the ok-to-test Indicates a non-member PR verified by an org member that is safe to test. label Nov 29, 2022

davidvossel reviewed Nov 29, 2022

View reviewed changes

BobyMCbobs added 3 commits November 30, 2022 10:39

Rename func to detectCloudInitVolumeType

fddd38b

Add merge support for existing a noCloud volume

93b760f

Use disk type for cloudinit disk and only insert when not found

57d40f5

davidvossel reviewed Dec 2, 2022

View reviewed changes

k8s-ci-robot assigned davidvossel Dec 2, 2022

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Dec 2, 2022

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Dec 2, 2022

k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Dec 2, 2022

BobyMCbobs added 2 commits December 5, 2022 08:30

Add panic on merge error

f88d6a2

Fix lint

e58acaa

nunnatsa requested changes Dec 4, 2022

View reviewed changes

Handle error in merge and functions above

bb66a2d

k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Dec 5, 2022

nunnatsa reviewed Dec 6, 2022

View reviewed changes

BobyMCbobs added 4 commits December 8, 2022 09:02

Update error handling

6a8fd2b

Update detectCloudInitVolumeType

a621d12

Update detectCloudInitDisk

acd5d10

Update call of detectCloudInitDisk

2dc72b5

nunnatsa reviewed Dec 8, 2022

View reviewed changes

BobyMCbobs added 2 commits December 9, 2022 10:43

Use iota enum for cloudInit type

dc49cec

Update not found return value

c2123db

Fix error handling with merge on nocloud type

e5b4bbb

davidvossel reviewed Dec 9, 2022

View reviewed changes

davidvossel reviewed Dec 13, 2022

View reviewed changes

BobyMCbobs closed this Jan 11, 2023

hh mentioned this pull request Feb 10, 2023

Use nocloud when specified #224

Closed

Use nocloud when specified #212

Use nocloud when specified #212

Conversation

BobyMCbobs commented Nov 29, 2022

coveralls commented Nov 29, 2022 • edited Loading

Pull Request Test Coverage Report for Build 3654098425

💛 - Coveralls

davidvossel commented Nov 29, 2022

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

davidvossel left a comment

Choose a reason for hiding this comment

k8s-ci-robot commented Dec 2, 2022

davidvossel commented Dec 2, 2022

davidvossel commented Dec 2, 2022

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

BobyMCbobs commented Dec 5, 2022

nunnatsa left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nunnatsa Dec 6, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nunnatsa Dec 6, 2022 • edited Loading

Choose a reason for hiding this comment

BobyMCbobs Dec 7, 2022 • edited Loading

Choose a reason for hiding this comment

nunnatsa Dec 7, 2022 • 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

BobyMCbobs commented Dec 7, 2022

nunnatsa commented Dec 7, 2022 • edited Loading

nunnatsa Dec 8, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BobyMCbobs commented Dec 8, 2022

BobyMCbobs commented Dec 9, 2022 • edited Loading

davidvossel 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

davidvossel commented Jan 11, 2023

BobyMCbobs commented Jan 11, 2023

coveralls commented Nov 29, 2022 •

edited

Loading

nunnatsa Dec 6, 2022 •

edited

Loading

nunnatsa Dec 6, 2022 •

edited

Loading

BobyMCbobs Dec 7, 2022 •

edited

Loading

nunnatsa Dec 7, 2022 •

edited

Loading

nunnatsa commented Dec 7, 2022 •

edited

Loading

nunnatsa Dec 8, 2022 •

edited

Loading

BobyMCbobs commented Dec 9, 2022 •

edited

Loading