| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It makes more sense when you read it
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I left a note to kill this later
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
See the comment for why I had to do this
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This helper didn't help much
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This can be a name or UID
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This prevents the non-array form from breaking things
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Issues:
- If you try to remove a package that doesn't exist it explodes
- If you try to use a package by its alias name it will blow up. Exampe: package 'golang' instead of 'go'. The hash of available packages will get built with 'go' as that's the package name
- versions are pretty much ignored, but I think that makes sense with homebrew. It's a roll forward package system so you can't install a specific version. That's just not a concept of the package system.
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Good example of why this is breaking, but this is better.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
All required properties are now required for all actions by default
even if the action does not reference the property.
In order to only make the property required for a subset of the
actions, specify them as an array of symbols to the required
options on the property.
```
property :whatever, String, required: %i{start stop}
action :start do
end
action :stop do
end
action :enable do
end
action :disable do
end
```
That property will be required for start+stop but not for
enable+disable.
There's an unaddressed edge case here where if you reference the
property in an action which was not specified that it will also
fail validation. That is correct behavior. We should probably
dig into how to warn the user that they must either remove the
reference to the property from that action or else to add the
action to the list of required actions on the property.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | |
| | | |
| | | |
| | | | |
Obvious fix; these changes are the result of automation not creative thinking.
|
| | | |
| | | |
| | | |
| | | | |
Obvious fix; these changes are the result of automation not creative thinking.
|
|\ \ \ \
| | | | |
| | | | | |
Knife bootstrap options cleanup
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We have issue that are caused by old code before merging of hash values
were done correctly.
The `config` hash correctly merges all options and should always be
used.
Knife plugins should never touch Chef::Config[:knife] values (either
reading or writing from them).
The `knife_config` should be converted to the `config` hash since it
directly accesses Chef::Config[:knife] values.
The `config_value()` helper should no longer be used. Very clearly most
people started to use that when they should just use the config hash
directly. That was intended to be used only when a knife cli option
was being renamed and the former configuration value needed to be
used as well. It has been cargo culted around as the way to access
config values, and that should really stop.
The DataBagSecretOption mixin has been cleaned up so that the cli
options read+write only to the config[:cl_secret] and
config[:cl_secret_file] values. The config file values go into
config[:secret] and config[:secret_file]. The fact that those are
the merged values in the `config` hash doesn't matter since only
the cli should be writing to the first two and only the config
file should be writing to the latter two. I don't know why it was
made so complicated to begin with, but if there's some hidden
chef-11.early backcompat there, then chef-16 deliberately breaks that.
The use of `locate_config_value` helpers in all knife plugins is also
discouraged (but they all implement those themselves), just use the
config hash, which has the correct hash merge ordering. All of those
need to be deleted.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | | |
| | | | |
| | | | |
| | | | | |
Obvious fix; these changes are the result of automation not creative thinking.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Obvious fix; these changes are the result of automation not creative thinking.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The consumption of ohai attributes by the ohai segment plugin code
was breaking this feature.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | | |
| | | | |
| | | | |
| | | | | |
Obvious fix; these changes are the result of automation not creative thinking.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | | |
Simplify this resource and squash some files
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
| | | |
| | | |
| | | | |
Obvious fix; these changes are the result of automation not creative thinking.
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | |
| | | |
| | | |
| | | | |
Obvious fix; these changes are the result of automation not creative thinking.
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: dheerajd-msys <dheeraj.dubey@msystechnologies.com>
|
| | | |
| | | |
| | | |
| | | | |
Obvious fix; these changes are the result of automation not creative thinking.
|
|\ \ \ \
| | | | |
| | | | | |
Add a warning to the end of the chef run for EOL releses
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Use 2006 as the base year. Chef 15 goes EOL next year on 5-1-2021 so
2006 + 15 = 2021 and then we know it.
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We really want to encourage people to upgrade. One way we can do this is
to just warn them that they're on an EOL release. This simple warning
might nudge them to upgrade their client. It's works off the base EOL
data of Chef 15 and takes the current release to add to that date. That
way we don't have to maintain anything and as long as we keep a yearly
release we're good. If we change the schedule then we either remove this
or update the logic. That's a risk in shipping code that doesn't fire
for 2 years.
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | | |
| | | | |
| | | | |
| | | | | |
Obvious fix; these changes are the result of automation not creative thinking.
|
|\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
MsysTechnologiesllc/dh/fix-msu-pkg-cumulative-update
msu_package: Fix cumulative updates installation and provide a 3600s default timeout
|
| | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: dheerajd-msys <dheeraj.dubey@msystechnologies.com>
|
| | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: dheerajd-msys <dheeraj.dubey@msystechnologies.com>
|
| |/ / /
|/| | |
| | | |
| | | | |
Obvious fix; these changes are the result of automation not creative thinking.
|
| | | |
| | | |
| | | |
| | | | |
Obvious fix; these changes are the result of automation not creative thinking.
|
| |_|/
|/| |
| | |
| | |
| | |
| | | |
I think we may finally have them all now.
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | |
| | |
| | |
| | | |
Obvious fix; these changes are the result of automation not creative thinking.
|
|\ \ \
| |/ /
|/| | |
Updates to timeout properties in various resources
|
| | |
| | |
| | |
| | |
| | |
| | | |
This should just be done on the resource instead of hacking it into the provider
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1) make sure they all have desired state false
2) Fix some indentation
3) Fix portage_package to have a type of String/Integer to match package
4) Add the String type to paludis_package to match the package default
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|/ /
| |
| |
| | |
Obvious fix; these changes are the result of automation not creative thinking.
|
| |
| |
| |
| | |
Obvious fix; these changes are the result of automation not creative thinking.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Legally incredibly dubious, particularly since we don't follow it
strictly as policy, and we have git history instead, which does it right.
This is just a waste of time and a cargo cult.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|