-
Notifications
You must be signed in to change notification settings - Fork 0
draft specification for central control plane changes #1
base: devel
Are you sure you want to change the base?
Conversation
// ServiceSpec defines the desired state of a Service | ||
type ServiceSpec struct { | ||
// UUID is a globally unique identifier for the Service object | ||
UUID string `json:"id,omitempty"` |
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.
Why force a UUID and not any other unique string?
Who generates this UUID?
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 we stay with a machine generated UUID, at least can add some logical name/description field of the service?
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.
See note above regarding Clusters. It could apply to Service
s as well:
...(denoted as a
UUID below. More descriptive names could also be used as long as they're not ambiguous within a ClusterSet)
. For example, if each cluster or service has a unique name - we could certainly use that.
I think the UUID
might be confusing as a real UUID isn't strictly needed or useful. Changed to ID to avoid confusion.
We can certainly add a description to the Service (in fact, I'd imagine we may want to add more information than just a description, for example: owner, API reference, ...). I'm leaving those out for now and we can add then as needed later. I'm not sure any of these attributes
|
||
### Source Code Location | ||
|
||
We propose a new toplevel `submariner-io/axon-ccp` (short for for Axon Central Control plane). |
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.
isn't the controller per broker (given broker multi-tenancy)?
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.
that's a deployment choice on out part. Either works:
- global broker instance, running in (e.g.,) "submariner-system", operating on all namespaces
- local instance in each namespace.
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.
First review iteration done
Signed-off-by: Etai Lev Ran <etai@il.ibm.com>
05250d2
to
5898bb9
Compare
Signed-off-by: Etai Lev Ran <etai@il.ibm.com>
8838a82
to
8085248
Compare
Signed-off-by: Etai Lev Ran <etai@il.ibm.com>
This is the preffered place fpr user to open issues with enhancement requests for the Submariner project Signed-off-by: Maayan Friedman <maafried@redhat.com>
Signed-off-by: Etai Lev Ran <etai@il.ibm.com>
Signed-off-by: Etai Lev Ran <etail@il.ibm.com>
Signed-off-by: Etai Lev Ran <etail@il.ibm.com>
Commits produced using "git commit --fix" are great for review, but must be squashed before a PR is merged. Signed-off-by: Stephen Kitt <skitt@redhat.com>
Signed-off-by: Etai Lev Ran <etail@il.ibm.com>
Signed-off-by: Donald Hunter <donald.hunter@redhat.com>
11dbad1
to
1b28b57
Compare
Signed-off-by: Etai Lev Ran <etail@il.ibm.com>
Signed-off-by: Etai Lev Ran <etail@il.ibm.com>
Signed-off-by: Etai Lev Ran <etail@il.ibm.com>
Signed-off-by: Etai Lev Ran etai@il.ibm.com