Write now the type pointer generation is failing (at runtime!)

panic: interface conversion: interface {} is *int, not *int32

goroutine 1 [running]:
github.com/naml-examples/simple.(*App).Install(0xc000391200, 0xc000508000, 0x0, 0xa)
        /home/nova/src/tests/app.go:86 +0xed9
github.com/kris-nova/naml.Install(0x1afcaf0, 0xc000391200, 0xc0004a3bd0, 0x0)
        /home/nova/go/pkg/mod/github.com/kris-nova/[email protected]/cmd.go:386 +0xc7
github.com/kris-nova/naml.RunCommandLineWithOptions.func2(0xc0004d2000, 0x1, 0x1)
        /home/nova/go/pkg/mod/github.com/kris-nova/[email protected]/cmd.go:160 +0x39f
github.com/urfave/cli/v2.(*Command).Run(0xc000391440, 0xc0003fdf40, 0x0, 0x0)
        /home/nova/go/pkg/mod/github.com/urfave/cli/[email protected]/command.go:163 +0x4dd
github.com/urfave/cli/v2.(*App).RunContext(0xc00025bd40, 0x1afc930, 0xc00019a010, 0xc0001a4000, 0x2, 0x2, 0x0, 0x0)
        /home/nova/go/pkg/mod/github.com/urfave/cli/[email protected]/app.go:313 +0x810
github.com/urfave/cli/v2.(*App).Run(...)
        /home/nova/go/pkg/mod/github.com/urfave/cli/[email protected]/app.go:224
github.com/kris-nova/naml.RunCommandLineWithOptions(0x1afcaf0, 0xc000391200)
        /home/nova/go/pkg/mod/github.com/kris-nova/[email protected]/cmd.go:316 +0xf2b
github.com/kris-nova/naml.RunCommandLine(...)
        /home/nova/go/pkg/mod/github.com/kris-nova/[email protected]/cmd.go:51
main.main()
        /home/nova/src/tests/cmd/main.go:42 +0xa5

Looks like this is the culprit

			Replicas: valast.Addr(1).(*int32),

We should fix Valast to do something like this

			Replicas: valast.Addr(int32(1)).(*int32),

Just wanted to say that I really like the project, writing (or templating) YAML is just painful!

Also if anyone is interested, TGIK will be doing an episode showcasing naml on their Youtube channel in 2 days, it will be fun to watch :)

https://youtu.be/ubJ4n_QHs98

Took the example stateless app from https://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment/ and ran it against naml.

[...]
kind: Deployment
metadata:
  name: nginx-deployment
[...]

Ran this through naml:

kubectl get deployments -oyaml | naml c
Error during codify: unable to auto format code: 88:2: expected identifier on left side of :=2021-08-01T18:41:03-07:00 [Critical  ]  unable to auto format code: 88:2: expected identifier on left side of :=

I disabled gofmt to see the actual error and found this:

