Follow conventions when creating objects

[redbaron]

It seems that shape of the object produced by individual
jsonnet library set to be following:

{
  hidden:: { ... }

  component: {
    resource1: { apiVersion: ... , kind: .... },
    resource2: { apiVersion: ... , kind: .... },
  }
}

so that std.objectFields(obj) returns an object
made of kubernetes object to apply.

Hidden fields are then can be used for cooperation
on values, such as _config::

This commit brings produced output in line with convention above

[redbaron]

hm, is Travis CI webhook stuck?

[brancz]

Last time I checked lists couldn't be nested, which is why we did what we did. Has this changed recently?

[redbaron]

Yes , change is that now it is not a JSON array, but a single Kubernetes 'kind: List' object

…

-------- Original Message --------

On 28 May 2019, 13:36, Frederic Branczyk wrote: @brancz commented on this pull request. --------------------------------------------------------------- In [README.md](#67 (comment)): > [ + grafana.dashboardDefinitions, Last time I checked lists couldn't be nested, which is why we did what we did. Has this changed recently? — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#67?email_source=notifications&email_token=AAAEB4FKACA6ZICHSXVLPFTPXURNRA5CNFSM4HOWR4XKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOBZ3FV5Q#pullrequestreview-242637558), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AAAEB4H7I2HGSLUWVLQVVPLPXURNRANCNFSM4HOWR4XA).

[redbaron]

see here, it used to be a [], but now a single { kind: ConfigmapList, items: [] } object, it allows embedding it

[brancz]

right, but when you render out a kind: List, does kubectl actually create deep lists recursively?

[redbaron]

Doesn't seem so. See same transformation in kube-prometheus:

https://github.com/coreos/kube-prometheus/blob/3fbc968930c2fef025470c59060d25635070f8e7/jsonnet/kube-prometheus/kube-prometheus.libsonnet#L18

kubectl seems to flatten kind: List items, at least one level deep for sure. here we are exactly one level deep, so should be fine

[brancz]

That only works because what is generated is not a List object but a directory of objects, where one of the files happens to be a ConfigMapList, so for kubectl the ConfigMapList is actually the top level item.

[redbaron]

let me run few tests, I'll come back to you

[brancz]

correct :)

[redbaron]

"library" object should still have "standard" shape:

{ key: { kind: ... } }

to make it easier to use it in other jsonnet deployments.

it is only examples which need to change. I can go with

local grafana =
  ((import 'grafana/grafana.libsonnet') + .... ).grafana;

local flatten(lst) = std.foldl(function(acc, r) if ! std.endsWith(r.kind, "List") then acc + [r] else acc + r.items, lst, []);

k.core.v1.list.new(flatten([grafana[k] for k in grafana]))

what do you think?

[brancz]

yeah, I quite like that

[redbaron]

Another approach would be to return plain array and change exampes to call jsonnet --yaml-stream.

Either way output is pipeable into kubectl . Which one do you prefer?

[brancz]

I think I prefer the first, as that way when people want to they can still make use of the *List types for grouping, in the way I think it's good that the dashboard configmaps are currently grouped that way.