Skip to content
This repository has been archived by the owner on Aug 2, 2023. It is now read-only.

feat: add start_service API #479

Merged
merged 21 commits into from
Dec 17, 2021
Merged

Conversation

kyujin-cho
Copy link
Member

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

@kyujin-cho kyujin-cho requested a review from achimnol September 16, 2021 09:29
@codecov
Copy link

codecov bot commented Sep 16, 2021

Codecov Report

Merging #479 (8890a43) into main (d8d525a) will increase coverage by 0.01%.
The diff coverage is 75.00%.

Impacted file tree graph

@@            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     
Impacted Files Coverage Δ
src/ai/backend/manager/models/scaling_group.py 65.82% <75.00%> (+0.15%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d8d525a...8890a43. Read the comment docs.

@adrysn adrysn added this to the 21.09 milestone Oct 11, 2021


def upgrade():
op.add_column('scaling_groups', sa.Column('wsproxy_address', sa.String(length=1024), nullable=True))
Copy link
Member

@adrysn adrysn Oct 11, 2021

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.

Copy link
Member

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

Copy link
Member

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

Copy link
Member

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

Copy link
Member

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

Copy link
Member

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

@achimnol achimnol added feature and removed feature labels Nov 25, 2021
Copy link
Member

@achimnol achimnol left a 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!

src/ai/backend/manager/api/scaling_group.py Outdated Show resolved Hide resolved
@achimnol achimnol merged commit 06b69a0 into main Dec 17, 2021
@achimnol achimnol deleted the feature/direct-wsproxy-connection branch December 17, 2021 02:49
achimnol pushed a commit that referenced this pull request Dec 17, 2021
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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants