Ir para o final dos metadados
Ir para o início dos metadados

1. Visão geral

Tutoriais integrados a interface do LS-WEB são tutoriais que podem ser executados pelos usuários do testbed de forma rápida e fácil onde o usuário apenas necessita ter acesso a interface WEB e o tutorial será executado utilizando o próprio OMF. Os tutoriais podem ter entradas configuradas de acordo com o experimento que o usuário deseja rodar e é mostrado ao usuário a saída do console da execução do OMF, além de ter a possibilidade de mostrar ao usuário a coleta dos dados do experimento em forma de gráficos e em tempo real. Os tutoriais podem ser acessados via portal LS-WEB pelo menu "Tutorials" que está disponível a todo usuário logado na ilha que possui suporte aos tutoriais.

Figura 1: Acessando os tutoriais integrados ao LS-WEB


Os usuários poderão, caso desejem, rodar os experimentos dos tutoriais manualmente, utilizando o comando "omf exec" (que o próprio LS-WEB utiliza para executar o tutorial). Os scripts utilizados nos tutoriais estão todos disponíveis na home do usuário do testbed em "/home/<Instituição>/<usuário sem o @instituição>/tutorials/omf_experiments".

Como o LS-WEB roda por baixo o experimento do tutorial utilizando o próprio comando exec do OMF, neste tutorial não vamos ensinar como criar experimentos para o OMF, de modo que assumimos que o experimento OMF já está criado e se deseja apenas integrar e disponibilizar o experimento para que este seja executado utilizando o LS-WEB. Naturalmente, para prosseguir com a integração precisamos que o arquivo de descrição do experimento no formato OEDL já esteja criado e localizado no diretório "/home/tutorials/omf_experiments/" com a permissão 555. Abaixo um exemplo de um script OEDL utilizado no tutorial 1 "Wireless experiment", integrado ao LS-WEB.

Script OEDL do tutorial 1: Wireless Experiment

Observem que as variáveis que serão configuradas durante a execução do experimento devem estar todas definidas por "defProperty", conforme o exemplo acima, pois deste modo podemos substituir o valor dessas variáveis na execução do experimento via comando "omf exec".

A lista de aplicações instrumentadas e que podem ser utilizadas no experimento OMF está disponível em "/usr/share/omf-expctl-5.4/repository/". abaixo temos a lista das aplicações que foram instrumentadas para serem utilizadas nos tutoriais e que podem ser utilizadas em quaisquer experimentos OMF:

NomeIdentificação via OEDLDescrição
iperftutorials:iperfAplicação do iperf instrumentada para coletar dados de saída do iperf, como pacotes de entrada e saída.
iwdatatutorials:iwdataAplicação instrumentada para coletar dados do comando iw. Atualmente a aplicação coleta apenas o RSSI.
sstutorials:ssAplicação instrumentada para coletar dados do comando ss. Atualmente a aplicação coleta apenas o RTT.
hostapdtutorials:utils:hostapdAplicação do hostapd instrumentada para criar uma rede em modo AP-Station.
wlanconfigtutorials:utils:wlanconfigAplicação instrumentada para configurar a interface dos nós utilizando ifconfig, iw e iwconfig. Esta aplicação utiliza o hostapd e o wpa instrumentado caso necessário.
wpatutorials:utils:wpaAplicação do wpa supplicante instrumentada para estabelecer a conexão em uma rede AP-Station.

2. Criando o tutorial integrado no LS-WEB

O LS-WEB foi desenvolvido utilizando o modelo arquitetural MVC, ou seja, ele possui 03 camadas bem divididas, são elas:

  1. Modelo (MVC) - Camada responsável pelo acesso aos dados requisitados pela base de dados (No LS-WEB essa camada foi omitida por chamadas diretas à API do LS-Sched)
  2. Controle (MVC) - Camada responsável pela execução e controle das páginas. Necessáriamente cada página deve possuir uma ação (action) em uma controladora (controller) responsável por um grupo de entidades ou páginas. No LS-WEB temos as seguintes controladoras:
    1. ErrorsController: Responsável pela renderização de páginas de erro no LS-WEB, como o 404 e 501.
    2. PagesController: Responsável por páginas mais genéricas, como por exemplo a página de contato.
    3. MotherboardsController: Responsável por páginas relativas a motherboards, como por exemplo páginas de visualização, criação, edição e até mesmo remoção de motherboards no sistema.
    4. PxeImagesController: Responsável por páginas relativas a pxe images, como por exemplo páginas de visualização, criação, edição e até mesmo remoção de pxe images do sistema.
    5. ResourcesController: Responsável por páginas relativas aos recursos do sistema. CRUD de recursos e reservas são de responsabilidade desta controladora.
    6. UsersController: Responsável por páginas relativas aos usuários do sistema, como por exemplo cadastro, conta do usuário, etc.
    7. TutorialsController: Responsável pelas páginas relativas aos tutoriais. É AQUI QUE VAMOS ATUAR NO TÓPICO 2.1.
  3. Visualização (MVC) -  Camada responsável pela renderização das páginas, basicamente nela temos os códigos HTML, CSS, jquery etc. Essas páginas recebem as variáveis que podem ser settadas pela controladora, como por exemplo a lista de usuários, etc.

