Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document project roadmap and contribution stance #15

Open
adamkennedy opened this issue Oct 24, 2016 · 3 comments
Open

Document project roadmap and contribution stance #15

adamkennedy opened this issue Oct 24, 2016 · 3 comments

Comments

@adamkennedy
Copy link

I'm looking at using Inviso for our clusters, but since it's been about 2 years since there was any notable changes there are some obvious concerns about the status of the project.

It would be useful if you could document (in the README.md file?) what the roadmap and status of the project is (have there been further changes at Netflix that are yet to be released? Has there literally been no changes in this time?) and what the project's stance towards contributions is.

@danielcweeks
Copy link
Contributor

@adamkennedy We've been running Inviso internally at Netflix since well before the release and it is largely unchanged from the initial release.

The only feature we recently added that hasn't made it back into the OSS version is the ability to see pending app/user/queue container requests in addition to the existing running ones that inviso shows now. If there's interest in that, I can push those changes as well.

Most of the known issues are related to getting Inviso setup in certain environments and you can see some of that in the current open issues. Probably the biggest issue is that Inviso won't work out-of-the-box with ElasticSearch 2.x due to the incompatibility of the mapping property names, but it appears one user found a workaround for that.

As with almost all OSS projects, we're happy to receive contributions. If the change is substantial, it might be good open an issue to discuss it first.

@adamkennedy
Copy link
Author

It would be nice to have that, we tend to burst a lot.
It would also mean any branches we worked on would be less likely to clash with internal work there when the time comes to merge.

@danielcweeks
Copy link
Contributor

danielcweeks commented Oct 25, 2016

Sounds good. I'll try to get the changes pushed in the next few days and an update to the docker file, so you can test it out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants