This repository has been archived by the owner on Nov 15, 2022. It is now read-only.
Find conflicting fields programatically #111
Comments
|
if i understand it correctly activeDeadlineSeconds in Job is doing something slightly different than activeDeadlineSeconds in Pod. It should be possible to specify both separately |
concaf
added a commit
to concaf/kedge
that referenced
this issue
Jul 11, 2017
Before this commit, we had no way to know if the embedded structs had any conflicting fields between each other or with the struct embedding the structs. This led to inconsistency since in case of conflicting fields, the data would not be unmarshalled and due to presence of a lot of fields, this would go unnoticed. This commit handles this in a 4 step process. Step 1: Get all the target structs. Look at tags in the fields of the input struct as well as the embedded structs, so both of them become our target structs. Step 2: Get blacklisted tags. Get the fields which have already been handled and were previously conflicting. This needs to be done only for the structs in spec.go, and with fields marked as "conflicting" using a JSON tag Step 3: Get JSON tags from target structs. Get the JSON tags from all of the target structs which we got in Step 1 except for the blacklisted tags, along with the names of the structs which hold the field with that tag. Step 4: Check if more than one struct holds a tag. Delete all the tags in Step 3 which are only help by one struct, because it means that the JSON tag is not conficting, and finally return the remaining tags which are held by more than one struct, and are not handled, hence conflicting tags The code has been heavily documented, and tests have been added for this behavior. The entire code is not a part of the main program and is not run every time a user executes any kedge command, instead it has been put as a test, since it's more of a developer facing problem than a user facing one. Fixes kedgeproject#111
|
How do you propose to fix conflicting keys programmatically? |
concaf
changed the title
concaf
added a commit
to concaf/kedge
that referenced
this issue
Jul 19, 2017
Before this commit, we had no way to know if the embedded structs had any conflicting fields between each other or with the struct embedding the structs. This led to inconsistency since in case of conflicting fields, the data would not be unmarshalled and due to presence of a lot of fields, this would go unnoticed. This commit handles this in a 4 step process. Step 1: Get all the target structs. Look at tags in the fields of the input struct as well as the embedded structs, so both of them become our target structs. Step 2: Get blacklisted tags. Get the fields which have already been handled and were previously conflicting. This needs to be done only for the structs in spec.go, and with fields marked as "conflicting" using a JSON tag Step 3: Get JSON tags from target structs. Get the JSON tags from all of the target structs which we got in Step 1 except for the blacklisted tags, along with the names of the structs which hold the field with that tag. Step 4: Check if more than one struct holds a tag. Delete all the tags in Step 3 which are only help by one struct, because it means that the JSON tag is not conficting, and finally return the remaining tags which are held by more than one struct, and are not handled, hence conflicting tags The code has been heavily documented, and tests have been added for this behavior. The entire code is not a part of the main program and is not run every time a user executes any kedge command, instead it has been put as a test, since it's more of a developer facing problem than a user facing one. Fixes kedgeproject#111
concaf
added a commit
to concaf/kedge
that referenced
this issue
Jul 21, 2017
Before this commit, we had no way to know if the embedded structs had any conflicting fields between each other or with the struct embedding the structs. This led to inconsistency since in case of conflicting fields, the data would not be unmarshalled and due to presence of a lot of fields, this would go unnoticed. This commit handles this in a 4 step process. Step 1: Get all the target structs. Look at tags in the fields of the input struct as well as the embedded structs, so both of them become our target structs. Step 2: Get blacklisted tags. Get the fields which have already been handled and were previously conflicting. This needs to be done only for the structs in spec.go, and with fields marked as "conflicting" using a JSON tag Step 3: Get JSON tags from target structs. Get the JSON tags from all of the target structs which we got in Step 1 except for the blacklisted tags, along with the names of the structs which hold the field with that tag. Step 4: Check if more than one struct holds a tag. Delete all the tags in Step 3 which are only help by one struct, because it means that the JSON tag is not conficting, and finally return the remaining tags which are held by more than one struct, and are not handled, hence conflicting tags The code has been heavily documented, and tests have been added for this behavior. The entire code is not a part of the main program and is not run every time a user executes any kedge command, instead it has been put as a test, since it's more of a developer facing problem than a user facing one. Fixes kedgeproject#111
concaf
added a commit
to concaf/kedge
that referenced
this issue
Jul 25, 2017
Before this commit, we had no way to know if the embedded structs had any conflicting fields between each other or with the struct embedding the structs. This led to inconsistency since in case of conflicting fields, the data would not be unmarshalled and due to presence of a lot of fields, this would go unnoticed. This commit handles this in a 4 step process. Step 1: Get all the target structs. Look at tags in the fields of the input struct as well as the embedded structs, so both of them become our target structs. Step 2: Get blacklisted tags. Get the fields which have already been handled and were previously conflicting. This needs to be done only for the structs in spec.go, and with fields marked as "conflicting" using a JSON tag Step 3: Get JSON tags from target structs. Get the JSON tags from all of the target structs which we got in Step 1 except for the blacklisted tags, along with the names of the structs which hold the field with that tag. Step 4: Check if more than one struct holds a tag. Delete all the tags in Step 3 which are only help by one struct, because it means that the JSON tag is not conficting, and finally return the remaining tags which are held by more than one struct, and are not handled, hence conflicting tags The code has been heavily documented, and tests have been added for this behavior. The entire code is not a part of the main program and is not run every time a user executes any kedge command, instead it has been put as a test, since it's more of a developer facing problem than a user facing one. Fixes kedgeproject#111
concaf
added a commit
to concaf/kedge
that referenced
this issue
Jul 27, 2017
Before this commit, we had no way to know if the embedded structs had any conflicting fields between each other or with the struct embedding the structs. This led to inconsistency since in case of conflicting fields, the data would not be unmarshalled and due to presence of a lot of fields, this would go unnoticed. This commit handles this in a 4 step process. Step 1: Get all the target structs. Look at tags in the fields of the input struct as well as the embedded structs, so both of them become our target structs. Step 2: Get blacklisted tags. Get the fields which have already been handled and were previously conflicting. This needs to be done only for the structs in spec.go, and with fields marked as "conflicting" using a JSON tag Step 3: Get JSON tags from target structs. Get the JSON tags from all of the target structs which we got in Step 1 except for the blacklisted tags, along with the names of the structs which hold the field with that tag. Step 4: Check if more than one struct holds a tag. Delete all the tags in Step 3 which are only help by one struct, because it means that the JSON tag is not conficting, and finally return the remaining tags which are held by more than one struct, and are not handled, hence conflicting tags The code has been heavily documented, and tests have been added for this behavior. The entire code is not a part of the main program and is not run every time a user executes any kedge command, instead it has been put as a test, since it's more of a developer facing problem than a user facing one. Fixes kedgeproject#111
concaf
added a commit
to concaf/kedge
that referenced
this issue
Jul 31, 2017
Before this commit, we had no way to know if the embedded structs had any conflicting fields between each other or with the struct embedding the structs. This led to inconsistency since in case of conflicting fields, the data would not be unmarshalled and due to presence of a lot of fields, this would go unnoticed. This commit handles this in a 4 step process. Step 1: Get all the target structs. Look at tags in the fields of the input struct as well as the embedded structs, so both of them become our target structs. Step 2: Get blacklisted tags. Get the fields which have already been handled and were previously conflicting. This needs to be done only for the structs in spec.go, and with fields marked as "conflicting" using a JSON tag Step 3: Get JSON tags from target structs. Get the JSON tags from all of the target structs which we got in Step 1 except for the blacklisted tags, along with the names of the structs which hold the field with that tag. Step 4: Check if more than one struct holds a tag. Delete all the tags in Step 3 which are only help by one struct, because it means that the JSON tag is not conficting, and finally return the remaining tags which are held by more than one struct, and are not handled, hence conflicting tags The code has been heavily documented, and tests have been added for this behavior. The entire code is not a part of the main program and is not run every time a user executes any kedge command, instead it has been put as a test, since it's more of a developer facing problem than a user facing one. Fixes kedgeproject#111
concaf
added a commit
to concaf/kedge
that referenced
this issue
Jul 31, 2017
Before this commit, we had no way to know if the embedded structs had any conflicting fields between each other or with the struct embedding the structs. This led to inconsistency since in case of conflicting fields, the data would not be unmarshalled and due to presence of a lot of fields, this would go unnoticed. This commit handles this in a 4 step process. Step 1: Get all the target structs. Look at tags in the fields of the input struct as well as the embedded structs, so both of them become our target structs. Step 2: Get blacklisted tags. Get the fields which have already been handled and were previously conflicting. This needs to be done only for the structs in spec.go, and with fields marked as "conflicting" using a JSON tag Step 3: Get JSON tags from target structs. Get the JSON tags from all of the target structs which we got in Step 1 except for the blacklisted tags, along with the names of the structs which hold the field with that tag. Step 4: Check if more than one struct holds a tag. Delete all the tags in Step 3 which are only help by one struct, because it means that the JSON tag is not conficting, and finally return the remaining tags which are held by more than one struct, and are not handled, hence conflicting tags The code has been heavily documented, and tests have been added for this behavior. The entire code is not a part of the main program and is not run every time a user executes any kedge command, instead it has been put as a test, since it's more of a developer facing problem than a user facing one. Fixes kedgeproject#111
concaf
added a commit
that referenced
this issue
Jul 31, 2017
Before this commit, we had no way to know if the embedded structs had any conflicting fields between each other or with the struct embedding the structs. This led to inconsistency since in case of conflicting fields, the data would not be unmarshalled and due to presence of a lot of fields, this would go unnoticed. This commit handles this in a 4 step process. Step 1: Get all the target structs. Look at tags in the fields of the input struct as well as the embedded structs, so both of them become our target structs. Step 2: Get blacklisted tags. Get the fields which have already been handled and were previously conflicting. This needs to be done only for the structs in spec.go, and with fields marked as "conflicting" using a JSON tag Step 3: Get JSON tags from target structs. Get the JSON tags from all of the target structs which we got in Step 1 except for the blacklisted tags, along with the names of the structs which hold the field with that tag. Step 4: Check if more than one struct holds a tag. Delete all the tags in Step 3 which are only help by one struct, because it means that the JSON tag is not conficting, and finally return the remaining tags which are held by more than one struct, and are not handled, hence conflicting tags The code has been heavily documented, and tests have been added for this behavior. The entire code is not a part of the main program and is not run every time a user executes any kedge command, instead it has been put as a test, since it's more of a developer facing problem than a user facing one. Fixes #111
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
We embed a lot of structs (huuuge structs), and it's very likely that there are some conflicting fields which we cannot catch just by looking.
We need to way to find conflicting fields in our resulting spec, and then handle such conflicts gracefully and very reliably.
One example is while implementing jobs (#52), I figured that the
activeDeadlineSecondsfield would not populate in the JobSpec, and @surajssd and I figured out that this field exists in bothapi.PodSpecandbatch.JobSpecand the way we are building jobs is -Hence, this field does not get populated in either of the structs due to the conflict.
In this case, the conflicting field
activeDeadlineSecondsspecifies the number of seconds a pod is allowed to run on a node, so it makes sense to substitute the same value in bothJobSpecandPodSpec.Similarly, we need to take decisions for all the conflicting fields.
So -
The text was updated successfully, but these errors were encountered: