UUIDv1 has several disadvantages:
- it encodes the MAC address of the host, which is a potential privacy issue
- it uses the clock of the host, which reveals time information
- the clock is very coarse, hence the complex code handling duplicates
UUIDv4 is simply a 122 bit random number encoded into the UUID format, which
has no problems with duplicates or locking.
Use the google/uuid library, as newer versions of pborman/uuid just wrap the
Google upstream.
Note that technically a random UUID might fail, but Go ensures that this
should not take place, as it will block if entropy is not available.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
What is the problem being solved?
https://github.com/kubernetes/kubernetes/pull/75135
Currently version compatibility is not being checked in server side apply between the patch object and the live object. This is causing a merge that will error to be run and the apiserver returns a 500 error. The request should fail if the apiVersion provided in the object is different from the apiVersion in the url, but it should fail before trying to merge, and be a 4xx error. Probably a bad request error.
Why is this the best approach?
The approach of serializing the patch byte array and then checking for version equality with the already serialized live object is the simplest and most straightforward solution.
We REJECT every other case. Close this FIXME.
To get this to work in all cases, we have to process service in
filter.INPUT, since LB IPS might be manged as local addresses.
This is a prefactoring for followup changes that need to use very
similar but subtly different test. Now it is more generic, though it
pushes a little logic up the stack. That makes sense to me.
Need to add bracket in the tag for sig-windows. Also fix an issue: for
current testing structure, it first init driver and then set up the
framework. So when initialize the driver, it does not know what OS is
and we can not set up the capabilities correctly. Instead we have to add
all the capabilities and supported fs types including both linux and
windows. Later in the code, we will check the Node OS and decide how to
run the test.
* Upload certificates: generate certificates and check that the kubeadm-certs
secret is populated with the expected contents.
* Download certificates: given we have a kubeadm-certs secret, ensure that
keys and certificates are copied on the expected target, and that depending
on the secret nature they have the expected permissions.
The fuzzer test for NodeRegistrationOptions is defaulting the CRISocket member.
This is a left over from the times this member was statically defaulted in the
config. Now that the member is dynamically defaulted, setting CRISocket to foo
can cause issues to get undetected by the fuzzer test with this member.
The resolution is to stop setting CRISocket in the fuzzer test.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
