Support toggling provisioning checks

[ekarlso]

cf #183

Testing performed:
Added / adapted tests

[wikkyk]

@ekarlso I edited your comment to remove the word 'fixes' as otherwise merging this PR would close the issue prematurely.

[mcbenjemaa]

There is still failing tests

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
90.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[ricottatosta]

Dear IONOS Team,
I believe this is not the right way to address all the issues around cloud-init and Talos. And the way it will be addressed also involves flatcar support in some way.
Talos image can get qemu-agent via custom image, so it needn't to check it. But if there is any other issue regarding the agent, it can be addressed.
The problem involving cloud-init and Talos is related to cloud-init datasource. Up to date, any os running in a vm must expect network-config to be in cloud-init netplan format and must install cloud-init binary.
On the other hand, Talos expects network-config to be in cloud-init nocloud format and has no cloud-init binary installed.
Flatcar has another config file format, in json if I'm not wrong.
For all this reasons, I think all these issues should be addressed more schematically, maybe using a schema like this in proxmox_machine_type.go:

spec:
  config:
    engine: cloud-init|flatcar
    flatcar: {}
    cloudInit:
      dataSource: netplan|nocloud
  qemuAgent: true|false

With this new arrangement in place, it should be possible to address all the issues around that involve both reconciliation activities and engine config format in general.
I have started forking your project in order to be able to create a Pull Request. If you are interested in my idea, I will try to arrange the code. But be aware, I'm less than a newbie at GoLang. It will need a review.
I hope you will change your mind.

[mcbenjemaa]

Hey,
your Proposal is nice
but we need to keep things in mind,
in debian-based os, we check cloud-init status via the qemuAgent.
so we need a way of skipping such a check.
in flatcar we can run qemuAgent but not cloud-init.

spec:
  config:
    engine: cloud-init|flatcar
    flatcar: {}
    cloudInit:
      dataSource: netplan|nocloud
  qemuAgent: true|false

here is some of my notes:

• Having qemuAgent field is great
• config.engine is also nice. however we can also check that based on generated bootstrap data.
• config.cloudInit.dataSource I don't know why you need such a field, please explain.

However, can you also explain how we can actually implement the cloud-init checks and Qemu and under which conditions?

Finally, a word of advice, please create a new issue and start a discussion around the API additions or changes in the issue, before starting the PR,
you need the API approved, so you don't change it when you start the PR.
we would appreciate your contributions.

[ricottatosta]

If you want to leave the world as is, the only issue to solve to let Talos do its work with capmox is the value of networkConfigTPl constant in pkg/cloudinit/network.go file.
Netplan expects it to start as follows:

const (
	/* network-config template. */
	networkConfigTPl = `network:
  version: 2
  renderer: networkd

Nocloud expects it to start as follows:

const (
	/* network-config template. */
	networkConfigTPl = `version: 2
renderer: networkd

Routes section should be written as follows:

{{- define "routes" }}
  {{- if or .Gateway .Gateway6 }}
    {{- if .Gateway }}
    gateway4: {{ .Gateway }}
    {{- end }}
    {{- if .Gateway6 }}
    gateway6: {{  .Gateway6  }}
    {{- end }}
  {{- end }}
  {{- if .Routes }}
    routes:
  {{- range $index, $route := .Routes }}
      - {
      {{- if $route.To }} "to": "{{$route.To}}", {{ end -}}
      {{- if $route.Via }} "via": "{{$route.Via}}", {{ end -}}
      {{- if $route.Metric }} "metric": {{$route.Metric}}, {{ end -}}
      {{- if $route.Table }} "table": {{$route.Table}}, {{ end -}} }
  {{- end -}}
{{- end -}}

and the rest of the string should be rearranged accordingly in terms of indentation.
With this in mind, you could rearrange proxmoxmachine spec as follows:

spec:
  checks: {}
  cloudInitFormat: netplan|nocloud

and check for the format before creating NetworkConfigData.

[mcbenjemaa]

@ekarlso
Is that the case?
I thought the network-config v2 works well in your setup.

@ricottatosta Open new issue, and let's discuss there.

[ricottatosta]

#51