Clear out lots of cruft and mistakes in this old API. The language GAPI
isn't updated with this commit, and as a result, this won't build, but
the fixes for it are coming shortly. We could have merged the two
commits, but it's easier to show them separately for clarity.
The nil type is being added, but only slightly. It is not meant for real
use in the language. It will not work in all situations, and it isn't
implemented for many methods.
It is being added only for being a "dummy" placeholder value in the
engine when we have an unused value being propagated along an edge.
This is a bit tricky, and we should nuke and redo some of this API. The
sneaky bit has to do with whether we've already added the namespace
magic into our etcd client or not.
We want the pattern to be key:0, val:0, key:1, val:1, and so on... This
was previously using 0,1,2,3...
When we use Call directly, we need to fix this. Previously this was dead
code which is why the bug wasn't caught.
There's no reason we need to remake these two channels, when we can just
use one. We should probably rewrite this code entirely, but at least we
get rid of this race for now.
This removes the secret channel from the call function. Having it made
it more complicated to write new function engines, and it's not clear
why it was even needed in the first place. It seems that even the
current generation of function engines work just fine without it.
Co-authored-by: Samuel Gélineau <gelisam@gmail.com>
It's common in many concurrent engines to have a situation where we
collect errors on shutdown. Errors can either because a context closed,
or because some engine error happened. The latter, can also cause the
former, leading to a list of returned errors. In these scenarios, we
want to filter out all the secondary context errors, unless that's all
that's there. This provides a helper function to do so.
We should consider if it's possible to avoid all of this transforming
entirely, but at least for now, do it all in one place by having an
available helper.
This started because it was possible, not because it was very useful.
The overhead of using the full function API, is lessened by the function
API helpers, and the upcoming improvements in the function API.
It's much easier to have one fewer API's to manage and so on.
It's also a stark reminder of how weak tools like "puppet" are which
only really have data collection systems that don't take arguments.
If the user is logged in, and we try to change from /home/james to
/home/james/ we'll get the error:
usermod: user james is currently used by process ????
and furthermore, it makes no sense to try and make this change since the
usermod function won't do anything if you run:
usermod --gid james --groups wheel --home /home/james/ james
when /etc/passwd has /home/james as the string.
The provisioner should be able to encrypt things. We should use an empty
passphrase so that the choosing of the actual passphrase can be done at
first boot.
Could be used for any tool, but mgmt is an obvious possibility.
I should check this code more, but it's roughly right and I'm sure it
will get refactored more when I build opt-in provisioning and so on.
