-
Notifications
You must be signed in to change notification settings - Fork 85
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
feat: introduce Namespace
#229
Conversation
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.
Changes seem to be ok but it would be great if we have a test that makes sure that separation with namespaces actually works.
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.
Changes seem to be ok but it would be great if we have a test that makes sure that separation with namespaces actually works.
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.
Changes for the "namespace" feature are hard to spot due to many changes suggested by linter. I suggest moving the linter-induced changes to a new PR, so we can review it separately.
Tests still fail for Consul version >= 1.10 because enterprise is not supported. Any suggestions on how we can skip these tests? |
Look at the |
Hmm.. It still fails for <1.7 Shall I create a new attribute |
I think you also need to combine two checks:
I'm not sure, but I don't think it is necessary to implement a new attribute to achieve that. |
Currently I don’t think that |
Yup, just tested. We do need to create a new attribute. For now, I'll just make |
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 changes look good, just left a few minor comments. I think it would be nice also to write a test that would exercise the namespaces feature in a way that is not yet presented in this PR. For example, we could use KV store (https://developer.hashicorp.com/consul/commands/kv) to show that it is possible to store values in different namespaces and assert that they are not visible to each other.
Consul/Namespace.cs
Outdated
{ | ||
public string Name { get; set; } | ||
|
||
public string Description { get; set; } = ""; |
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.
nit: I'm not sure about this default initialization. Was it causing any trouble when it was null
by default? Is there any benefit?
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.
It doesn't seem to cause any trouble when it is null but the Consul server expects an empty string and I am not sure if it could cause unforeseen effects otherwise. See here.
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.
Thank you for this amazing work. There is just single formatting issue remaining, apart from that all looks really good. Well done 🏆
Namespace
Namespace
Namespace
EnterpriseOnlyFact
skippable