Fabric: 'abort_on_prompts' overrides warn_only = True

Criado em 22 out. 2012  ·  12Comentários  ·  Fonte: fabric/fabric

Tentar usar abort_on_prompts e warn_only = True faz com que abort_on_prompts substitua warn_only e a malha ainda lança um SystemExit

In [6]: from fabric.api import sudo, execute, cd, env, run, local

In [7]: with settings(warn_only = True):
    result = local("ls -ltrh")
   ...:     
[localhost] local: ls -ltrh
total 188K
In [8]: with settings(warn_only = True):
    result = local("ls -ltrh /tmp/tartratrat")
   ...:     
[localhost] local: ls -ltrh /tmp/tartratrat
ls: cannot access /tmp/tartratrat: No such file or directory

Warning: local() encountered an error (return code 2) while executing 'ls -ltrh /tmp/tartratrat'


In [9]: env['abort_on_prompts'] = True

In [10]: with settings(warn_only = True):
    result = local("ls -ltrh /tmp/tartratrat")
   ....:     
[localhost] local: ls -ltrh /tmp/tartratrat
ls: cannot access /tmp/tartratrat: No such file or directory

Warning: local() encountered an error (return code 2) while executing 'ls -ltrh /tmp/tartratrat'


In [11]: with settings(warn_only = True):
    result = run("ls -ltrh /tmp/tartratrat")
   ....:     

Fatal error: Needed to prompt for the target host connection string, but abort-on-prompts was set to True

Aborting.
An exception has occurred, use %tb to see the full traceback.

SystemExit: 1
To exit: use 'exit', 'quit', or Ctrl-D.
Bug Core

Todos 12 comentários

(Protip, use o link "Github Flavored Markdown" acima dos campos de texto, ele mostrará como formatar as coisas corretamente. Corrigido sua descrição para você :))

Eu diria que, na maioria dos casos, quando os usuários alternam abort_on_prompts , eles estão _provavelmente_ esperando o comportamento atual (abortar) e não um aviso e continue. warn_only=True normalmente se aplica ao que fazer quando _o programa remoto_ falha, vs o próprio Fabric abortando.

No entanto, reconheço que esta situação em que ambos são verdadeiros não está bem definida / documentada. Além disso, a maioria dos outros usos de abort() na base de código foram substituídos por chamadas para error() que é o que lida com a lógica "abortar se warn_only=False ".

Por enquanto, farei a convocação de que a consistência supera a possibilidade de um usuário tentar abortar nos prompts e ser impedido por um warn_only=True inesperado e fará a alteração que você está solicitando. Se outras pessoas vierem reclamando, eu colocarei você na frente;)

Refletindo, estou realmente dividido sobre isso; Eu posso ver a mudança bagunçando as coisas para os usuários que, como mencionado, realmente querem que o Fabric exploda com solicitações inesperadas. Erros ocultos podem ser incrivelmente frustrantes de rastrear.

@pkittenis - que situação do mundo real você está enfrentando em que isso é um problema para você? Você poderia usar try/except SystemExit para contornar isso?

Se você estiver bloqueado por isso, o que pode fazer mais sentido é adicionar alguma nova opção de configuração (com algum nome idiota como warn_trumps_abort talvez) para que as pessoas em seu caso de uso possam controlar o comportamento, sem causar uma mudança inesperada para usuários atuais.

O problema é que o comportamento de abort_on_prompts faz com que o tecido lance um SystemExit quando cai para No hosts found. Please specify (single) host string for connection: quando um comando tem um erro.

Ao usar o fabric como uma API, isso é apenas IMO errado. O usuário da API já configurou warn_only para evitar um SystemExit na execução e, em vez disso, ser capaz de manipular códigos de retorno dentro do código. Isso é ótimo.

Em seguida, o usuário define abort_on_prompts e, em vez de obter o código de erro para seu comando quando ele falha, obtém um SystemExit por causa do fallback para enter a host e do uso de abort_on_prompts . Pode lidar com a exceção, claro, mas nesse caso você não pode mais ver o código de retorno do comando que falhou.

Pode contornar agora, redefinindo abort_on_prompts volta para False, mas isso precisa ser feito em cada comando que pode ou não falhar,

Suponho que o melhor seria um sinalizador para desabilitar completamente os prompts integrados do fabric que devem ser usados ​​na linha de comando, particularmente o No hosts found.. one, ao usar o fabric como uma API. Então abort_on_prompts não causaria um SystemExit, pois não há prompt para causá-lo.

+1 - Estou enfrentando esse mesmo problema agora. Meu caso de uso concreto é que estou usando o Fabric para fazer uma verificação nos nós de nuvem provisionados recentemente e confirmar se esses nós têm acesso SSH com a chave pública apropriada. Como resultado, eu preciso realmente _catch_ a exceção abort_on_prompts. Por enquanto, vou capturar SystemExit explicitamente, mas isso parece muito errado, de fato.

+1 - Eu também gostaria de capturar as exceções abort_on_prompts.

: +1: Estou na mesma situação em que não quero que SystemExit seja gerado - isso mata meus trabalhadores do aipo.

Neste estágio, sinto que esse nível de mudança se encaixa melhor na versão 2.0, que está sendo projetada com o caso de uso da API primeiro e o caso de uso da CLI como um caso de uso secundário / wrapper. Mudar o comportamento no 1.x será muito surpreendente / confuso / sujeito a adicionar bugs.

Marcando como 2.x e deixando aberto para que eu possa revisitar e ter certeza de que o considero ao escrever essa parte da API.

+1 - quando abort_on_prompts e warn_only são _Verdadeiros_, warn_only deve prevalecer.
Outra discussão sobre este problema, por @reeesga : https://github.com/fabric/fabric/issues/521

+1

+1 - quando abort_on_prompts e warn_only são True, warn_only deve prevalecer. Uma configuração mais recente para fazer isso também é adequada

Alguma atualização disso ?
Eu peguei SystemExit, mas isso apenas torna minha saída feia ...

Veja por si mesmo:

webapps2adm001.qa.aws.company.com: Conexão como root SUCCESS.
webapps2001.qa.aws.company.com: Conexão como root SUCCESS.

Erro fatal: necessária para solicitar uma senha de conexão ou sudo (host: webapps3001.ia.aws.company.com), mas a entrada seria ambígua no modo paralelo

Abortando.
webapps3001.ia.aws.company.com: Falha na conexão como root. Sair do sistema: 1
webapps3adm001.ia.aws.company.com: Conexão como root SUCCESS.

Eu só quero manter a linha após o aborto. Não quero ver as mensagens de erro.

Também estou enfrentando esse problema e adoraria ver o comportamento atual alterado.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

haydenflinner picture haydenflinner  ·  5Comentários

shadyabhi picture shadyabhi  ·  5Comentários

yuvadm picture yuvadm  ·  5Comentários

Grazfather picture Grazfather  ·  4Comentários

peteruhnak picture peteruhnak  ·  4Comentários