Possible new direction for sensu-salt

[perlchild]

Allow me to introduce myself, I'm Eric Robibaro, I work for AppDirect in the fair city of Montreal.
Earlier this week, I volunteered to write a saltstack formula for sensu 2.0 when it lands.

What does this have to do with anything you ask?

Glad you asked.

Sensu has two saltstack formulas.
Neither of them seem very actively developed, nor include the developer friendly features that the saltstack-formulas organisation usually requires.

http://salt-formulas.readthedocs.io/en/latest/develop/testing-formulas.html especially, would be nice to have.

There was a team discussion that started on slack about what we would need to do, and how best to approach this. I'm opening up this issue to start this dicussion.

• We need to resolve the conflict with two repos having different contexts, and different approaches to configure the same software
• We need to address the lack of testing
• We would do this while preparing for sensu community 2.x becoming GA
• We need to establish the use case of the resulting formula(is the default case a multi-machine setup? I propose that it should be, for instance)
• Do we want to use SPM? How useful are they, in the context of plugins, do we need a spm for each sensu plugin? Would we use a jinja templated approach, possibly using pillars?
• What are sane defaults, in this context? Do we fall back to everything on one machine, or do we exclude it (I've had at least one case in my career where each component having to run on seperate machines made the code much simpler, so let's discuss this)
• Any other concerns about the new salt formula

[x70b1]

I think a repo with two branches is a good idea as @majormoses suggested.
First of all, it will be important to determine the current status of the formular.

The existing form seems to use a separation. I like that!
saltstack-formulas/sensu-formula#available-states

[majormoses]

I'd vote for a branch called sensu-2.x to differentiate that this is for sensu 2.x and not the 2.x of the formula version which may or may not happen to align.

A broader question is about this repos formulas and sensu version support. I assume at this point that there will be need to make some changes that makes them uncompatible. Even if that is not true we need to assume at some point this will be true. From my experiences with version support on larger projects it is not someone is going to migrate within a short period of time after the next generation of sensu is GA. I think we should probably do something like this:

• 6 months of adding features, after this period ends the the master branch would be renamed sensu-1.x and the sensu-2.x branch would be renamed to master and made the default branch.
• 12 months of supporting existing use cases, bug fixes only. This includes the previous 6 months of adding features.

This is a much further thinking strategy and more closely resembles how larger projects handle these types of situations. It might be overkill but that is my $0.02 on how to handle a difficult transition. This is how I imagine I will handle the chef cookbooks, we have a WIP branch called next_gen just to play around with but as that becomes something more than a playground we will use what I proposed here. I am not sure how we will handle plugins as there is still quite a bit of unknowns on how the asset pipeline will end up working so I make no promises there.

[majormoses]

I don't know a ton about salt so I will try to keep my comments to higher level and allow people who know what they are talking about to debate the implementation details without making assumptions that it works like chef, puppet, ansible, etc.

We need to resolve the conflict with two repos having different contexts, and different approaches to configure the same software

IMHO we just need to choose a direction and fix one of them to be the "official" one and when we are ready work on deprecating the old one with links and deprecation tags. We can also make announcements via blog posts, google groups, and in slack to all users (which thankfully requires admin perms to avoid abuse).

We need to address the lack of testing

Super important! I'd suggest using test-kitchen, kitchen-(docker|dokken), and serverspec as that is what we use on chef, sensu-plugins, and ansible is also starting to adopt it.

[mbbroberg]

Note that Sensu Core 2.0 is public and available here: https://github.com/sensu/sensu-go

It may be a little light on API documentation atm. Take a look when you get a chance and we can see what needs to happen at this stage of the game.

[mbbroberg]

Note that, during this temporary transition period, two separate branches is right move imo. We're working on general practices for CM projects over here: sensu-plugins/community#103