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

Projects
None yet
7 participants
@jtimberman
Copy link
Member

jtimberman commented Sep 14, 2014

No description provided.

@jtimberman

This comment has been minimized.

Copy link
Member Author

jtimberman commented Sep 14, 2014

Paging @jkeiser

@tas50

This comment has been minimized.

Copy link
Member

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

@mivok

This comment has been minimized.

Copy link

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.

@lamont-granquist

This comment has been minimized.

Copy link
Contributor

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.

@coderanger

This comment has been minimized.

Copy link
Contributor

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.

@adamhjk

This comment has been minimized.

Copy link
Contributor

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.

@jtimberman

This comment has been minimized.

Copy link
Member Author

jtimberman commented Oct 30, 2014

100% agree.

@jtimberman

This comment has been minimized.

Copy link
Member Author

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).

@lamont-granquist

This comment has been minimized.

Copy link
Contributor

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.

@tknerr

This comment has been minimized.

Copy link

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) :-)

@adamhjk

This comment has been minimized.

Copy link
Contributor

adamhjk commented Nov 13, 2014

👍 please merge.

@jtimberman

This comment has been minimized.

Copy link
Member Author

jtimberman commented Nov 13, 2014

Thanks! 🍨

coderanger added a commit that referenced this pull request Nov 13, 2014

Merge pull request #54 from opscode/jtimberman/replace-solo-with-loca…
…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