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

[0.9.3-master] bad wiretype for field internal.Field.Type: got wiretype 2, want 0 #3831

Closed
johnstall opened this issue Aug 25, 2015 · 7 comments
Labels

Comments

@johnstall
Copy link

I installed and built influx 0.9.0 on a mac OSX Yosemite 10.10.3

when I run influxd command, I get this error

run: open server: open tsdb store: failed to open shard 2: load metadata index: proto: bad wiretype for field internal.Field.Type: got wiretype 2, want 0

This is the total output.

no configuration provided, using default settings

[metastore] 2015/08/25 11:52:53 Using data dir: /Users/me/.influxdb/meta
[metastore] 2015/08/25 11:52:53 Skipping cluster join: already member of cluster: nodeId=1 raftEnabled=false peers=[127.0.0.1:8088]
[store] 2015/08/25 11:52:53 Using data dir: /Users/me/.influxdb/data
[metastore] 2015/08/25 11:52:53 Node at localhost:8088 [Follower]
[retention] 2015/08/25 11:52:53 retention policy enforcement terminating
run: open server: open tsdb store: failed to open shard 2: load metadata index: proto: bad wiretype for field internal.Field.Type: got wiretype 2, want 0
@otoolep
Copy link
Contributor

otoolep commented Aug 25, 2015

The software has moved on quite significantly since 0.9.0. I strongly suggest you build master or the 0.9.3 branch.

@beckettsean beckettsean changed the title bad wiretype for field internal.Field.Type: got wiretype 2, want 0 [0.9.0] bad wiretype for field internal.Field.Type: got wiretype 2, want 0 Aug 25, 2015
@johnstall johnstall changed the title [0.9.0] bad wiretype for field internal.Field.Type: got wiretype 2, want 0 bad wiretype for field internal.Field.Type: got wiretype 2, want 0 Aug 25, 2015
@johnstall
Copy link
Author

That actually was built from Master. In the terminal client, it said version 0.9, so I assumed it was 0.9.0, however, git branch revealed it to be built from master. Anyways, I thought it must be only my Mac that couldn't build your software properly but five other developers in the office (using the exact same system i.e. OSX Yosemite 10.10.3) had the same problem, and we therefore called it quits on your software. Sorry, not being able to even start your software we felt you weren't ready for our needs yet. Good luck.

@beckettsean beckettsean changed the title bad wiretype for field internal.Field.Type: got wiretype 2, want 0 [0.9.3-master] bad wiretype for field internal.Field.Type: got wiretype 2, want 0 Aug 25, 2015
@beckettsean
Copy link
Contributor

@johnstall any reason you needed to build from master rather than using a pre-built (tested) package? Actual point releases have homebrew packages for installation.

@johnstall
Copy link
Author

Sorry for the delayed response, as I am not a normal Github user.

First off, it's always preferable (in my opinion and that of the team I work with) to install from source and it'd be a definite warning sign if I had to install via a package manager

In this particular situation to help you understand better, my team has three analytics-type projects in the immediate pipeline where using Influx was one possible alternative, however, it was never the likely choice as someone we trust felt that while its speed had improved, it still wasn't stable (in terms of both api, but more importantly being unable to keep data in a consistent state and crashes), however, due to the creator of Influx being familiar to one of our team members we decided to consider it. In this context, when the team sat down to explore tech stack alternatives for the first of our three projects, the fact that nobody on our team (all experienced developers) could get it to start made it an easy decision for us not to use Influx for this project at least. After wasting about 10 or 11 total developer hours reading the docs and trying to get Influx to start without crashing, it didn't seem like a good investment of time to install a package manager to install a piece of software we were considering.

We have since made decent progress in a short period of time with one of the alternatives we were considering, so there's no need for us to consider installing Influx via package manager.

Perhaps most importantly for us, the clients we work with sometimes use our source code as a blue print for developing projects using their internal teams (i.e. if they don't want to pay our more expensive rate). Therefore, our technology choices need to be rock solid and, leaving aside the fact that I don't use a package manager myself, I would never feel comfortable telling a client that it had to install a crufty package manager to get the software started (in addition to other potential issues with Influx being < 1.0).

Anyways, I hope that helps you assess the state of your project. on our team's internal tech radar, we have moved Influx from "something to consider" to "definitely not ready yet." We might consider using it for a future project, but being able to install and start it without jumping through hoops is a definite must for the reasons stated above.
Regards,
J.S

@beckettsean
Copy link
Contributor

Thanks for the detailed note, @johnstall. I can understand you don't want to use a package manager for production installs, but you obviously aren't going to be running in production on OS X. Why not try building from source on the actual production OS?

As for building from source, there's building from HEAD and then building from a known and tested branch or tag. Taking HEAD is always riskier than going with an actual GA release, even if you build from source rather than use a package manager.

Lastly, if you had build or launch problems with InfluxDB we would love to see those stack traces or errors. We don't have any other reports of build issues on OS X so it's possible you've found a novel bug. This one we cannot repro so far, can you give us more detail on how you built the package?

@iorlas
Copy link

iorlas commented Aug 26, 2015

Seen this on HN. I'm sorry, but woah that was strong, @johnstall.
I really don't understand why you need to build everything from sources(do you use gentoo linux for production or what?). Software development by it's nature is an evolving thing, which has versioning to "give product". You can't just say "I need only fresh sources right from developer sticky fingers" because this could even not compile into something which works.
So, you can grab some TAG or VERSION and compile it. Or just install compiled binaries from your OS package manager(LTS releases are considered STABLE and SUPPORTED, so why not?). Also, there is a docker image for influx, which makes everything so much easier.
And... dude.

in addition to other potential issues with Influx being < 1.0

Have you ever heard of semver? You should definitely read about it, it will give you a reasons why we have so many software solutions in "<1.0 state"

@pauldix
Copy link
Member

pauldix commented Aug 26, 2015

I should mention that our standard is that master should always be build-able and tests should pass. We use continuous integration and pull requests to help ensure this.

I personally build Influx on Yosemite many times per day. I also recently had to do it on a brand new laptop because my previous one was stolen. Getting InfluxDB building and running took less than an hour, which included installing homebrew, xcode, go, git, and then building the actual project.

I hadn't done this from scratch in a very long time so I actually just followed the instructions on the CONTRIBUTING.md doc. It worked without a problem.

Is the software early? yes. Is completely non-functional and not build-able? absolutely not.

When people hit problems with an open source project, they can help in one of two ways: report an issue with steps to reproduce the problem, or (even better) submit a PR with a fix.

Everything else is just noise and doesn't help advance the state of the project.

@pauldix pauldix closed this as completed Aug 26, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants