Enhance development experience of k8s-nmstate operator with Tiltfile

[sanjay7178]

Problem : The current development workflow for the nmstate operator involves multi-step Make targets, slow container builds, manual manifest regeneration, and re-deployment. This results in slow iteration and developer friction.

The current workflow (make cluster-sync) is slow:

• Build images → Push to registry → Generate manifests → Deploy → Wait
• Takes 2-3 minutes per code change
• No live reload or unified view of logs

Introduce a Tiltfile to accelerate development and enable fast inner-loop workflows:

Solution : Tiltfile that provides :

• Live code updates and see changes in 5-10 seconds
• Automatic Container rebuilds happen when Go fiiles , Dockerfiles and manifest changes
• Tiltfile Also shows the logs . build status and resource health
• Also provides port forwarding for easier debugging
• Integrates with existing kubevirtci local cluster setup

References :

• Tilt Documentation
• Similar projects: kubetail, cluster-api
• Openfaas blog on tilt

[qinqon]

@sanjay7178 can you prepare a PR to see how it looks ?

[sanjay7178]

Sure

[mkowalski]

Sorry for direct question but can you confirm that you have written this issue yourself and that it is not AI-generated?

[sanjay7178]

@mkowalski yes , I've used openai codex cli , but it's for testing and proof of concept . I rather have an experience working with tiltfile in my side project .

Tiltfile directly has support kind and k3d , which you can build operator or any other docker images based on local changes to kind/k3d k8s cluster directly without a local/remote registry .

Currently when i was using nmstate-k8s with existing makefile targets , I feel the bash scripts aren't OS native and I need to setup quay.io/local registry to push build operator images and pull them in test cluster using make cluster-sync .

Before contributing to helm chart issue I need to get familiar with this project , so I dig into it , I checked with make cluster-up which I feel kubevirtci/k8s image doesn't make sense to me , the image way too bulky to pull at first , So I did a research with codex , then I did setup my own bare metal rke2 cluster through kcli with fedora 42 base image , tested the tiltfile (automatically installs the operator), ran current operator testing manifests and it's works like a charm

[sanjay7178]

The only exception while we're working with bare metal clusters , to develop this operator , unlike kind/k3d support , tiltfile can't push the built docker images directly to cluster to sync , instead to use a local/remote registry and sync in the cluster (tiltfile automatically does this workflow seamlessly) .