Configuration Management + Sensu Core 2.0

[mbbroberg]

Update

After thoughtful discussion on the naming convention of repositories and packages, and considering how version numbers is NOT good to instantiate in names, I'm shifting recommendations to be around.

---

With the open sourcing of Sensu Core 2.0, we have a lot of excitement around deployment options. I'd like to propose we follow some convention across each project to get there. Initial idea:

• Every project starts a sensu2-compatibility branch
• Each project, if maintainers use milestones, create one called Sensu Core 2.0 Compatibility
• Any issues that are specific to the project are created and added to the milestone.

Wdyt everyone?

Pulling maintainer info from the README + the TODO of adding our SaltStack maintainer:

Area	Major Links	Maintainers	Needs Contributors?
	Puppet Module	Garrett (@ghoneycutt) - Lead	Yes! Help review issues.
	Chef Cookbook Uchiwa Cookbook	Ben (@majormoses) - Lead Tom (@thomasriley)	Yes! Help review issues.
	Ansible Role Ansible Module	Jared (@jaredledvina) - Lead Chris (@cjchand) Calum (@cmacrae)	Yes! Help review issues.
	SaltStack Formula	Eric R (@perlchild)	Yes! Please volunteer.

[majormoses]

I think this is a good idea and aligns with what I outlined in saltstack when discussing the go forward path with the maintainers. I think we need to call out our support plan. Moving from 1.x -> 2.x will not be a smooth transition for most people and I would expect we will need to continue to support both 1.x and 2.x solutions for a while.

As originally proposed I think that we should create a new branch called sensu-1.x from master, and create a sensu-2.x branch either from master or blank branch with nothing on it. Additionally I would encourage renaming the cookbooks, playbooks, formulas to sensu2 so that we can follow semver without having conflicting versions between two different products. We will want to add messaging around this and do a full major version upgrade so that anyone pulling master but pinning on specific versions will be unaffected. At some point master will be the branch that becomes the equivalent of "development" for sensu-2.x branch. Now to the main point I was going to make is that we need to support them both for a while. I think that we should take an approach like this:

• 6 months of feature development of sensu-1.x after sensu 2 is GA
• 6 months of additional of bug fixing of sensu-1.x which leads to a total of 1 year of support on sensu-1.x

After the first 6 months we would make master the pre-release branch for sensu-2.x and any sensu-1.x work would be made directly to the release branch. At that point we would no take a stance of not putting any more effort into supporting sensu-1.x but would allow reviewing of bug and security fixes only from the community, no features allowed period.

An alternate approach would be to create new repos such as sensu2-chef and start from scratch this eliminates many of the extra complexity but the same support principles would apply. I think this is probably the better approach IMHO even though I originally proposed the first idea.

[thomasriley]

An alternate approach would be to create new repos such as sensu2-chef and start from scratch this eliminates many of the extra complexity but the same support principles would apply. I think this is probably the better approach IMHO even though I originally proposed the first idea.

I find that it does tend to be easier to develop in a greenfield space, so it is a +1 from me on creating a new repo. Makes it easier to support & release both versions side by side removing any complexity explained above (until the support for sensu 1.x expires as explained above by Ben).

[mbbroberg]

@thomasriley @majormoses good points. Let me review what @portertech had planned - he was hacking on Chef work as well - and circle back here today.

[mbbroberg]

@majormoses @thomasriley I just created sensu-go-chef with a few heads up to keep in mind:

• We may rename the repo based on packaging naming decisions
• If at some point in the future we there is sponsored support for the repo, non-maintainers might make more design decisions

With that in mind: https://github.com/sensu/sensu-go-chef

[mbbroberg]

Note the update to the description - separate repos that align to the sensu-go repo name is a good first step. No one here is required to work on it of course, but let me know if you're interested and I'll link you into plans coming out of Core engineering team.

[x70b1]

@mbbroberg this means the new standard is sensu-go-*? Did I understand that right?
Another example: sensu-go-salt? I'm asking for a friend. 😎

[majormoses]

That is the current go forward naming convention which is currently something that I consider still up for debate and subject to change as we are still in alpha.

[mbbroberg]

Hey @x70b1! Yes, that's the plan for now. I'll update this issue as we evolve the plan, but this plan is solid for our Alpha phase right now. Specifically talking about Salt, if you're ready to go and @perlchild doesn't mind, I could setup the new repo for you two as well 🙂. Wdyt?

[x70b1]

It was just so that I could understand. I think if we actually need the repo, we'll let you know.

[jaredledvina]

I think we're alright here, looking forward we have the following as of today:

Ansible

• Sensu Core: https://github.com/sensu/sensu-ansible
• Sensu Go: https://github.com/sensu/sensu-go-ansible

Chef

• Sensu Core: https://github.com/sensu/sensu-chef
• Sensu Go: https://github.com/sensu/sensu-go-chef

Puppet

• Sensu Core: https://forge.puppet.com/sensu/sensuclassic
• Sensu Go: https://github.com/sensu/sensu-puppet

SaltStack

• https://github.com/sensu/sensu-salt - Unsure as to the status here, I've never used SaltStack.

I'll close this out for now, feel free to reopen if anyone feels that there's still work to do here.