SCRUM issueshttps://gitlab.c3sl.ufpr.br/le6/SCRUM/-/issues2018-11-29T13:43:36Zhttps://gitlab.c3sl.ufpr.br/le6/SCRUM/-/issues/624Possibilitar a passagem de parâmetros extra do avahi através do cli do le-lab2018-11-29T13:43:36ZlegtonPossibilitar a passagem de parâmetros extra do avahi através do cli do le-labAtualmente é possível se usar parâmetros extra do avahi, porém é impossível de se passar esses parâmetros para a CLI do le-lab.Atualmente é possível se usar parâmetros extra do avahi, porém é impossível de se passar esses parâmetros para a CLI do le-lab.legtonlegtonhttps://gitlab.c3sl.ufpr.br/le6/SCRUM/-/issues/576Atributos no le-lab2018-09-20T14:41:36ZLucas Sulzbachls17@inf.ufpr.brAtributos no le-labAtualmente o le-lab é orientado aos eventos de anunciar e desanunciar serviços, mas não ao de setar atributos, por exemplo, o que seria interessante para otimizar a solução em #534.
Alguns atributos poderiam ser padronizados e generaliz...Atualmente o le-lab é orientado aos eventos de anunciar e desanunciar serviços, mas não ao de setar atributos, por exemplo, o que seria interessante para otimizar a solução em #534.
Alguns atributos poderiam ser padronizados e generalizados para os serviços, como um de enable/disable. No caso do epoptes, é interessante dar ao administrador da máquina a autonomia de não ser "escravizado" por outro computador da rede.
A funcionalidade da #534 soluciona parcialmente este problema, pois permite que o admin impeça o epoptes de tornar a máquina um cliente em sessões futuras, mas não em uma sessão já aberta (devido à complexidade de implementação). Outra desvantagem desta implementação é que o script do serviço deixa de ser um processo que executa uma tarefa simples e morre rapidamente para se tornar ele mesmo um daemon que fica escutando eventos e sobrecarregando ainda mais o LE.https://gitlab.c3sl.ufpr.br/le6/SCRUM/-/issues/474Remover necessidade de reiniciar o le-lab quando novo serviço é criado2019-10-29T18:21:21ZDiego Giovane Pasqualindpasqualin@inf.ufpr.brRemover necessidade de reiniciar o le-lab quando novo serviço é criadoSão três opções:
1. Adicionar um *handler* para `systemctl reload le-lab`, que iria reler os diretórios dos serviços e reconstruir a estrutura interna do le-lab.
2. Sempre que necessário, o le-lab poderia ler os diretórios e construir e...São três opções:
1. Adicionar um *handler* para `systemctl reload le-lab`, que iria reler os diretórios dos serviços e reconstruir a estrutura interna do le-lab.
2. Sempre que necessário, o le-lab poderia ler os diretórios e construir essa estrutura.
3. Um *watch* seria configurado para recarregar o le-lab sempre que arquivos fossem alterados nos diretórios esperados.
Particularmente acho a primeira opção mais fácil de implementar e mais eficiente. Além disso diversos outros serviços comuns do mundo unix seguem essa linha (nginx, apache, postgresql, etc).v6.2.1-2legtonlegtonhttps://gitlab.c3sl.ufpr.br/le6/SCRUM/-/issues/467Criar diagrama de execução para o le-lab2018-12-06T12:38:24ZDiego Giovane Pasqualindpasqualin@inf.ufpr.brCriar diagrama de execução para o le-labDada a complexidade do le-lab, seria útil ter no README alguns diagramas descrevendo o fluxo de mensagens no programa. Ao menos um para o processo de *advertising* de um serviço e outro para a requisição de variáveis remotas.Dada a complexidade do le-lab, seria útil ter no README alguns diagramas descrevendo o fluxo de mensagens no programa. Ao menos um para o processo de *advertising* de um serviço e outro para a requisição de variáveis remotas.v6.2.1-2Guilherme Becker AggeGuilherme Becker Agge