-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
etcdmain: Refactor etcdStart for use in embedding etcd servers #5432
Conversation
This should resolve #5430 |
If you ACK this patch, I'll also send a docs patch with some example usage. LMK. |
1fc2f83
to
8647c18
Compare
FWIW I think the semaphore failure is unrelated to this patch. Something is up with your CI, but travis passed. |
8647c18
to
787d47f
Compare
@xiang90 If someone could review, that would be great! I don't know why this would affect the integration test and cause a fail, but if you or someone could enlighten me on that, I would appreciate it thanks! |
The failure seems to be related to git master btw. Others see it too: eg: #5350 @jonboulle Feel like reviewing? Thanks |
@purpleidea Sorry for the delay. We probably do not have time to review this pull request until early next week. |
@purpleidea those failures (some closed connection handling and election stuff which afaik have both been fixed) are unrelated to this one. Semaphore runs more tests than travis (integration, e2e) via |
@heyitsanthony Thanks for the reply... Do you have any ideas why it would be related to my patch? Maybe fresh eyes would help, but it's supposed to be a straight refactor without a change in behaviour. Thanks! |
@xiang90 With the utmost respect for you and the other maintainers of this project, I don't think that this is a good response to encourage outside contributors. IMO the priority should always be getting the PR count to zero. |
@purpleidea This is not how priority works in this project. We have milestones, and we prioritize things based on the milestone. Bugs and regression issues have a higher priority above all others. Our bandwidth is limited. Also there is no us or community. We are trying to be part of the community. All milestones are public. We are growing our community. At CoreOS, we try our best to review pull requests that are even not on etcd milestones when we have time for the new members of the community. I am telling you that just want you to be patient. The reason is that this pull request involves some "big changes". We need to think care about this. This pull request is not something that I can say a "yes" or "no" in ten minutes. |
@xiang90 I understand, and thank you for your time. It was just my lone opinion on the matter as I am trying to move into becoming a more valuable contributor to the project, and was hoping for more facilitation in that matter. In any case, I'll patiently await some review. Thanks! |
dd67a16
to
3db1bb8
Compare
This patch refactors out the important (and often non-public) portions of etcdStart that need to get run for use in embedding an etcd server. This will allow projects just as `mgmt` (config) to embed etcd without duplicating code, or trailing behind the latest upstream etcd changes.
3db1bb8
to
06fe488
Compare
Sorry for the delay. If I understand the change correctly, it changes the start function to take a list of args instead of only config. Why do we want to accept args instead of config struct? Or what is the benefits of accepting a list of args? |
@xiang90 Sorry for being pushy earlier and thanks for looking into this. Yes, it tries to abstract away the common things that are normally done in This way a user can run the equivalent of I decided to pass in the few needed values as args to avoid creating yet another struct, but I'm happy to rewrite this to use a struct if you're happy with the idea. Thanks, |
@purpleidea I am wondering if we can add a helper function call defaultConf or something to generate a pre-filled conf struct. That seems to be a simpler approach to solve the copy/paste problem you have. |
@xiang90 I cannot find a 'defaultConf` struct in the current code base, so perhaps I misunderstand. The way you can invoke this now with this patch is like:
Which should effectively stay portable. As you mentioned, if you don't mind another struct, then it could make sense to pass that into the helper method instead of the list of params. With this approach, you still want to specify your own ServerConfig as shown here. Let me know how you'd like me to proceed. Thanks! |
@xiang90 Thinking about this more, I realize this should probably be renamed to ConnectionHelper or similar, since it deals with setting up and running the tls and connection stuff. That's easy to do as desired though. |
...So yeah if you like the idea, I would probably rewrite it to have the |
@purpleidea Why not just use today's startEtcd(cfg) in your program? func startEtcd(cfg *config) (<-chan struct{}, error) |
Two reasons:
|
@purpleidea Yea. So my suggestion was to make it public and have a helper function to construct the configuration. Then we do not have to change the implementation of startEtcd. |
On Tue, Jun 7, 2016 at 5:05 PM, Xiang Li notifications@github.com wrote:
The config that gets passed to it is highly dependent on things like flags |
Creating a clean cfg for startEtcd. Embedding that conf struct into today's config. |
Sorry, can you elaborate please? |
I agreed that the current config struct is bad for startEtcd, just as you mentioned. The main problem is that tt contains flagset, which is unnecessary. It also contains some proxy related stuff, which is also unnecessary. I would suggest to have another cfg struct for StartEtcd, which is clean and does not contain flag set. |
@xiang90 Now that I understand, I agree. While I think this would be more correct, I'm not sure that it would necessarily be more useful, since the only parameters you need to set if embedding etcd are the seven or so I mentioned for the connecting handling, since everything in As a result, would you consider reviewing a reworked patch that uses your connection struct idea? I think it would solve most use cases without needing to copy values between three structs. |
After we got that clean cfg, we can pre-fill some of the common fields. So normal user can just fill in the field that they want to customize like connection related. |
I don't really know how to write this, particularly all the places it would touch and how the flag stuff works. If you're able to start this, I'm happy to fill in all the blanks to make it work.
What about this? Interested? I can cook it up now. |
I feel this is not as clean as I would like it to be. I can work on the the clean conf idea later this week or so. |
Let me know how I can help! |
I will close this patch because of the improved version in #5584 |
This patch refactors out the important (and often non-public) portions
of etcdStart that need to get run for use in embedding an etcd server.
This will allow projects just as
mgmt
(config) to embed etcd withoutduplicating code, or trailing behind the latest upstream etcd changes.