2.1 Criando uma nova ação na controladora dos tutoriais

Para criar uma nova ação que será a controladora do novo tutorial que está sendo desenvolvido, basta criar um método público na classe TutorialsController localizada em "../LS-WEB/Controller/TutorialsController.php". Para explicar como a nova ação pode ser criada usaremos como exemplo a ação utilizada para o tutorial 1: Wireless Experiment, disponível no LS-WEB:

Controladora do tutorial 1: Wireless Experiment

 

  • O if da linha 5 até a linha 23 {if(count($_POST) > 0)} se refere a execução do experimento, ou seja, o que deve ser executado quando o usuário efetivamente clicar no botão de Executar o experimento. Normalmente, se o experimento tiver dados de configuração, como o caso deste tutorial, esses dados chegarão na controladora por meio de $_GET ou $_POST. Neste exemplo os dados estão chegando por $_POST e dentro deste "if" nós verificamos e criamos os dados que serão passados na chamada da API do LS-Sched para execução do experimento. Os dados experados nessa chamada "execute_experiment" são:
    • username: Usuário que está solicitando a execução do experimento (com @<instituição> incluso). Normalmente esse dado será obtido por "$_SESSION[SECURITY_SESSION]['username']", uma vez que essa variável retorna o usuário logado no LS-WEB, ao qual se destina a execução do tutorial.
    • experiment: Nome do experimento a ser executado (mesmo nome do script OEDL incluso no diretório "/home/tutorials/omf_experiments" sem a extensão ".rb).
    • properties: Array contendo as propriedades do experimento, ou seja, as variáveis definidas no script OEDL que poderão ser modificadas e que, naturalmente, devem ter sido inseridas pelo usuário.
  • A linha 21 envia a requisição de execução do experimento para a API LS-Sched e seu retorno é armazenado na variável $executeExperiment onde podemos analisar se houve algum erro no pedido da execução do experimento e que, na linha 22, criamos o balão de mensagem informando isto ao usuário.
  • As linhas 25 à 27 definem os parâmetros comuns a serem utilizados em algumas outras chamadas à API LS-Sched, são elas:
    • is_experiment_executing: Usada na linha 28 e visa saber se o tutorial está sendo executado no momento.
    • getExperimentScript: Usada na linha 32 e visa buscar o script OEDL que é utilizado no tutorial.
  • As linhas 35 à 37 utilizam o método setVariable para settar variáveis que poderão ser utilizadas na páginas (view) do tutorial, ou seja, neste tutorial a view terá acesso as variáveis "is_executing", "is_executing_by_user" e "experiment_script".

2.2 Criando uma página para a ação/tutorial criado

Uma vez com a ação criada na controladora, o nosso próximo passo para a criação do tutorial integrado ao LS-WEB é criar a página que será renderizada para o tutorial. Para isto, basta criar um arquivo de extensão ".vw" dentro do diretório "../LS-WEB/View/Tutorials/". O arquivo deve ter o nome da ação criada na controladora, por exemplo, para o tutorial 1: Wireless Experiment, a sua ação na controladora possui o nome "wireless_experiment", deste modo o arquivo da página deste tutorial deve ser o "../LS-WEB/View/Tutorials/wireless_experiment.vw". Este arquivo irá possuir a view da página, contendo o código html e até mesmo a utilização das variáveis settadas pela ação da controladora dentro de tags do php. Abaixo temos como exemplo a view do tutorial 1: Wireless Experiment:

Página (view) do Tutorial 1: Wireless Experiment

 

  • Observe que na linha 101 utilizamos uma variável que foi settada pela ação da controladora.
  • Os gráficos e a rederização da saída do console da execução do experimento via OMF são coletadas por chamadas assíncronas a um método de coleta criado na API LS-Sched. As chamadas a esse método e a renderização do gráfico e do console são feitas via jQuery/javascript nos arquivos "js/tutorials/flot/statistics.wireless_experiment.js" e "js/tutorials/wireless_experiment.js", conforme carregados nas linhas 12 e 13.

2.3 Criando e/ou ajustando as saídas do experimento

Figura 2: Execução e saída do experimento realizado pelo tutorial.

2.3.1 Criando gráficos utilizando o Flot Charts para visualização dos dados coletados no experimento do tutorial

Como comentado na seção 2.2, o gráfico é criado utilizando uma biblioteca em Jquery chamada Flot Charts. Essa biblioteca é capaz de criar gráficos de diversas formas (barras, estilo pizza, linha, etc) com opções para atualizações em tempo real. Para os tutoriais criados até o momento foi criado utilizando essa biblioteca um gráfico de área que tem opção de zoom e atualização em tempo real com opção desta ser desativada. Deste modo, caso o novo tutorial contenha um gráfico nessas condições, o código desenvolvido pode ser reaproveitado, assim como é feito nos tutoriais já disponíveis. Demais formas de gráficos será necessário consultar e criar utilizando a documentação da biblioteca.

A criação do gráfico consiste de 3 partes:

  1. Código HTML que contém as tags que serão referenciadas na página para a criação do gráfico. (Presente no arquivo .vw)
  2. Método na API do LS-Sched que captura os dados das bases de dados do OML e os retorna em formato para ser plotado no gráfico em formato JSON. (Seção 3)
  3. Código JQuery/Javascript responsável pela chamada assíncrona que busca os dados na API do LS-Sched e cria/modifica o gráfico utilizando a biblioteca do Flot Charts.

 

Código HTML

 

  • Esse é o código criado para interagir com o JQuery/Javacript do gráfico criado utilizando o Flot Charts para os tutoriais. Vocês poderão observar no código do javascript abaixo que várias das tags utilizadas neste código HTML são referenciadas para que o gráfico seja criado corretamente na página do LS-WEB.

 

Código JQuery/Javascript

 

  • A função getData presente nas linhas 2~52 é a responsável pelas chamadas que são realizadas de forma assíncrona para a API LS-Sched e que busca os dados do experimento executado no tutorial.
    • Observe que o método chamado la API do LS-Sched é o get_wireless_experiment_data, alguns outros parâmetros são passados neste método, mas isso veremos posteriormente na seção 3.
    • Uma vez de posse dos dados, o código presente nas linhas 10~50 é responsável por realizar a atualização do gráfico e do output da console na interface.
  • A função updateData presente nas linhas 54~81 é a responsável por atualizar a estrutura de dados que contém os dados dos gráficos. Essa estutura de dados possui os padrões pedidos pela biblioteca do Flot Charts de modo que ela é diretamente utilizada na atualização do gráfico.
  • O código das linhas 83~179 é executado assim que a página é carregada juntamente a este javascript e ele é responsável por iniciar a biblioteca do Flot Charts e configurar todo o gráfico.
  • A linha 179 é a responsável por iniciar as requisições assíncronas à API LS-Sched, realizando a primeira chamada à função getData.

2.3.2 Inserção da saída da console do comando OMF exec

Os dados da saída da console do comando do OMF executado durante o tutorial é obtida através da API do LS-Sched. Para otimizar a quantidade de chamadas feitas à API para se obter os dados de saída do tutorial, é criado um único método no LS-Sched por tutorial, de modo que a chamada ao método do tutorial no LS-Sched retorna os dados coletados pelo OML, a saída do console e, caso necessário, demais dados. Deste modo, fica clara a motivação de a inserção e atualização da saída da console ser executada junta à função de atualização dos dados do gráfico, como exposto no tópico anterior no código das linhas 20~49, ou seja, caso deseje adicionar os dados da saída do console na página do tutorial, basta coloca-lo como dado na chamada do método da API LS-Sched, conforme explicado na seção 3 e adicionar os códigos HTML e javascript correspondentes na view da página:

Código HTML para a saída do console
Código javascript para saída do console

 

  • Observe que a última parte se refere a habilitar o botão de execução do tutorial novamente quando o experimento do tutorial já tiver sido finalizado.

3. Criando um método na API do LS-Sched para buscar dados do experimento da base de dados do OML

O LS-Sched também foi desenvolvido seguindo o mesmo modelo MVC, entretanto a camada de visualização é estática para retornar apenas a saída em formato JSON. No caso dos experimentos temos uma peculiaridade também, que é uma camada de Serviços, respon?avel por executar tarefas auxiliares como chamadas de sistema durante a execução dos métodos de experimentos.

Para criar um método na API do LS-Sched com a finalidade de buscar dados a serem utilizados como saída e integrados na interface do LS-Web iremos precisar basicamente de realizar alterações nos seguintes arquivos:

  • "~/LS-Sched/Controller/ExperimentController.php": Classe controladora do que diz respeito aos experimentos no LS-Sched. Ela irá conter a definição do método que poderá ser utilizado pela API.
  • "~/LS-Sched/Model/ExperimentModel.php": Classe para manipulação de dados do que diz respeito aos experimentos, ou seja, é ela que é responsável por buscar os dados dos experimentos nas bases de dados do OML.
  • "~/LS-Sched/Service/ExperimentService.php": Classe de serviços auxiliares ao experimento. Nela, por exemplo, é que é realizada a leitura da saída do console do OMF para o experimento que está sendo executado.

3.1 Experiment Controller

Para criar um novo método na API LS-Sched basta criar um método público na classe ExperimentController. O nome do método criado dentro da classe será o nome do método chamado pela API, logo se você criar um método de nome teste, ele poderá ser chamado passando o parâmetro "?method=teste" para à API.

Como exemplo, abaixo temos o código do método para a coleta dos dados do tutorial 1: Wireless Experiment:

Código da controladora do método da API

 

  • Este método define o método da API "get_wireless_experiment_data" ou "getWirelessExperimentData" (aceita tanto padrão camel quanto underscore).
  • Todos os métodos de API devem receber um parâmetro que irá conter os parâmetros de entrada da chamada.
    • O parâmetro será um array em forma de dicionário dos parâmetros passados durante a chamada.
    • Como pode ser visualizado nas linhas 8 e 9, utilizamos os parâmetros da chamada "before_time_size" e "now_get_time".
  • O retorno do método deve ser convertível para um JSON, ou seja, se o retorno for um objeto, este deve implementar a interface JsonSerializable. Arrays, strings, booleanos e numéricos são convertíveis naturalmente.
  • Na linha 12 utilizamos um método da model dos experimentos para buscar os dados do iperf coletados para este experimento.
  • Nas linhas 14~21 utilizamos o serviço de experimentos e a model para buscar a saída da console do experimento OMF que está sendo executado durante o tutorial.
 

Após criar o método da API, você deverá configurar quais são os parâmetros de entrada (caso não exista você pode pular essa parte) que o seu método aceita e quais os tipos de dados eles devem ser. Essa configuração deve ser feita no método getMethodParameters() encontrado na classe ExperimentController:

Método para definição de parâmetros de entrada

 

  • Basta adicionar um "case" dentro do switch das linhas 11~35 com o nome de seu método definindo quais são os parâmetros obrigatórios ($obParams) e os parâmetros opcionais ($opParams).
    • Basta colocar dentro do array a chave contendo o nome do parâmetro e o valor contendo o tipo dele.
    • Os tipos aceitos são:
      • numeric
      • string
      • bool
      • array
      • double

Para finalizar com nosso desenvolvimento na controladora, precisamos definir o nível de acesso ao método. Por padrão, todos que possuem a key de acesso (passada via parâmetro) possuem acesso aos métodos da API, entretanto, para esses métodos de coleta dos dados para serem visualizados no portal, onde as requisições são feitas por quaisquer clientes, precisamos liberar o acesso sem a necessidade da Key. Para isto basta modificar o método beforeFilter() encontrado na classe ExperimentController:

Controle de acesso

 

  • Observe que nas linhas 8~11 já foi codificado uma forma de liberar o acesso para métodos que não precisam da key, ou seja, para você liberar seu método basta adiciona-lo no array contido na linha 8.
  • Caso seja necessário, você pode programar neste método outras formas de autorização, lembrando que o "parent::beforeFilter()" possui a validação padrão que é verificar se foi passado como parâmetro a chave de acesso e se ela é válida.

3.2 Experiment Model

Apenas será necessário modificar essa classe nos seguintes caso:

  • Nova aplicação instrumentada.
  • Necessidade de modificar a forma de coleta dos dados do OML de alguma aplicação existente.
  • Outros?

Caso você entre em algum dos casos listados acima, basta criar um método nas suas condições na classe e utiliza-lo na controladora ou na classe de serviços como desejar.

3.3 Experiment Service

Caso seja necessário realizar alguma atividade complementar durante a execução, configuração ou até mesmo coleta dos dados do experimento, como ler algum arquivo do sistema, você pode criar um método que o faça nessa classe e a partir daí utiliza-lo na controladora de modo similar ao que foi demonstrado na seção 3.1.

Etiquetas
  • Nenhum