Open lamont-granquist opened 10 years ago
Overall, yes.
chef configure
; continue.@tduffield, this might be of interest for you for the container issues you were dealing with.
@danielsdeleo , the server already supports an endpoint for creating a new client without the validator, right?
@adamedx I should explain a little how it works now and point out what need to change to make validator-less bootstraps work:
chef-client
determines client and node name based on user config (the node_name
setting) or automatically from ohai hostname/fqdn.chef-client
creates the client and node objects by making a POST to /clients and /nodes. Note that because of authz (bifrost) authZ model, the POST to /nodes has to be done using the identity of the client created in the previous step.knife
or any API client can hit the right endpoints to make the POST requests to /clients and /nodes, but you have to know what node_name
you want. In the current scheme, this is something that happens very late in the process when you let chef pick the node names for you.
Depending on how we judge the tradeoffs, we could:
chef-detect-node-name
. Increases time you have to wait until a failure happens, but the code would be more cross-platform.Some things we might do to make the experience nicer for users:
knife bootstrap --use-validator
so you can switch back to the old behavior if you prefer.--use-validator
isn't given then -N NODE_NAME
is required.knife bootstrap -N chat-server --uniqify-name
and knife picks a node name like chat-server-RANDOMHEX
for you.FQDN
argument to knife bootstrap FQDN
as the node name rather than detecting it client side, e.g., knife bootstrap my-host.example.com --use-fqdn-as-node-name
.I'd say we just mandate -N and offer --use-validator for old behavior.
The uniqify problem is already something that exists, it seems a bit orthogonal. The workaround to the last thing is just knife bootstrap FQDN -N FQDN
-- we could think about just making that the default unless you pass in an explicit -N.
@lamont-granquist yeah, I was thinking about use cases like knife $cloud create
where we sometimes use unique identifiers from the cloud service as node names. For a cloud bootstrap we have to make a choice about the trade-offs of picking a node name before we ask the cloud API for a new instance. If there is any issue with client creation, like invalid credentials (bad username/user key, not authorized to create client, duplicate node/client name), invalid user config, chef-server availability problem, the user will find out about it before they waste time (and money) spinning up a cloud instance that they cannot actually bootstrap. The downside is that you can't use your cloud provider's IDs for your node names, so you have to rely on getting this data from ohai. I think adding custom ID suffixes as a feature would make it more convenient to do the chef credential creation up-front, which I think would be a better UX overall.
Triaging this issue for the Chef Workstation team. This overlaps with some of the unified CLI work we have been talking about, and highlights the disparity between different products packaged inside Workstation. Namely - that they all use different configuration files and configuration methods.
I would think, in a world where a chef
command gives users all the functionality they need to manage their Chef Software installation, that users would only have 1 configuration file to manage.
This also highlights the issue users have of "I just installed Chef Workstation, what do I do now". Our post install command should point them to something like chef configure
or chef init
so they have a breadcrumb of steps to follow
We need to replace 'knife configure -i' with something a bit more opinionated (yet ultimately customizable) and which does better integration.
By default it should probably hit hosted chef, with a --server command line option to override the server location (I DO NOT WANT TO TYPE IN API.OPSCODE.COM AND YES IM SCREAMING THIS). It needs to know your organization, user and password. It should take those off of the command line, or via interactive prompting.
It should then fetch your validator, client key and setup a knife.rb for your with no additional prompting.
The default location for the knife.rb should be .chef/knife.rb, it should assume a ~/chef-repo/{cookbooks,data_bags,role,etc} directory structure. Do not prompt the user to make a choice. It should /allow/ overriding the directory structure to move it under a more
~/env/{organization}
-like structure (I'd like to be able to set~/env/{organization}
as a preference in a .chefrc file)The way I see this working for a new hosted user:
The way I see this working for a new private EC user:
The way I'd like to be able to use it after some minor config tweaking: