Open perlchild opened 6 years ago
x70b1
commented
6 years ago 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
commented
6 years ago 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:
sensu-1.x and the sensu-2.x branch would be renamed to master and made the default branch.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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago 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: https://github.com/sensu-plugins/community/issues/103
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.