Судя по жесту коллеги, в то, что там показывают можно всунуть два пальца (розетка что-ли?)
Ну или он двумя пальцами (зачем?) на что-то указывает (смотрит при этом в первую девушку)
Тут нужна конференция для мужчин, которые заставляют мужчин более здраво мыслить и не давать волю стереотипам. А женщины сами подтянуться. Потому что те, которые могут и умеют уже в отрасли, и после пары-тройки недель притирки очень уважаемы коллегами и очень сильно поддерживаемы (в отличии от мужчин). А те, которые вне ИТ, я думаю, в ИТ и не стремятся, к сожалению.
Не могу. Да и зачем?
YANG — это способ описания схемы данных. Точка.
На нем вы можете описать свою модель. А данные положить во что угодно, куда можно уложить иерархическую схему. Например gobgp описывает свою конфигурацию с помощью расширения OpenConfig модели BGP своими значениями. А потом данные хранит в yaml или toml: https://github.com/osrg/gobgp/tree/master/tools/pyang_plugins
У вас в yaml описаны данные. Можете задать их схему на YANG. Можете на чем угодно другом. Удобный инструмент работы с YANG — pyang. Является стандартом де факто в IETF и OpenConfig. Google пытается пилить goyang: https://github.com/openconfig/goyang, но пока далеко не ушли.
Попробуйте использовать YANG для своих целей, посмотрите, насколько он вам поможет своей более "сетевой" природой. Там сетевые только модели, описанные на YANG, но сам YANG к сетям имеет мало отношения.
Не во все сетевые ОС закладывалась возможность использовать API, и производителям бывает непросто встроить их поддержку в свои продукты.
Ага. А OpenConfig будет легче встроить, чем какой-то свой API? Я думаю, что если свой API не смогла компания осилить, то куда же ей до Openconfig-а.
Если на каждой из них нужно настроить одну и ту же функцию, несложно догадаться, что хотелось бы, чтобы она везде настраивалась одинаково!
А то что функция имеет разные фичи на разных девайсах — это как?
А то что концепции одной функции у разных вендоров разные — как это уместить в одной модели?
На заре своей деятельности «неформальная рабочая группа» OpenConfig весьма продуктивно работала, создавая модели для BGP, MPLS и управления интерфейсами.
Например, для компании Juniper поддержка моделей IETF и OpenConfig не составит труда.
Составит труд. Не все параметры из моделей juniper-а есть в модели OpenConfig-а и наоборот. Как тут быть? Пойти по пути расширения стандартной модели своими проприетарными фичами? Тогда получим то, что имеем сейчас — каждый вендор будет иметь свой личный зоопарк из моделей.
Потребитель, который может заплатить, как правило, получает, чего хочет.
А хочет ли?
Когда стандартные сетевые модели станут встречаться повсеместно, мир откроется для разработки инструментария, платформ оркестровки, ПО для мониторинга и SDN контроллеров, и на рынке появятся прекрасные инструменты для конфигурирования и отчетности.
А сейчас что мешает?
то сейчас многие производители активно добавляют поддержку различных интерфейсов прикладного программирования (OpenFlow, OpenStack, JSON, XML, NETCONF/YANG и пр.).
Извините, но как все эти слова в скобках связаны друг с другом?
Мне лично кажется, что сайту PacketPushers занесли за эту статью.
По моему опыту работы с YANG, yang хорош для задания своих моделей и для генерации кода на базе этих моделей. То есть еще один такой protobuf, thrift, asn.1. Зачем нужно было еще один выдумывать — видимо для поднятия денег.
Существующие модели для YANG-а сложно использовать в реальных проектах.
Во-первых YANG модели никто не поддерживает.
Во-вторых YANG модели не полны для вендоров оборудования.
Хех. Я Sybase ASE жил. в 2000 году. Использовал документацию от MS SQL 6.5, потому что своя была просто ужасна, а от SQL на 99% совпадала.
А почему бедолаги? Отличный сервер, особенно сравнивая с тем, что под линуксом тогда было.
«Настройки оборудования Cisco» звучит страшно. На самом деле вещь очень простая — текст.
Я думаю что 90 процентов цисковиков настройки циско в блокноте пишут и не жужжат.
Используя perl или python для разворачивания шаблонов.
> В текущих условиях, если пользователь решил загрузить контейнеры в VSphere, ему приходится все скопом помещать их в одну единственную виртуальную машину. Таким образом, если что-то случится с одним из контейнеров, повреждения могут получить и все остальные, находящиеся в ВМ. Распределение контейнеров по разным ВМ обеспечивает их сохранность и аккуратное управление платформой.
Я тут недопонял. Это что за технология, которая позволяет одному контейнеру повреждать данные другого? И это контейнеры?
Ну или он двумя пальцами (зачем?) на что-то указывает (смотрит при этом в первую девушку)
Что девушки там увидели? Есть предположение? Что может быть так смешно в ИТ?
Или что конкретно вы делаете?
Производительность DPDK зависит от:
YANG — это способ описания схемы данных. Точка.
На нем вы можете описать свою модель. А данные положить во что угодно, куда можно уложить иерархическую схему. Например gobgp описывает свою конфигурацию с помощью расширения OpenConfig модели BGP своими значениями. А потом данные хранит в yaml или toml: https://github.com/osrg/gobgp/tree/master/tools/pyang_plugins
У вас в yaml описаны данные. Можете задать их схему на YANG. Можете на чем угодно другом. Удобный инструмент работы с YANG — pyang. Является стандартом де факто в IETF и OpenConfig. Google пытается пилить goyang: https://github.com/openconfig/goyang, но пока далеко не ушли.
Попробуйте использовать YANG для своих целей, посмотрите, насколько он вам поможет своей более "сетевой" природой. Там сетевые только модели, описанные на YANG, но сам YANG к сетям имеет мало отношения.
Ага. А OpenConfig будет легче встроить, чем какой-то свой API? Я думаю, что если свой API не смогла компания осилить, то куда же ей до Openconfig-а.
А то что функция имеет разные фичи на разных девайсах — это как?
А то что концепции одной функции у разных вендоров разные — как это уместить в одной модели?
У меня есть подозрение что неформальная группа стартовала с использования наработок Google-а, который, как раз, эту группу (OpenConfig) и двигает: https://www.nanog.org/sites/default/files//meetings/NANOG64/1011/20150604_George_Sdn_In_The_v1.pdf
А хочет ли?
А сейчас что мешает?
Извините, но как все эти слова в скобках связаны друг с другом?
Мне лично кажется, что сайту PacketPushers занесли за эту статью.
По моему опыту работы с YANG, yang хорош для задания своих моделей и для генерации кода на базе этих моделей. То есть еще один такой protobuf, thrift, asn.1. Зачем нужно было еще один выдумывать — видимо для поднятия денег.
Существующие модели для YANG-а сложно использовать в реальных проектах.
Во-первых YANG модели никто не поддерживает.
Во-вторых YANG модели не полны для вендоров оборудования.
А почему бедолаги? Отличный сервер, особенно сравнивая с тем, что под линуксом тогда было.
Я думаю что 90 процентов цисковиков настройки циско в блокноте пишут и не жужжат.
Используя perl или python для разворачивания шаблонов.
В итоге — не убедили. Не нужны эти скилзы.
github.com/Microsoft/ChakraCore/pull/207
Я тут недопонял. Это что за технология, которая позволяет одному контейнеру повреждать данные другого? И это контейнеры?
Тут и defer-ы появляются и try-catch критикуются.