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

Replace chef-solo with chef-client --local-mode functionality #54

Merged
merged 2 commits into from Nov 13, 2014

Conversation

@jtimberman
Copy link
Contributor

@jtimberman jtimberman commented Sep 14, 2014

No description provided.

@jtimberman
Copy link
Contributor Author

@jtimberman jtimberman commented Sep 14, 2014

Paging @jkeiser

Loading

@tas50
Copy link
Contributor

@tas50 tas50 commented Sep 15, 2014

It would be really great to fully replace Solo with Local Mode, but there really needs to be support for roles/environments in .RB format before this can be done. A lot of people out there (like me) have all their roles/environments in RB format and Chef Zero can't parse them.

chef/chef#1641

Loading

@mivok
Copy link

@mivok mivok commented Sep 15, 2014

To what extent do we want/need to preserve existing chef-solo behavior after changing the underlying implementation? One thing I'm immediately thinking of is that chef-solo doesn't persist node data, and I'm aware of at least one chef-solo workflow (using git pull on individual servers and passing in -j nodes/nodename.json on the command line) where changing files on disk would be problematic.

I'm very much 👍 on the idea of local mode in place of chef-solo, but the behavior between the two is slightly different. We'll need to identify those differences, then decide where to change the behavior of chef-solo to match local mode and where to change the behavior of local mode if called as chef-solo (perpetuating some of the issues with differing behavior that prompted this RFC in the first place). Perhaps changing the behavior of chef-solo but documenting how to make it behave (almost) exactly as it used to will be the best option here.

Loading

@lamont-granquist
Copy link
Contributor

@lamont-granquist lamont-granquist commented Oct 4, 2014

I tend to doubt that we're going to get perfect API compatibility out of chef-zero and that the better step would be adding a WARN to chef-solo that its functionality was deprecated and community supported only and that users should migrate to chef-zero. Then we do need to solve issues that come up in chef-solo to chef-zero migrations, but right now with chef-solo users largely not having this issue on our radar we only know what a few big ones might be.

Loading

@coderanger
Copy link
Contributor

@coderanger coderanger commented Oct 30, 2014

Conclusion from the dev meeting is that this is a good change, but it shouldn't be merged until local mode is updated to support .rb loading and is otherwise compatible with chef-solo's loading behavior. When that is done, we will be within striking distance and can thaw this RFC.

Loading

@adamhjk
Copy link
Contributor

@adamhjk adamhjk commented Oct 30, 2014

Agreed Just for perfect clarification:

chef-solo needs to exist forever, with 100% compatibility. If anything, chef-zero/local mode should just be renamed to chef-solo when we are through. Solo is hugely useful, and a huge portion of our community uses it every day. We are not going to deprecate it, we aren't going to put warnings in place, we are going to get 100% compatible (with extra features) before we do anything at all.

Long live Chef Solo, and lets get the work done so that people stop needing check solo/server.

Loading

@jtimberman
Copy link
Contributor Author

@jtimberman jtimberman commented Oct 30, 2014

100% agree.

Loading

@jtimberman
Copy link
Contributor Author

@jtimberman jtimberman commented Oct 30, 2014

I wasn't sure if we need language about the behavior/effect of Chef::Config[:solo]. That specific setting would actually be rather unnecessary for cookbook authors as recipes will behave the same, as it's usually used to guard against search. Of course, "solo" probably won't have results given that it doesn't use state about other nodes from a server (by design).

Loading

@lamont-granquist
Copy link
Contributor

@lamont-granquist lamont-granquist commented Oct 30, 2014

From a client code perspective, the final 'definition of done' here would be that all the Chef::Config[:solo] codepaths would be removed from the client.

Loading

@tknerr
Copy link

@tknerr tknerr commented Oct 31, 2014

@adamhjk thanks for stating this so clearly - chef solo is a perfect fit for many use cases (and it makes the workflow so much easier) :-)

Loading

@adamhjk
Copy link
Contributor

@adamhjk adamhjk commented Nov 13, 2014

👍 please merge.

Loading

@jtimberman
Copy link
Contributor Author

@jtimberman jtimberman commented Nov 13, 2014

Thanks! 🍨

Loading

coderanger added a commit that referenced this issue Nov 13, 2014
…l-mode

Replace `chef-solo` with `chef-client --local-mode` functionality
@coderanger coderanger merged commit f22f97f into master Nov 13, 2014
@jtimberman jtimberman deleted the jtimberman/replace-solo-with-local-mode branch Nov 14, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
7 participants