Comments (14)
Thanks for the issue @bknowles. Since knife is mostly an interactive tool having a log location for it wasn't at the top of our list. Do you have a scenario for which this is required?
from chef.
Yup. During a first boot operation of a node that is being bootstrapped, the logs don't get saved anywhere. There are situations where the only time Chef will be run on a node is during that bootstrap, because the node might be relatively ephemeral, or the client might decide that Chef is only used to install the software and not to do long-term maintenance with Chef.
Then there's the factory model, where you bootstrap a new node with a factory role, and then it is responsible for going to bootstrap all the other new nodes that need to be created. In that case, there is no way to pass the log_level or log_location information down from knife into the factory node that is being bootstrapped, or to pass that information down from the factory node to all the other nodes that are going to be bootstrapped.
Log information can be critical. Both log_level and log_location are things that we need to be able to communicate from our Chef workstation through the bootstrap process to the node being created, and through that factory node to all the other nodes that are going to be bootstrapped.
from chef.
Excellent thanks for sharing the scenario @bknowles. Definitely a super important scenario. In that case I think we want to have an option in the knife context here:
https://github.com/opscode/chef/blob/master/lib/chef/config.rb#L478-L490
Having a straight knife config options sounds as if we're trying to redirect the output of knife to a log file. Not that above context is used during bootstrap only.
Let me know if more clarification is needed on this.
Thanks for bringing this up.
from chef.
Okay, sounds like a good idea. Should we call these options "chef_log_level" and "chef_log_location"?
I'm fine with taking the standard defaults of :auto or :info for chef_log_level, and STDOUT for chef_log_location. I just want something that we can easily over-ride and make sure it gets passed all the way down.
from chef.
I think log_level
and log_location
is fine since they will be in in knife
config_context
.
We should pick the current defaults since we would like to preserve backwards compatibility.
from chef.
Will do.
from chef.
I am still working on the specs that need to be modified to suit.
Would you like me to commit and push what I've got so far, so that you can take a look?
from chef.
Do you think adding these to knife configure
is critical @bknowles? It's somewhat problematic since the bootstrap settings need to be set as below in the config:
knife[:log_location] = "/foo/bar"
I think knife configure
is primarily used for the relatively new users where this scenario seems to be somewhat of an advanced scenario. I'm 👍 on adding these options to bootstrap and rendering them on the client.rb
prepared on the node that is being bootstrapped but leaning towards 👎 on adding these to knife configure
.
Any additional thoughts on this @opscode/client-eng ?
from chef.
If knife configure
is only for new users in setting up their knife.rb
the first time, then I would be fine with removing this from that section of the code.
from chef.
Of course, you have to fix config_content
in all the appropriate places, or you have to fix all the bootstrap configurations to be more like archlinux-gems.erb
and explicitly specify exactly what all should go into the configuration file.
I'm not sure what the right way is to solve that problem.
from chef.
And let's not forget commit id 6c9d8c3
from chef.
👍 to this feature. I have about the same scenario as @bknowles mentioned but for the windows environments, so let's not forget to change https://github.com/opscode/knife-windows/blob/0aece756377e9c7127818a064113ccbf818eaca2/lib/chef/knife/core/windows_bootstrap_context.rb#L49-L50 as well. So, if you need any assistance on testing for Windows, just let me now, I'll be happy to help.
And just as a side note for anybody wandering how it could be implemented right now, I'm using cusom bootstrap template for Windows with only one change:
> <%= bootstrap_directory %>\client.rb (
<%= config_content %>
<%# Additional config overrides -%>
<%= escape_and_echo('log_location "c:/chef/chef.log"') %>
<%= escape_and_echo('log_level :debug') %>
)
from chef.
This is fixed in #5502 and chef/knife-windows#407.
The Chef changes are in 12.17.25+, with a stable release targeted for release on Monday. The knife-windows changes will be an upcoming release.
from chef.
chef/knife-windows#407 was released in knife-windows 1.8.0 today.
from chef.
Related Issues (20)
- Start a service after enabling it HOT 3
- Cloud helper functions return incorrect results after nodes are moved between clouds (Azure -> AWS)
- 18.4.2 windows_service property "description": NoMethodError HOT 3
- 'log' resource ignores the 'message' attribute, and will always use the name of the resource as the message
- chef_client_config errors out for bool property
- apt_repository should not use deprecated apt-key anymore HOT 2
- Deprecate osx_profile resource since it can longer silently install profiles HOT 1
- Sysctl resource behaves incorrectly when supplied with comment
- The Supermarket cookbook API limit has changed
- chef-client runs with version 18.x get a EOL warning HOT 7
- homebrew_tap resource always fails with TypeError on x86 HOT 3
- Chef Infra Client 18 is being marked as End Of Life as of May 1, 2024 HOT 3
- Ruby files have known CVEs HOT 1
- Chef client under FIPS mode now broken in RHEL 9.4/Rocky Linux 9.4 HOT 1
- AllowClobber switch is not configurable on powershell_package resource
- Unable to install any versions of Chef except the latest one on Amazon Linux 2023 HOT 1
- FIPS broken for Ruby on Windows with OpenSSL 3.x
- Allow Chef to support a stable Semantic Versioning specification
- WARN: Resource cron_access built into Chef Infra Client is being overridden by the resource from a cookbook. HOT 4
- Point at a non-branch/git repo fork of ruby-shadow
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from chef.