Sensu-go: Consistent sensu <resource> import UX

[grepory]

For all import commands, we want to import the configuration from a file or STDIN and output a config file and/or errors. Should we make this a "best effort" import, write what we can, and then emit errors for checks that cannot be imported to STDERR?

Alongside this, also add an optional flag for create that reads from a file (and supports the creation of multiple objects).

[palourde]

@grepory So just to make sure I understand, right now we have the sensuctl import command, that imports 1.x resources from STDIN/files, and directly create them into 2.x.

Are we talking about splitting that command into multiple subcommands (e.g <resource> import) or simply modifying the current import command so it outputs files instead?

[grepory]

Capturing what we said in our convo:

I think we should have sensuctl import that spits out files with individual resources, organized in a way that makes sense. E.g.

sensuctl import myconfig.json would create a directory structure like (org name)/(env name)/checks/(id).json. Those individual JSON files could then be used with sensuctl check create --from-file <path>.

The intermediate representation gives users the opportunity to edit and modify what we asserted they wanted. They can update their eval statements. Etc.

[calebhailey]

I'm not sure if this ticket is primarily about support for Sensu 1.x configuration, or just Sensu2 configuration in general, so this comment may be misplaced, but I'm leaving it here for posterity. 😃

For alignment with a large part of our target audience (i.e. kubernetes users), I have hoped/imagined this could look almost exactly like the kubectl UX, where a configuration file may contain the reference to the resource type (e.g. kind: Deployment, kind: Service, etc):

$ kubectl create -f filename.yml

In the case of Sensu2, the resource types would obviously be different (e.g. kind: check, or kind:handler, etc), but in theory the UX could be the same. 🙏 😄

$ sensuctl create -f check_definition.yml

<3

[echlebek]

@calebhailey,

I think that would be a good way to go, and should be workable within the existing system. I think a PoC could be developed pretty quickly.

[echlebek]

We met about this issue, and discussed how the import should work. The conclusion we came to is that we should adopt a sensuctl create -f type command, and then make the import tool generate a file that we can use with this.

So this task is now blocked on #1056.

When implementing this work, we need to be able to traverse a Sensu 1.x resource directory, handling fragments the way that Sensu 1.x does.

Sensu 1.x can deep-merge resource fragments, and does so with this logic: https://github.com/sensu/sensu/blob/44dc4263021782728c0d12b24f57c4cefd8e9360/lib/sensu/utilities.rb#L33-L52

The logic is tested here https://github.com/sensu/sensu/blob/master/spec/utilities_spec.rb#L27-L64, and some larger-scale loader tests are here: https://github.com/sensu/sensu-settings/blob/master/spec/loader_spec.rb

It will take some careful work to correctly implement this merging in Go, but should largely be mechanical work, given that we implement the tests correctly. :smile:

[calebhailey]

The conclusion we came to is that we should adopt a sensuctl create -f type command, and then make the import tool generate a file that we can use with this.

Love it!

[palourde]

Closing that in favour of https://github.com/sensu/sensu-go/issues/1056