Skip to content
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

Merged

Conversation

KiptoonKipkurui
Copy link
Member

Description
This PR updates Meshsync to receive configuration for Meshsync CRD
This PR fixes #257

Notes for Reviewers

Signed commits

  • Yes, I signed my commits.

CRD

Signed-off-by: Daniel Kiptoon <kiptoonkipkurui@gmail.com>
meshsync crd

Signed-off-by: Daniel Kiptoon <kiptoonkipkurui@gmail.com>
CRD if available

Signed-off-by: Daniel Kiptoon <kiptoonkipkurui@gmail.com>
@codecov
Copy link

codecov bot commented Oct 11, 2023

Codecov Report

Attention: 56 lines in your changes are missing coverage. Please review.

Comparison is base (dbcef1e) 2.77% compared to head (988de5b) 11.53%.

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     
Flag Coverage Δ
unittests 11.53% <47.16%> (+8.76%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
internal/config/crd_config.go 47.16% <47.16%> (ø)

... and 2 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@Aisuko Aisuko left a 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
Copy link
Member

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"

Copy link
Member Author

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

internal/config/crd_config.go Outdated Show resolved Hide resolved
internal/config/crd_config.go Show resolved Hide resolved
internal/config/types.go Outdated Show resolved Hide resolved
crdConfigs, err := config.GetMeshsyncCRDConfigs()

if err != nil {
// no configs found from meshsync CRD log warning
Copy link
Member

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.

Copy link
Member Author

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

KiptoonKipkurui and others added 4 commits October 23, 2023 21:52
Co-authored-by: Aisuko <urakiny@gmail.com>
Signed-off-by: Kiptoon Kipkurui <50325211+KiptoonKipkurui@users.noreply.github.com>
Co-authored-by: Aisuko <urakiny@gmail.com>
Signed-off-by: Kiptoon Kipkurui <50325211+KiptoonKipkurui@users.noreply.github.com>
Signed-off-by: Daniel Kiptoon <kiptoonkipkurui@gmail.com>
@KiptoonKipkurui
Copy link
Member Author

KiptoonKipkurui commented Oct 23, 2023

@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 <kiptoonkipkurui@gmail.com>
@leecalcote
Copy link
Member

leecalcote commented Oct 26, 2023

Some notes from today's Meshery Build and Release meeting:

A new attribute inside of the meshsync CRD on the order of something like watchList, which is configurable with both the ability to explicitly name Resources and Event types of interest and explicitly those that are not.

My intuition leans into suggesting that this positive/negative tuple is ideally/conveniently defined in a ConfigMap, which is assigned to the watchList attribute.

Clarification of the terms that I've just used:

  • positive:whitelist
  • negative:blacklist
  • tuple:{"ResourceName":"EventType"}

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 <kiptoonkipkurui@gmail.com>
Signed-off-by: Daniel Kiptoon <kiptoonkipkurui@gmail.com>
Signed-off-by: Daniel Kiptoon <kiptoonkipkurui@gmail.com>
publishing item

Signed-off-by: Daniel Kiptoon <kiptoonkipkurui@gmail.com>
listeners before using them

Signed-off-by: Daniel Kiptoon <kiptoonkipkurui@gmail.com>
Signed-off-by: Daniel Kiptoon <kiptoonkipkurui@gmail.com>
Copy link
Contributor

@MUzairS15 MUzairS15 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@KiptoonKipkurui
Copy link
Member Author

KiptoonKipkurui commented Nov 1, 2023

Some notes from today's Meshery Build and Release meeting:

A new attribute inside of the meshsync CRD on the order of something like watchList, which is configurable with both the ability to explicitly name Resources and Event types of interest and explicitly those that are not.

My intuition leans into suggesting that this positive/negative tuple is ideally/conveniently defined in a ConfigMap, which is assigned to the watchList attribute.

Clarification of the terms that I've just used:

* positive:whitelist

* negative:blacklist

* tuple:`{"ResourceName":"EventType"}`

The recording of today's discussion is an excellent reference - https://discuss.layer5.io/t/meshery-build-release-meeting-oct-26th-2023/4103/3

@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 <kiptoonkipkurui@gmail.com>
from main to enable smoother unit testing

Signed-off-by: Daniel Kiptoon <kiptoonkipkurui@gmail.com>
Signed-off-by: Daniel Kiptoon <kiptoonkipkurui@gmail.com>
Signed-off-by: Daniel Kiptoon <kiptoonkipkurui@gmail.com>
Signed-off-by: Daniel Kiptoon <kiptoonkipkurui@gmail.com>
Copy link
Contributor

@MUzairS15 MUzairS15 left a 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.

// 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 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

Copy link
Member Author

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

@KiptoonKipkurui
Copy link
Member Author

@KiptoonKipkurui How we handle conflicting values in WhiteList and BlackList. If one has priority over other, do mention it.

Looks good overall.

@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?.

@MUzairS15
Copy link
Contributor

@KiptoonKipkurui How we handle conflicting values in WhiteList and BlackList. If one has priority over other, do mention it.
Looks good overall.

@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.

Then this validation can be done when creating the CRD,
Only when creating the CRD? Since, the resources would be sourced from ConfigMap, shouldn't we validate at that instant as well? (You can skip the validation part in this PR, so that we can get going with these changes atleast).

Copy link
Contributor

@MUzairS15 MUzairS15 left a 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.

@KiptoonKipkurui
Copy link
Member Author

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

@MUzairS15
Copy link
Contributor

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.

@KiptoonKipkurui
Copy link
Member Author

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?

@MUzairS15
Copy link
Contributor

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.

@MUzairS15
Copy link
Contributor

Makes sense?

@leecalcote
Copy link
Member

Makes sense?

Yes. +1

and remove listener configuration from whiteliest and blacklist resources

Signed-off-by: Daniel Kiptoon <kiptoonkipkurui@gmail.com>
Signed-off-by: Daniel Kiptoon <kiptoonkipkurui@gmail.com>
@KiptoonKipkurui
Copy link
Member Author

Makes sense?

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 <kiptoonkipkurui@gmail.com>
@KiptoonKipkurui
Copy link
Member Author

@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

@MUzairS15
Copy link
Contributor

Thanks @KiptoonKipkurui 🚀
Is your PR in meshery operator ready?
I am merging this now.

@MUzairS15 MUzairS15 merged commit e1545b9 into meshery:master Nov 8, 2023
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/meshsync MeshSync related pr/do-not-merge PRs not ready to be merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Configuration from Meshsync CRD
4 participants