-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Meshync Dynamic Configuration from Meshsync #258
Meshync Dynamic Configuration from Meshsync #258
Conversation
CRD Signed-off-by: Daniel Kiptoon <[email protected]>
meshsync crd Signed-off-by: Daniel Kiptoon <[email protected]>
CRD if available Signed-off-by: Daniel Kiptoon <[email protected]>
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #258 +/- ##
==========================================
+ Coverage 2.77% 11.53% +8.76%
==========================================
Files 6 9 +3
Lines 397 529 +132
==========================================
+ Hits 11 61 +50
- Misses 385 461 +76
- Partials 1 7 +6
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contributing. We need a test case here.
var ( | ||
namespace = "meshery" // Namespace for the Custom Resource | ||
crName = "meshery-meshsync" // Name of the custom resource | ||
version = "v1alpha1" // Version of the Custom Resource |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe you can import it rather than hard coded it https://github.com/meshery/meshery-operator/blob/master/api/v1alpha1/meshsync_types.go. Same like metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will update meshsync with this change immediately the meshery operator is approved with the CRD changes
crdConfigs, err := config.GetMeshsyncCRDConfigs() | ||
|
||
if err != nil { | ||
// no configs found from meshsync CRD log warning |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure the log level should be warning level, please get confirm from @leecalcote @theBeginner86. I assume that if we cannot get configs, it should be the Info level? Because we have the default configuraiton.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The choice of using a warning log is because the desired state of configuration for Meshsync from now and in future lies is utilizing the crd as per conversations with @leecalcote and @theBeginner86 so this is an extra speed bump to notify one that the desired approach has not been utilized
Co-authored-by: Aisuko <[email protected]> Signed-off-by: Kiptoon Kipkurui <[email protected]>
Co-authored-by: Aisuko <[email protected]> Signed-off-by: Kiptoon Kipkurui <[email protected]>
Signed-off-by: Daniel Kiptoon <[email protected]>
@Aisuko sorry for the delayed resolutions, I was unwell, I am now better and will work on the proposed changes |
Signed-off-by: Daniel Kiptoon <[email protected]>
Some notes from today's Meshery Build and Release meeting: A new attribute inside of the My intuition leans into suggesting that this positive/negative tuple is ideally/conveniently defined in a ConfigMap, which is assigned to the Clarification of the terms that I've just used:
The recording of today's discussion is an excellent reference - https://discuss.layer5.io/t/meshery-build-release-meeting-oct-26th-2023/4103/3 |
Signed-off-by: Daniel Kiptoon <[email protected]>
Signed-off-by: Daniel Kiptoon <[email protected]>
Signed-off-by: Daniel Kiptoon <[email protected]>
publishing item Signed-off-by: Daniel Kiptoon <[email protected]>
listeners before using them Signed-off-by: Daniel Kiptoon <[email protected]>
Signed-off-by: Daniel Kiptoon <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In case you missed.
meshery/meshery-operator#533 (review)
@MUzairS15 I did not miss your review, it was discussed extensively in the above quoted recording , and what I have pushed is an update from the meeting |
Signed-off-by: Daniel Kiptoon <[email protected]>
from main to enable smoother unit testing Signed-off-by: Daniel Kiptoon <[email protected]>
Signed-off-by: Daniel Kiptoon <[email protected]>
Signed-off-by: Daniel Kiptoon <[email protected]>
Signed-off-by: Daniel Kiptoon <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@KiptoonKipkurui How we handle conflicting values in WhiteList and BlackList.
If one has priority over other, do mention it.
Looks good overall.
internal/config/crd_config.go
Outdated
// Handle listeners | ||
listerners := make(ListenerConfigs, 0) | ||
for _, v := range Listeners { | ||
if idx := slices.IndexFunc(meshsyncConfig.BlackList, func(c string) bool { return c == v.Name }); idx != -1 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if idx := slices.IndexFunc(meshsyncConfig.BlackList, func(c string) bool { return c == v.Name }); idx != -1 { | |
if idx := slices.IndexFunc(meshsyncConfig.BlackList, func(c string) bool { return c == v.Name }); idx == -1 { |
== I believe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Resolved by removing listeners till further conversations
@MUzairS15 Ideally as a start we support one or the other, so we either blacklist resources(allowing the rest) or whitelist a few and ignore the rest. Then this validation can be done when creating the CRD, thoughts?. |
Sounds good either way.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merge Conflicts and a comment to resolve.
@MUzairS15 Finalizing on the fixes, then I think we should have another conversation for the ListenerConfigs, some of the values are part of the code case in point and also we have ListenerConfigs as in Meshync but mapping to broker.RequestEntity types, Ill explain, from switch case, we are using the switch case on a broker entity type, but mapping to a Listener Config. So for now I would like to remove handling ListenerConfigs until we have a more conversations on how best to handle them |
Also, we should look for getting reid of Pipelien configs defined i.e. In this PR we are using blacklist & whitelst and comapring with the CR config based on that watch for the resources. As Lee also mentioned, we can externalise this configiguration in a ConfigMap. Whenever the configmap is updated we would reconcile the CR and the watch. |
Sorry Im not understanding well, the whitelist and blacklist here are supplied from a ConfigMap from the CR as from this other PR yet to be approved, the default configurations are maintained here as a backup. In this case the config map is updated together with the CR then the meshsync can watch for changes, Are you speaking along the same lines or something different? |
Yes, I am on same line. But I was thinking if we could externalise it, i.e. instead of having an attribute of type ConfigMap in the CR we would have a ConfigMap resource which would contain the configs and instead of updating CR we could update ConfigMap. |
Makes sense? |
Yes. +1 |
and remove listener configuration from whiteliest and blacklist resources Signed-off-by: Daniel Kiptoon <[email protected]>
Signed-off-by: Daniel Kiptoon <[email protected]>
Now i get it, in that case, what would the need for having the ConfigMap in the CR? It can work as an independent component that the meshery server can independently configure it |
Signed-off-by: Daniel Kiptoon <[email protected]>
@MUzairS15 I have resolved the issues, pending extraction of the configs to a ConfigMap independent of the CRD, if in agreement we can scrap off updating the CRD and dealing sorely with an independent config map @leecalcote |
Thanks @KiptoonKipkurui 🚀 |
Description
This PR updates Meshsync to receive configuration for Meshsync CRD
This PR fixes #257
Notes for Reviewers
Signed commits