Комментарии 6
Я не DevOps. А с точки зрения программиста решение этой проблемы выглядит по другому: коммиты должны быть атомарными. Не надо делать две разные вещи в одном коммите. Если бы сначала поменяли настройки FastEthernet0, а потом — добавили FastEthernet3, то ничего бы не сломалось.
Это в духе ансибля.
Определить в cisco-конфиге, что измененные строчки приходятся на int F0 они могут, а подать команду exit после отправки всех измененных строчек, чтобы вернуться в основной контекст они уже не могут.
Определить в cisco-конфиге, что измененные строчки приходятся на int F0 они могут, а подать команду exit после отправки всех измененных строчек, чтобы вернуться в основной контекст они уже не могут.
Потому что нужно было это запустить на паре хостов для начала.
Не понял, ансибль что, вообще игнорировал указанный в шаблоне "interface FastEthernet3"? Т.е. "interface FastEthernet0" для входа в контекст используется, а с другим интерфейсом это не работает? Такое ощущение, что автор написал о том что не проверял на практике.
Или я что-то упустил (трудности перевода?)?
Это одно из слабых мест подхода Configuration-as-Code.
В руках человека оказывается очень мощный инструмент, при неправильном использовании которого возможны самые печальные последствия.
Ошибка в пробелах.
В числе возможных обходных решений, генерировать конфигурацию, а не руками набивать.
Это помимо code review, и тестовых контуров.
В руках человека оказывается очень мощный инструмент, при неправильном использовании которого возможны самые печальные последствия.
Ошибка в пробелах.
В числе возможных обходных решений, генерировать конфигурацию, а не руками набивать.
Это помимо code review, и тестовых контуров.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как убить вашу сеть с помощью Ansible