Possibility to apply single lib/object?

[strowi]

Hi,

still progressing building our stack with tanka.;) I opted to create separate /lib/*-folders for deployments like rabbitmq/redis/haproxy etc.
E.g.: lib/haproxy will contain sth. like:

{
  haproxy: {
    namespace:
      k.core.v1.namespace.new('haproxy-controller'),

    controller: {
    ...

Instead of having to specify every k8s-object beneath this with "-t configmap/haproxy1 -t deployment/haproy -t ....", is there a way to apply a single lib/object (which is usually what you want during testing)?
I know in k8s i can usually just apply all, but for testing this sometimes takes time and requires some rollover of deployments etc..
So it could be really useful and a timesaver to apply only this 1 object.

regards,
strowi

[julienduchesne]

You mean that you would want to eval a single attribute (haproxy), and apply/diff that? If so, I think that's possible. It may just be a matter of moving some logic down from the eval command (-e option) to the show, diff and apply commands

[strowi]

Sorry about mixing up the wording, but yes.
I think it is more natural if you want to test 1 application you'd also need the configmap, secret etc.. (and not even thinking about helm-charts) - so it would make sense to allow only diff/apply.. 1 attribute and everything beneath.

[Duologic]

I think you want a separate Tanka environment per application, then you can do this much simpler.

[strowi]

In an ideal world definitly @Duologic , But this is a bigger "app" comprised of lots of services, that currently is being migrated from a rather monolithic docker-swarm to kubernetes - which involves a handful of other problems (initalisation of services, one service cant work without the other, etc..). Therefore we decided to migrate first and split it up later.

[jmgilman]

Currently, I've resorted to commenting out specific attributes to emulate this behavior. It's not a great UX. Resorting to one environment per app breaks the design philosophy of one environment per folder (unless you can nest them, I haven't attempted this yet).

Is there an alternative I'm missing here?

[strowi]

@jmgilman Haven't found one so far. I really like to see @julienduchesne idea of specificy an attribute or attribute-path.
Then it would be possible to apply complete sub-paths for each app an run like 'tk apply environment/test -p toplevel.app1`.

[zerok]

@strowi Would it perhaps help if you use inline environments and have those components that you want to apply in one env while all the rest somewhere else for now?

[strowi]

@zerok this is a bit connected to #801, for now i've resorted to prefixing all resources with their name (should've done that from the beginning ;)).
I guess i could create different "sub-environments" and import all those in a "top-level" environment (basically a 2nd layer of libs).
Will test this out, but it seems to require some work to restructure this (also not sure yet how this would work with vars defined in 1 sub-env, but not the other).