Closed ncdc closed 4 months ago
ncdc
commented
2 years ago | Old | New |
|---|---|
| virtual workspace | service |
| APIExport virtual workspace | APIExport service |
| Syncer virtual workspace | Syncer service |
| Workspaces virtual workspace | Workspaces service |
| Initializing workspaces virtual workspace | Initializing workspaces service |
| pkg/virtual | pkg/service |
| cmd/virtual-workspaces | cmd/kcp-services (?) |
| docs/virtual-workspaces.md | docs/services.md |
stevekuznetsov
commented
2 years ago +10000
pweil-
commented
2 years ago Some of these make me wonder if we'll be muddying up the term service. A service, in my head, encapsulates the entirety of:
But I like where this is going. Is there value in keeping the workspace concept in there? Like virtual workspace -> service workspace. Or maybe that confuses the place the service is deployed too, so maybe virtual workspace -> service api workspace.
ncdc
commented
2 years ago @pweil- we need to remove "workspace" from this term - these "things" are not workspaces 😄
pweil-
commented
2 years ago 😆
MikeSpreitzer
commented
1 year ago If I understand correctly, the concept here is very analogous to what, in the database community, is called a "view". I think we should focus on that term, it will readily lead the reader in the right direction.
If I understand correctly, there is one more critical specific feature of the concept here, which is that a virtual workspace looks the same, to a client, as a plain Kube cluster or a kcp workspace. That is, it provides what I call a "kube API service".
So I suggest the following possibilities.
I prefer the first two because I think they are less restrictive in semantics. The latter two suggest that one of these is a view of one API sservice, and I think that cardinality restriction is not something we desire here.
stevekuznetsov
commented
1 year ago Yep, we had brandied around the "view" terminology early on as well.
ncdc
commented
1 year ago I like view as that doesn't conflict with the core v1 Service API type. Would also rework /services to /views in the URLs.
@sttts @davidfestal @stevekuznetsov let's nail this down - would you prefer service or view? (or <shudder> do you want to suggest something else?)
davidfestal
commented
1 year ago I really prefer views
ncdc
commented
1 year ago This is what the table looks like for views:
| Old | New |
|---|---|
| virtual workspace | view |
| APIExport virtual workspace | APIExport view |
| Syncer virtual workspace | Syncer view |
| Initializing workspaces virtual workspace | Initializing workspaces view |
| pkg/virtual | pkg/view (or pkg/views) |
| cmd/virtual-workspaces | cmd/kcp-views |
| docs/virtual-workspaces.md | docs/views.md |
stevekuznetsov
commented
1 year ago view sounds good to me
stevekuznetsov
commented
1 year ago Proposal: blast this out to the mailing list, give a spot at the next community call to speak or forever hold the peace, and then change it over next week.
samyak-jn
commented
1 year ago +1 for view :")
kasturinarra
commented
1 year ago +1 for view
wangke19
commented
1 year ago +1 for view. Just like the concepts of table and view of database.
kcp-ci-bot
commented
6 months ago Issues go stale after 90d of inactivity.
After a furter 30 days, they will turn rotten.
Mark the issue as fresh with /remove-lifecycle stale.
If this issue is safe to close now please do so with /close.
/lifecycle stale
kcp-ci-bot
commented
5 months ago Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
kcp-ci-bot
commented
4 months ago Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
kcp-ci-bot
commented
4 months ago @kcp-ci-bot: Closing this issue.