bosun continue: discussion

Loop a ser modificado: https://github.com/luizirber/bosun/blob/master/bosun/tasks.py#L83

Em vez de fazer o loop, salvar o (inicio, fim) atual num DB (sqlite?) no home do usuário. Daria para colocar no scratchout no diretório do experimento também, mas o legal de deixar no HOME é que tem histórico de rodadas depois.

========================

O check_status tem uma opção 'oneshot' que ficou um tanto quanto redundante do jeito que está agora: https://github.com/luizirber/bosun/blob/master/bosun/tasks.py#L110

E a única coisa que retorna é se tem job rodando ou não. Inicialmente é o suficiente, mas ele pode retornar mais coisas (teve erro?) que facilitariam o tratamento no run (algum período deu problema? tenta rodar de novo? etc)

========================

No momento tem bastante coisa que fica salva no environ que é dinâmica: qual o nome de cada job rodando, por exemplo. Esses são os primeiros candidatos a ir parar no DB.

#######################################################

chat:

January 28, 2014
11:47 Luiz: pitacos? =P
11:47 Luiz: vou chutar que o azul radioativo é o Léo
11:48 GG: olha, no momento, pro que eu preciso, apenas pegar o conteúdo daquele loop e jogar num outro processo já me resolvia
11:48 Luiz: hmm, como assim?
11:48 Luiz: O que é 'jogar em outro processo'? outro job no tupã?
11:48 GG: um outro processo python
11:49 GG: que fique nesse loop de ressubmissao
11:49 Luiz: mas isso ficaria rodando localmente?
11:49 GG: e que rode no tupa, pq eu quero simplesmente dar um bosun run no meu computador e sair do python
11:49 Luiz: entendi
11:49 GG: pq aí posso mandar um run, e imediatamente editar o namelist, commit/push, e outro run
11:51 unnamed: e aquele problema de dar um run no msm exp ... parece que ele não encavala as novas modificações
11:51 Luiz: é que eu acho que separar a submissão e a verificação ajudam conceitualmente
11:51 Luiz: porque fica complicado você resgatar o processo depois
11:51 GG: eu incluí no meu namelist uma opcao "runname", que coloco no diretorio de saída
11:51 GG: aí antes de rodar eu dou outro prepare e outro run, assim nao rodo por cima do outro
11:52 Luiz: GG, o teu problema não resolve com um & no fim do comando?
11:53 GG: sim
11:53 GG: mas assim é muito fácil
11:53 Luiz: haha
11:53 GG: eu quero ver as mensagens de submissao
11:53 Luiz: mas a solução difícil que eu tô dando você não quer! =P
11:53 GG: ter certeza que nao deu erro lá
11:53 GG: só nao quero ficar vendo esse loop de status da rodada
11:53 Luiz: ah, capisco
11:54 Luiz: é mais problema de output verboso mesmo
11:54 Mabelete: como assim um & no final do comando? 
11:54 GG: assim o comando roda em background, mabel
11:54 Luiz: bosun run:name=expbase &
11:54 Luiz: aí o terminal volta a ser utilizável
11:54 GG: mas nao muito
11:54 Luiz: mas não é uma solução mui prática, porque o bosun vai continuar imprimindo coisas na tela
11:55 GG: pq vai ficar jogando a saída na tela
11:55 GG: enquanto eu estiver digitando
11:55 Luiz: yup
11:55 GG: exatamente
11:55 GG: vou fazer o seguinte:
11:55 GG: separar o que tá dentro do loop numa outra função
11:55 Luiz: GG, o teu problema é só os prints
11:55 Luiz: principalmente dentro do check_status
11:56 Luiz: https://github.com/luizirber/bosun/blob/master/bosun/tasks.py#L143
11:56 Luiz: Dá para só comentar eles
11:56 GG: se eu fizer com & sim, aí precisaria de uma opção não verbose
11:57 GG: fechou entao, vou colocar uma opcao verbose=True como default no check_status
11:57 Luiz: isso, pode tirar a oneshot
11:58 Luiz: uma boa opção, querendo tirar o loop, é pensar um pouco em como colocar o run num job na fila auxiliar
11:59 Luiz: estando na fila auxiliar ele consegue ler o HOME para salvar status
11:59 Luiz: e consegue disparar coisas nos nós de computação
12:00 Luiz: daria para deixar rodando em algum nó de serviço também, mas eu sempre me perco para localizar em que nó tá rodando
12:02 GG: vou clonar o repo e fazer o pull request
12:02 Luiz: \o/
12:03 Luiz: se quiser aprender sobre logging no python, talvez seja um bom momento =]
12:03 Luiz: http://docs.python.org/2/howto/logging.html
12:04 Luiz: aí dá para controlar na linha de comando o nível de verbosidade
12:04 Luiz: mas é um nice to have, por enquanto o verbose no check_status resolve
12:05 Luiz: eu nunca fui muito atrás porque logging no fabric é um feature antigo nunca implementado =( https://github.com/fabric/fabric/issues/57
12:11 GG: tem mais prints
12:11 GG: environ['model'].check_status(....)
12:11 GG: onde fica isso?
12:12 Luiz: ah
12:12 Luiz: é o check_status de cada modelo
12:12 Luiz: vai ter em coupled, agcm e mom
12:13 GG: hmmm entao ja começa a valer a pena o logging
12:13 GG: ehehe
12:13 Luiz: https://github.com/luizirber/bosun/search?q=check_status&ref=cmdform
12:14 GG: bom, vou fazer o logging só nesses por enquanto
12:14 GG: depois faço um refatoramento maior
12:14 Luiz: já é um bom começo =]
12:14 GG: trocar todos os prints por logging
12:16 Luiz: aqui tem um cara que fez isso no fabric: https://github.com/tswicegood/fabric/commit/89c3cec8a8aa10d583a35a6201c1b4fd424f795f
12:16 Luiz: pode ser uma boa referência