2015-05-11 7 views

risposta

6

Come già sottolineato da Bruce, questo è codificato. Ma ho anche un problema con questo comportamento, dato che il mio IDE mostra il nome del file nella scheda e ho usato un tab di bazillion chiamato "main.yml".

La mia configurazione di serie è quella di avere due file:

  • main.yml
  • ruolo nome- .yml

Nel main.yml poi semplicemente è un include compito allo role-name.yml. Oltre a questo, gestisco i tag, perché voglio che tutti i miei ruoli vengano etichettati con il loro nome.

--- 

- include: role-name.yml 
    tags: role-name 

... 
+0

Un approccio simile anche qui - main.yml include il mio "Posso vedere a cosa sto lavorando basato solo sul file" del file yaml. Dato che nessun altro codice è elencato nel file main.yml diverso dal percorso verso il file con il nome migliore, a parte la creazione iniziale, non vengono mai modificati, quindi non creano mai confusione. – PhillipHolmes

+0

migliore opzione (a corto di patch Ansible) che ho visto, è strano per me che questo include è relativo alla directory di ruolo, non il file main.yml. Hai qualche consiglio per rendere ./vars/main.yml meno stupido? – ThorSummoner

3

Purtroppo non c'è modo di farlo. Il nome main.yml è hardcoded nel codice sorgente ansible. (Se davvero a cuore, cercare la funzione _resolve_main in this file.)

compiti di ruolo sarà sempre nel file roles/<rolename>/tasks/main.yml, variabili in roles/<rolename>/vars/main.yml, ecc Poiché il percorso che ogni file vive in fornisce il dettaglio completo del nome del ruolo & scopo del file, non c'è davvero bisogno di cambiare il nome da main.yml. Si finirebbe con qualcosa come roles/<rolename>/tasks/<rolename>.yml che è ridondante.

Questo è tutto documentato nel documento di Ansible Best Practices.

+3

Perché non si può finire con percorsi come 'ruoli//tasks.yml'? IMO, sarebbe bello poter usare questa semplificazione. Ci sono trappole nascoste? –

2

Come una soluzione alternativa può comodamente link simbolico chiamato rolename_tasks.yml a main.yml ...