nginx-deploymentDeployment := &appsv1.Deployment{

We should probably trim illegal characters, though this may in rare circumstances cause a duplicate name. e.g. two deployments on the same system with names nginx-deployment vs nginxdeplolyment

If I understand properly, you're supposed to fork this repo and then modify it to fit your app. GH templates would make it a little bit easier for folks to do that.

I tried running naml codify on an ObjectBucketClaim resource:

apiVersion: objectbucket.io/v1alpha1
kind: ObjectBucketClaim
metadata:
  name: example-obc
spec:
  generateBucketName: example-obc
  storageClassName: openshift-storage.noobaa.io

I was expecting it to fail due to an unknown resource type, but to my surprise it didn't emit any errors. The resulting main.go has no resources (and does not compile).

It would be nice if naml codify would emit an error (and fail) when it is unable to successfully convert the input.

This PR is largely motivated by the contents of https://github.com/knative/serving/releases/download/knative-v1.1.0/serving-core.yaml

There are two issues that still require more work:

1. Template delimiters inside configmap data causes parsing errors with go fmt. Not sure how to handle this at the moment so temporarily replaced double curly braces with quotes to get working output.

apiVersion: v1
kind: ConfigMap
metadata:
  name: test
data: 
  a: |
    # {{ .Name }}

2. Handling multiple versions for a Horizontal Pod Autoscaler. v2beta2 was not replaced with autoscalingv2beta2 for some reason after the alias. Tried to follow policyv1beta1 but might've missed something. https://github.com/GuessWhoSamFoo/naml/blob/4194c5e2352317bfdd1709adf6a47140a0b503f2/codify/codify.go#L40

Saul Nachman12:17 PM
# command-line-arguments
./test.go:31:2: imported and not used: "k8s.io/api/apps/v1" as appsv1
./test.go:32:2: imported and not used: "k8s.io/api/core/v1" as corev1
./test.go:33:2: imported and not used: "k8s.io/api/networking/v1" as networkingv1
./test.go:35:2: imported and not used: "k8s.io/apimachinery/pkg/util/intstr"
./test.go:73:25: undefined: Ingress
./test.go:108:33: client.NetworkingV1().Ingresss undefined (type "k8s.io/client-go/kubernetes/typed/networking/v1".NetworkingV1Interface has

ClusterRole now follows goname pattern that was set in Deployments.

Also extracts goName into its own method for simplifcation.

Signed-off-by: Frederick F. Kautz IV [email protected]

Hi, really fun project, enjoying it so far :). One little thing I noticed; when I merge 2 kubeconfig files in the KUBECONFIG variable, there is hardcoded path searching for config file in .kube dir in this function in client.go

// Client is used to authenticate with Kubernetes and build the Kube client
// for the rest of the program.
func Client() (*kubernetes.Clientset, error) {
	kubeConfigPath := path.Join(homedir.HomeDir(), ".kube", "config")
	return ClientFromPath(kubeConfigPath)
}

giving this error when context is in other file than config:

unable to find local kube config [/home/decoder/.kube/config]: invalid configuration: [context was not found for specified context: default, cluster has no server defined]

Swapping to another cluster (with context present in config) works as expected.

Maybe reading KUBECONFIG variable on a retry when this error occurs would be a good idea?

lets auto generate a makefile as well for our friends

maybe syntax like this

kubectl get deploy -oyaml | naml codify --name=beeps > main.go
naml codify makefile --name=beeps > Makefile
make
./beeps
sudo make install
beeps --help

This project seems to have seen decent traction - perhaps it's worth considering another maintainer?

Anyway @fkautz you seem to be the most active here. Would you be interested in a low-commitment maintainer spot on the project to serve as another place to get things done / merge PRs / review my code / etc?

Hello! Thanks for this wonderful library. I am trying to convert a YAML file that contains a "kind: HorizontalPodAutoscaler" and "kind: CustomResourceDefinition". These are ignored by NAML. Is this expected?

trying to make a basic test

kubectl get job beeps -o yaml | naml codify > main.go

naml build

2022-10-04T16:44:09+02:00 [Warning   ]  ⚠ naml build alpha feature ⚠
2022-10-04T16:44:09+02:00 [Warning   ]  if this is a feature you plan on using please make your use case known in the issue tracker
2022-10-04T16:44:09+02:00 [Warning   ]  ⚠ naml build alpha feature ⚠
2022-10-04T16:44:09+02:00 [Critical  ]  unable to build NAML binary from source:

+-------------------------+---------------------------------
| Codify Compile Failure  |
+-------------------------+
|
|
| # github.com/kris-nova/naml/codify
../../go/pkg/mod/github.com/kris-nova/[email protected]/codify/codify.go:138:3: unknown field 'ClusterName' in struct literal of type "k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta
../../go/pkg/mod/github.com/kris-nova/[email protected]/codify/codify.go:138:33: m.ClusterName undefined (type "k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta has no field or method ClusterName)
+----------------------------------------------------------

Dislaimer: I come from JavaLand. Applolgies if I am reporting something that would be easy to solve for people living in GoLand.

I am trying out NAML to cofify an existing deployment

1. I exported our deployment to yaml first via kubectl get all -n <my_namespace> -o yaml | tee out/all.yaml which resulted in a yaml file with 24031 lines
2. Then I switched to the out folder and converted it to go via cat all.yaml | naml codify > main.go which resulted in a go file with 26986 lines
3. Now that I tried go build main.go I am getting following errors

> naml build -o app
2022-04-25T11:14:16+02:00 [Warning   ]  ⚠ naml build alpha feature ⚠
2022-04-25T11:14:16+02:00 [Warning   ]  if this is a feature you plan on using please make your use case known in the issue tracker
2022-04-25T11:14:16+02:00 [Warning   ]  ⚠ naml build alpha feature ⚠
2022-04-25T11:14:17+02:00 [Critical  ]  unable to build NAML binary from source: 

+-------------------------+---------------------------------
| Codify Compile Failure  |
+-------------------------+
| 
| 
| # command-line-arguments
/tmp/3648555560.go:171:9: unknown field 'i' in struct literal of type resource.Quantity
/tmp/3648555560.go:171:21: int64Amount not exported by package resource
/tmp/3648555560.go:172:10: unknown field 'value' in struct literal of type resource.int64Amount
/tmp/3648555560.go:173:10: unknown field 'scale' in struct literal of type resource.int64Amount
/tmp/3648555560.go:175:9: unknown field 's' in struct literal of type resource.Quantity
/tmp/3648555560.go:179:9: unknown field 'i' in struct literal of type resource.Quantity
/tmp/3648555560.go:179:26: int64Amount not exported by package resource
/tmp/3648555560.go:179:38: unknown field 'value' in struct literal of type resource.int64Amount
/tmp/3648555560.go:180:9: unknown field 's' in struct literal of type resource.Quantity
/tmp/3648555560.go:186:21: int64Amount not exported by package resource
/tmp/3648555560.go:186:21: too many errors
+----------------------------------------------------------

Another thing that was quite strange to me was that NAML generated properties like NodeName: with the node a certain pod is currently running on. Haven't looked further but my gut feeling tells me that it generates code for pods resulting from staeful/daemon/replica-sets which doesn't feel right.

Relevant to #61 we can harden our package management

We can (and should) use reflection to snoop the Kubernetes libraries as needed. We need to get rid of the string lists at the top of codify.go

https://github.com/kris-nova/naml/blob/main/codify/codify.go#L37

Right now we have a problem with vendoring and capturing the compile commands with naml

We can use naml build as a way to vet the code and ensure everything is working as expected