-
Notifications
You must be signed in to change notification settings - Fork 20
Conversation
Codecov Report
@@ Coverage Diff @@
## main #479 +/- ##
==========================================
+ Coverage 48.84% 48.85% +0.01%
==========================================
Files 54 54
Lines 8943 8947 +4
==========================================
+ Hits 4368 4371 +3
- Misses 4575 4576 +1
Continue to review full report at Codecov.
|
|
||
|
||
def upgrade(): | ||
op.add_column('scaling_groups', sa.Column('wsproxy_address', sa.String(length=1024), nullable=True)) |
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.
This is just a question. Is there a reason to set wsproxy_address
per scaling group? I originally thought that the wsproxy endpoint can be configured globally from manager.toml
or somewhere else. So, I wonder if there a scenario for multiple wsproxies for a different scaling group.
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.
For more scalability and distributed deployments, I think it would be better to have this option, although in most cases it would fallback to the manager.toml
configuration value.
Note: In the future this would be refactored using RBAC (also the default storage proxy for scaling groups / allowed storage proxies for user groups as well).
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.
Just a minor change please in the code level.
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.
Sorry again, but another minor fix suggestion: rename wsproxy_address
to wsproxy_addr
, to be consistent with agent_addr
in other places.
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.
Found a minor typo.
...i/backend/manager/models/alembic/versions/60a1effa77d2_add_coordinator_address_column_on_.py
Outdated
Show resolved
Hide resolved
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.
Please make the Redis-based caching logic to "stand out", i.e., any new code readers could easily recognize it as a caching logic.
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.
Just a minor refactoring please.
Other parts looks good!
This API is dedicated to start a container application from container's service definitions, while existing `stream_proxy` API performs both `start_service` and then actual websocket proxying, for wsproxy v2. Note: wsproxy v2 directly connects the user clients and the container apps to provide better horizontal scalability. The separation of those two functions is the key starting point. Co-authored-by: Jonghyun Park <[email protected]> Backported-From: main (22.03) Backported-To: 21.09
this commit adds new
start_service
API under session, which starts kernel service on backend.ai session and returns service access information (host and port).