Consider admission control for Guest Agent RPCs
Mantenedores costumam responder em até 1 dia
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 35/100
- Tipo de issue
- Funcionalidade
- Clareza
- Precisa de esclarecimento
- Status de atividade
- Ativa
- Stack de tecnologia
- rust
- Domínio
- backend-api-design, performance
Direção de pesquisa
Nenhum arquivo, teste ou ponto de entrada é nomeado. Comece localizando o limite centralizado do cliente Guest Agent e revisando como as chamadas RPC de VMM, os deadlines e as métricas são tratados atualmente. Defina a política de concorrência e sobrecarga com base na capacidade de implantação e no uso medido de recursos; o trabalho estará concluído quando houver um design acordado que cubra os limites globais e por VM, o comportamento sob sobrecarga e as métricas.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Problem
VMM proxies several API methods to the Guest Agent over vsock. Request deadlines bound how long each individual call can remain active, but they do not cap the number of calls that can execute concurrently. A burst of requests, or many unresponsive guests, could therefore create a large number of concurrent connection attempts and request tasks until their deadlines expire.
Possible approach
Consider adding admission control at the centralized Guest Agent client boundary, with:
- a global VMM concurrency limit;
- an optional per-VM concurrency limit so one guest cannot consume the full budget;
- explicit overload behavior (fail fast versus bounded queueing);
- metrics for active calls, rejected calls, and timeout rates;
- limits derived from expected deployment size and measured resource use rather than hard-coded without capacity data.
This is intentionally tracked separately from request timeout hardening so the timeout fix remains small and the operational policy can be reviewed independently.
- Linguagem predominante
- Rust
- Estrelas
- 555
- Forks
- 97
- Merge médio
- 1d 3h
- PRs com merge (30d)
- 199
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de Dstack-TEE/dstack
-
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 35/100
Dstack-TEE/dstack#1384 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 30/100
Dstack-TEE/dstack#1301 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 55/100
Dstack-TEE/dstack#1300 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 48/100
Dstack-TEE/dstack#1299 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 48/100
Dstack-TEE/dstack#1298 ·
Mantenedores costumam responder em até 1 dia
Todas as issues de Dstack-TEE/dstack
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
trezor/trezor-firmware#7997 ·
Mantenedores costumam responder em até 2 dias
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
smol-machines/smolvm#1489 · 1 comentário · 1 reação ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 88/100
Mantenedores costumam responder em até 1 dia