розвиток

Весь вихідний код VyOS розміщено на GitHub в рамках організації VyOS, яку можна знайти тут: https://github.com/vyos

Наш код розбитий на кілька модулів. VyOS складається з кількох окремих пакетів, деякі з них є розгалуженнями вихідних пакетів і періодично синхронізуються з попереднім потоком, тому зберігати весь вихідний код в одному репозиторії було б дуже незручно та повільно. Зараз тривають спроби консолідувати всі специфічні для VyOS пакети рамок/налаштувань у пакет vyos-1x, але базова структура залишиться незмінною, лише з дедалі меншою кількістю пакетів, тоді як базовий код переписується з Perl/BASH на Використання Python і визначення інтерфейсу на основі XML для CLI.

Репозиторій, який містить усі сценарії збірки ISO: https://github.com/vyos/vyos-build

Файл README.md допоможе вам використовувати це сховище верхнього рівня.

Надіслати патч

Патчі завжди більш ніж вітаються. Щоб мати чистий і простий в обслуговуванні репозиторій, у нас є деякі рекомендації щодо роботи з Git. Чисте сховище полегшує автоматичне створення файлу журналу змін.

Хорошим підходом для написання повідомлень комітів є перегляд історії файлів за допомогою git log path/to/file.txt.

Підготуйте патч/комміт

У великій системі, такій як VyOS, яка складається з кількох компонентів, неможливо відстежувати всі зміни та помилки/запити на функції в своїй голові. Для цього ми використовуємо багтрекер, відомий як Phabricator (кращим терміном був би «трекер проблем», але цей застряг).

Інформація використовується трьома способами:

• Слідкуйте за прогресом (що ми вже зробили в цій гілці і що нам ще потрібно зробити).

• Підготуйте примітки до випуску для майбутніх випусків

• Допоможіть майбутнім супроводжувачам VyOS (це можете бути ви!) дізнатися, чому певні речі були змінені в кодовій базі або чому були додані певні функції

Щоб цей підхід працював, кожна зміна має бути пов’язана з номером завдання (з префіксом T) і компонентом. Якщо для змін, які ви збираєтеся внести, немає звіту про помилку/запиту на функції, вам потрібно спочатку створити завдання Phabricator. Якщо у Phabricator є запис, ви повинні посилатися на його ідентифікатор у своєму повідомленні коміту, як показано нижче:

• ddclient: T1030: автоматично створювати каталоги середовища виконання

• Jenkins: додайте поточний ідентифікатор коміту Git до опису збірки

Якщо у комітах вашого запиту на отримання відсутнє посилання Phabricator, ми маємо попросити вас змінити повідомлення коміту. Інакше нам доведеться його відхилити.

Написання хороших повідомлень про коміти

Формат має бути та натхненний: https://git-scm.com/book/ch5-2.html Також варто прочитати https://chris.beams.io/posts/git-commit/

• Єдиний короткий підсумок коміту (рекомендовано 50 символів або менше, не більше 80 символів), що містить префікс зміненого компонента та відповідне посилання Phabricator, наприклад snmp: T1111: або ethernet: T2222:` ` - кілька компонентів можуть бути об'єднані, як у ``snmp: ethernet: T3333

• У деяких контекстах перший рядок вважається темою електронного листа, а решта тексту – основним. Порожній рядок, що відокремлює резюме від основної частини, є критичним (якщо ви повністю не пропускаєте основної частини); такі інструменти, як rebase, можуть заплутатися, якщо ви запускаєте обидва разом.

• Далі слідує повідомлення з описом усіх деталей, таких як:

  • Що/чому/як щось було змінено, полегшує життя кожного під час роботи з git bisect

  • Увесь текст повідомлення коміту, якщо це можливо, має бути обернуто 72 символами, що полегшує читання журналів комітів за допомогою git log на стандартному терміналі (розмір якого буває 80x25)

  • Якщо застосовно, має бути зроблено посилання на попередній комміт, який гарно зв’язує ці коміти під час перегляду історії: Після фіксації abcd12ef ("snmp: це заголовок") відсутній оператор імпорту Python, викликаючи такий виняток: ABCDEF

• Завжди використовуйте опцію -x для команди git cherry-pick під час зворотного або прямого перенесення окремого коміту. Це автоматично додає рядок: (вишня, вибрана з коміту<ID> ) до оригінального повідомлення авторів, що полегшує розділення проблем навпіл.

• Кожен набір змін має бути узгодженим (самовмісним)! Не виправляйте кілька помилок в одному коміті. Якщо ви вже працювали над кількома виправленнями в одному файлі, скористайтеся git add –patch, щоб додати лише частини, пов’язані з однією проблемою, у ваш майбутній комміт.

Обмеження:

• Ми приймаємо лише виправлення помилок у пакетах, відмінних від https://github.com/vyos/vyos-1x, оскільки жодна нова функціональність не повинна використовувати старі шаблони стилю (node.def і код Perl/BASH. Використовуйте новий стиль XML Натомість інтерфейс /Python.

Будь ласка, надішліть свої виправлення за допомогою відомого запиту GitHub для наших репозиторіїв, які знаходяться в організації VyOS GitHub за адресою https://github.com/vyos

Визначте вихідний пакет

Припустімо, ви хочете внести зміни в сценарій веб-проксі, але все ще не знаєте, який із багатьох пакетів VyOS надсилає цей файл. Ви можете визначити відповідне ім’я пакета VyOS за допомогою команди Debian dpkg -S вашої запущеної інсталяції VyOS.

vyos@vyos:~ dpkg -S /opt/vyatta/sbin/vyatta-update-webproxy.pl
vyatta-webproxy: /opt/vyatta/sbin/vyatta-update-webproxy.pl

Це означає, що відповідний файл (/opt/vyatta/sbin/vyatta-update-webproxy.pl) знаходиться в пакеті vyatta-webproxy, який можна знайти тут: https://github. com/vyos/vyatta-webproxy

Форк репозиторію та надішліть патч

Розгалуження репозиторію та надсилання запиту на отримання GitHub є кращим способом надсилання ваших змін до VyOS. Ви можете розділити будь-яке сховище VyOS на свій власний обліковий запис GitHub, просто додавши /fork до URL-адреси будь-якого сховища на GitHub. Щоб, наприклад, розгалужити репозиторій vyos-1x, відкрийте наступну URL-адресу у вашому улюбленому браузері: https://github.com/vyos/vyos-1x/fork

Потім ви можете продовжити клонування свого форка або додати новий пульт до свого локального сховища:

• Клон: git clone https://github.com/<user> /vyos-1x.git

• Fork: git remote add myfork https://github.com/<user> /vyos-1x.git

Щоб записати вас як автора виправлення, ідентифікуйте себе в Git, вказавши своє ім’я та електронну адресу. Це можна зробити локально для цього єдиного сховища git config або глобально за допомогою git config --global.

git config --global user.name "J. Random Hacker"
git config --global user.email "[email protected]"

Внесіть зміни та збережіть їх. Зробіть наступне для всіх файлів змін, щоб записати їх у створений комміт Git:

• Додайте файл до індексу Git за допомогою git add myfile або для цілого каталогу: git add somedir/*

• Зафіксуйте зміни, викликавши git commit. Будь ласка, використовуйте змістовний заголовок коміту (прочитайте вище) і не забудьте вказати посилання на Phabricator ID.

• Надішліть патч git push і створіть GitHub pull-request.

Додайте патч до завдання Phabricator

Дотримуйтеся наведених вище кроків, щоб «форкувати репозиторій, щоб надіслати виправлення». Замість того, щоб завантажувати свої зміни на GitHub, ви можете експортувати виправлення/коміти та надіслати їх на supporters@vyos.net або прикріпити безпосередньо до помилки (бажано, ніж електронною поштою)

• Експортуйте останній комміт у файл виправлення: git format-patch або експортуйте останні два коміти у відповідні файли виправлення: git format-patch -2

Інструкції з кодування

Як і в будь-якому іншому проекті, у нас також є деякі невеликі вказівки щодо вихідного коду. Наші правила створені не для того, щоб карати вас, а для того, щоб допомогти нам усім. Маючи послідовний стиль кодування, новачкам і давнім учасникам стає дуже легко орієнтуватися в джерелах і всій неявній логіці будь-якого вихідного файлу.

Потрібно використовувати Python 3. Як довго ми можемо підтримувати Python 2? Жодних міркувань щодо сумісності з Python 2 не слід враховувати.

Форматування

• Python: вкладки не можна використовувати. Кожен рівень відступу повинен складатися з 4 пробілів

• XML: вкладки не можна використовувати. Кожен рівень відступу має складатися з 2 пробілів

Примітка

Існують розширення, наприклад, для VIM (xmllint), які допоможуть вам отримати правильні рівні відступів. Додайте наступне до свого файлу .vimrc: au FileType xml setlocal equalprg=xmllint\ --format\ --recover\ -\ 2>/dev/null тепер ви можете викликати linter за допомогою ``gg=G` ` в командному режимі.

Генерація тексту

Процесор шаблону потрібно використовувати для створення конфігураційних файлів. Вбудоване форматування рядків може використовуватися для простих рядково-орієнтованих форматів, де кожен рядок самодостатній, наприклад, правила iptables. Процесор шаблонів має використовуватися для структурованих багаторядкових форматів, таких як ті, що використовуються ISC DHCPd.

Типовим процесором шаблонів для коду VyOS є Jinja2.

Резюме

Змінюючи вихідний код, пам’ятайте про ці правила кампанії з усунення застарілих версій:

• У Perl немає нових функцій

• Немає старих визначень команд

• Немає коду, несумісного з Python3

Python

Перехід на мову програмування Python для нового коду – це не просто зміна мови, а шанс переосмислити та вдосконалити підхід до програмування.

Давайте подивимося правді в очі: VyOS наповнена спагетті-кодом, де логіка читання конфігурації VyOS, генерації конфігурацій демона та перезапуску процесів змішана.

Python (або будь-яка інша мова, якщо на те пішло) не забезпечує автоматичного захисту від поганого дизайну, тому нам також потрібно розробити вказівки щодо дизайну та слідувати їм, щоб зберегти систему розширюваною та зручною для обслуговування.

Але ми тут, щоб допомогти вам, і хочемо допомогти вам, як ви можете стати хорошим учасником VyOS. Наші правила створені не для того, щоб карати вас, а для того, щоб допомогти нам усім. Що це означає? Маючи послідовний стиль кодування, новачкам і давнім учасникам стає дуже легко орієнтуватися в джерелах і всій неявній логіці спагетті-коду.

Please use the following template as good starting point when developing new modules or even rewrite a whole bunch of code in the new style XML/Python interface.

Структура та поведінка сценарію конфігурації

Ваш сценарій конфігурації або сценарій режиму роботи, який також написаний на Python3, повинен мати розрив рядка на 80 символів. Сьогодні це здається трохи дивним, але оскільки деякі люди також працюють віддалено або програмують за допомогою vi(m), це досить хороший стандарт, на який, я сподіваюся, ми можемо покластися.

Крім того, це також допоможе під час перегляду кодової бази GitHub на мобільному пристрої, якщо ви випадково божевільний учений.

#!/usr/bin/env python3
#
# Copyright (C) 2020 VyOS maintainers and contributors
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 or later as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

import sys

from vyos.config import Config
from vyos import ConfigError

def get_config():
    if config:
        conf = config
    else:
        conf = Config()

    # Base path to CLI nodes
    base = ['...', '...']
    # Convert the VyOS config to an abstract internal representation
    config_data = conf.get_config_dict(base, key_mangling=('-', '_'), get_first_key=True)
    return config_data

def verify(config):
    # Verify that configuration is valid
    if invalid:
        raise ConfigError("Descriptive message")
    return True

def generate(config):
    # Generate daemon configs
    pass

def apply(config):
    # Apply the generated configs to the live system
    pass

try:
    c = get_config()
    verify(c)
    generate(c)
    apply(c)
except ConfigError as e:
    print(e)
    sys.exit(1)

Функція get_config() має перетворити конфігурацію VyOS на абстрактне внутрішнє представлення. Жодній іншій функції не дозволяється викликати ``vyos.config. Безпосередньо налаштувати метод об’єкта. Обґрунтування цього полягає в тому, що коли читання конфігурації змішується з іншою логікою, дуже важко змінити синтаксис конфігурації, оскільки вам потрібно відсіяти кожне входження старого синтаксису. Якщо специфічний для синтаксису код обмежено однією функцією, решту коду можна залишити недоторканим, якщо внутрішнє представлення залишається сумісним.

Ще однією перевагою є можливість тестування коду. Знущатися над усією підсистемою конфігурації важко, тоді як побудувати внутрішнє представлення вручну набагато простіше.

Функція verify() бере ваше внутрішнє представлення конфігурації та перевіряє, чи вона дійсна, інакше вона повинна викликати ConfigError з повідомленням про помилку, яке описує проблему та, можливо, пропонує, як її виправити. Він не повинен вносити жодних змін у систему. Обґрунтуванням для цього знову є можливість перевірки, а в майбутньому, коли сервер конфігурації буде готовий і кожен сценарій буде переписано таким чином, можливість виконати сухий прогін фіксації («тест фіксації», як у JunOS) і скасувати фіксацію перед внесенням будь-яких змін до системи, якщо в будь-якому компоненті виявлено помилку.

Функція generate() створює файли конфігурації для системних компонентів.

Функція apply() застосовує згенеровану конфігурацію до живої системи. Він повинен використовувати безперервне перезавантаження, коли це можливо. Він може виконувати зривні операції, такі як перезапуск процесу демона, якщо певний компонент не підтримує безперебійне перезавантаження або коли очікуване погіршення сервісу є мінімальним (наприклад, у випадку допоміжних служб, таких як LLDPd). У разі значних служб, таких як VPN-демон і протоколи маршрутизації, коли підтримується перезавантаження без збоїв для деяких, але не для всіх типів змін конфігурації, авторам сценаріїв слід докласти зусиль, щоб визначити, чи можна змінити конфігурацію без зривів. і вдаватися до аварійного перезапуску, лише якщо його неможливо уникнути.

Без крайньої необхідності сценарії конфігурації не повинні безпосередньо змінювати активну конфігурацію компонентів системи. Якщо це можливо, сценарії повинні генерувати файл або файли конфігурації, які можна застосувати за допомогою однієї команди, наприклад перезавантажити службу через systemd init. Особливо не рекомендується вставляти оператори один за одним, наприклад, під час налаштування правил netfilter, збереження їх у файлі та завантаження його за допомогою iptables-restore завжди слід віддавати перевагу, ніж виконання безпосередньо iptables.

Функції apply() і generate() можуть викликати ConfigError, якщо, наприклад, демон не запустився з оновленою конфігурацією. Це не повинно замінити правильну перевірку конфігурації у функції verify(). Необхідно докласти всіх розумних зусиль, щоб переконатися, що згенерована конфігурація дійсна і буде прийнята демоном, включаючи, за необхідності, перехресні перевірки з іншими піддеревами конфігурації VyOS.

Винятки, включно з VyOSError (який викликає vyos.config.Config під час неправильних операцій конфігурації, таких як спроба використання list_nodes() на вузлі без тегів), не слід вимикати. або перехоплено та повторно піднято як помилку конфігурації. Звісно, це не виглядатиме гарно на екрані користувача, але це покращить звіти про помилки та допоможе користувачам (а більшість користувачів VyOS є ІТ-фахівцями) також виконувати власне налагодження.

Для легкої орієнтації ми пропонуємо вам поглянути на реалізацію ntp.py або interfaces-bonding.py (для вузлів тегів). Обидва файли можна знайти в репозиторії vyos-1x.

XML (використовується для визначень CLI)

Завершення bash (або краще vbash) у VyOS визначено в шаблонах. Шаблони — це текстові файли (так звані node.def), що зберігаються в дереві каталогів. Імена каталогів визначають імена команд, а файли шаблонів визначають поведінку команд. До VyOS 1.2 (crux) ці файли створювалися вручну. Після складного процесу редизайну новий шаблон стилю автоматично генерується з вхідного файлу XML.

Визначення інтерфейсу XML для VyOS постачаються зі схемою RelaxNG і знаходяться в модулі vyos-1x. Ця схема є дещо зміненою схемою VyConf псевдонім VyOS 2.0, тому визначення інтерфейсу VyOS 1.2.x можна буде повторно використовувати у версіях VyOS Nextgen з дуже мінімальними змінами.

Чудова особливість схем полягає не тільки в тому, що люди можуть точно знати повну граматику, але й у тому, що її можна автоматично перевірити. Сценарій scripts/build-command-templates, який перетворює визначення XML на шаблони старого стилю, також перевіряє їх на відповідність схемі, тому неправильне визначення призведе до помилки збирання пакета. Я згоден, що формат є багатослівним, але зараз немає іншого формату, який би це дозволяв. Крім того, спеціалізований редактор XML може полегшити проблему багатослівності.

приклад:

<?xml version="1.0"?>
<!-- Cron configuration -->
<interfaceDefinition>
  <node name="system">
    <children>
      <node name="task-scheduler">
        <properties>
          <help>Task scheduler settings</help>
        </properties>
        <children>
          <tagNode name="task" owner="${vyos_conf_scripts_dir}/task_scheduler.py">
            <properties>
              <help>Scheduled task</help>
              <valueHelp>
                <format>&lt;string&gt;</format>
                <description>Task name</description>
              </valueHelp>
              <priority>999</priority>
            </properties>
            <children>
              <leafNode name="crontab-spec">
                <properties>
                  <help>UNIX crontab time specification string</help>
                </properties>
              </leafNode>
              <leafNode name="interval">
                <properties>
                  <help>Execution interval</help>
                  <valueHelp>
                    <format>&lt;minutes&gt;</format>
                    <description>Execution interval in minutes</description>
                  </valueHelp>
                  <valueHelp>
                    <format>&lt;minutes&gt;m</format>
                    <description>Execution interval in minutes</description>
                  </valueHelp>
                  <valueHelp>
                    <format>&lt;hours&gt;h</format>
                    <description>Execution interval in hours</description>
                  </valueHelp>
                  <valueHelp>
                    <format>&lt;days&gt;d</format>
                    <description>Execution interval in days</description>
                  </valueHelp>
                  <constraint>
                    <regex>[1-9]([0-9]*)([mhd]{0,1})</regex>
                  </constraint>
                </properties>
              </leafNode>
              <node name="executable">
                <properties>
                  <help>Executable path and arguments</help>
                </properties>
                <children>
                  <leafNode name="path">
                    <properties>
                      <help>Path to executable</help>
                    </properties>
                  </leafNode>
                  <leafNode name="arguments">
                    <properties>
                      <help>Arguments passed to the executable</help>
                    </properties>
                  </leafNode>
                </children>
              </node>
            </children>
          </tagNode>
        </children>
      </node>
    </children>
  </node>
</interfaceDefinition>

Визначення команд є суто декларативними і не можуть містити жодної логіки. Натомість уся логіка для створення файлів конфігурації для цільових програм, перезапуску служб тощо реалізована в сценаріях конфігурації.

Препроцесор GNU

Файли визначення інтерфейсу XML використовують розширення файлу xml.in, яке було реалізовано в T1843. Визначення інтерфейсу XML, як правило, містять багато дубльованого коду в таких областях, як:

• VIF (включаючи VIF-S/VIF-C)

• Адреса

• Опис

• Увімкнено/вимкнено

Замість надання всіх цих XML-вузлів багаторазово, тепер є файли включення з попередньо визначеними функціями. Короткий огляд:

• IPv4, IPv6 і DHCP(v6) призначення адреси

• IPv4, IPv6 призначення адреси

• Визначення VLAN (VIF)

• MAC-адреса призначення

Усі вхідні XML-файли визначення інтерфейсу (суфікс .in) буде надіслано до попередньої обробки GCC, а вихідні дані збережуться в папці build/interface-definitions. Згаданий раніше сценарій scripts/build-command-templates працює з папкою build/interface-definitions, щоб створити всі необхідні вузли CLI.

$ make interface_definitions
install -d -m 0755 build/interface-definitions
install -d -m 0755 build/op-mode-definitions
Generating build/interface-definitions/intel_qat.xml from interface-definitions/intel_qat.xml.in
Generating build/interface-definitions/interfaces-bonding.xml from interface-definitions/interfaces-bonding.xml.in
Generating build/interface-definitions/cron.xml from interface-definitions/cron.xml.in
Generating build/interface-definitions/pppoe-server.xml from interface-definitions/pppoe-server.xml.in
Generating build/interface-definitions/mdns-repeater.xml from interface-definitions/mdns-repeater.xml.in
Generating build/interface-definitions/tftp-server.xml from interface-definitions/tftp-server.xml.in
[...]

Настанови

Використання чисел

Слід уникати використання чисел у назвах команд, окрім випадків, коли число є частиною назви протоколу чи подібного. Таким чином, протоколи ospfv3 цілком нормальні, але щось на кшталт server-1 викликає сумніви в кращому випадку.

Рядок довідки

Щоб забезпечити єдиний вигляд і відчуття, а також покращити читабельність, ми повинні послідовно дотримуватися набору вказівок.

Вживання великої літери та пунктуація

Перше слово кожного рядка довідки повинно бути великим. У кінці довідкових рядків не повинно бути крапки.

Обґрунтування: це здається неписаним стандартом у CLI мережевих пристроїв і хорошим естетичним компромісом.

приклади:

• Добре: "Алгоритм Frobnication"

• Погано: "алгоритм фробнікації"

• Погано: «Алгоритм Frobnication».

• Жахливо: "алгоритм фробнікації".

Використання скорочень і акронімів

Абревіатури та абревіатури повинні бути написані з великої літери.

приклади:

• Добре: "Тайм-аут з'єднання TCP"

• Погано: "тайм-аут з'єднання tcp"

• Жахливо: "Тайм-аут підключення TCP"

Акроніми також повинні писати з великої літери, щоб візуально відрізняти їх від звичайних слів:

приклади:

• Хороший: RADIUS (як у віддаленій автентифікації для телефонних служб користувачів)

• Погано: радіус (якщо це не відстань між центром кола та будь-якою з його точок)

Деякі абревіатури традиційно пишуться у змішаному регістрі. Як правило, якщо він містить слова «над» або «версія», літера повинна бути малою. Якщо існує прийнятний варіант написання (особливо якщо він визначений RFC або іншим стандартом), його необхідно дотримуватися.

приклади:

• Добре: PPPoE, IPsec

• Погано: PPPOE, IPSEC

• Погано: PPPOE, IPSEC

Вживання дієслів

Дієслів слід уникати. Якщо дієслово можна пропустити, пропустіть його.

приклади:

• Добре: "Тайм-аут з'єднання TCP"

• Погано: «Установити тайм-аут з’єднання TCP»

Якщо дієслово важливе, збережіть його. Наприклад, у довідковому тексті set system ipv6 disable-forwarding, «Вимкнути пересилання IPv6 на всіх інтерфейсах» є цілком виправданим формулюванням.

Віддавайте перевагу інфінітивам

Дієслова, коли вони необхідні, повинні бути у формі інфінітива.

приклади:

• Добре: «Вимкнути переадресацію IPv6»

• Погано: «Вимикає переадресацію IPv6»

Перенесення старого CLI

Стара концепція/синтаксис	Новий синтаксис	Примітки
mynode/node.def	<node name=»mynode»> </node>	Використання листових вузлів (вузлів із значеннями).<leafNode> натомість тег
mynode/node.tag , тег:	<tagNode name=»mynode> </node>
довідка: Мій вузол	<properties><help>Мій вузол</help>
val_help:<format> ; якийсь рядок	<properties><valueHelp><format>формат</format><description> якийсь рядок</description>	Не додавайте кутові дужки навколо формату, вони будуть вставлені автоматично
синтаксис:вираз: шаблон	<properties><constraint><regex>…	<constraintErrorMessage>буде відображено в разі невдачі
синтаксис:вираз: $VAR(@) у &quot;foo&quot;, &quot;bar&quot;, &quot;baz&quot;	Жодного	Використовуйте регулярний вираз
синтаксис:вираз: exec …	<properties> <constraint> <validator> <name =»foo» argument=»bar»>	&quot;${vyos_libexecdir}/validators/foo bar $VAR(@)&quot; буде виконано,<constraintErrorMessage> буде відображено в разі невдачі
синтаксис:вираз: (арифметичний вираз)	Жодного	Зовнішній арифметичний валідатор може бути доданий, якщо є попит, складну перевірку краще залишити для сценаріїв під час фіксації
пріоритет: 999	<properties><priority>999</priority>	Залиште коментар, пояснюючи, чому було обрано пріоритет (наприклад, «після налаштування інтерфейсів»)
мульти:	<properties> <multi/>	Застосовується лише до листових вузлів
дозволено: панель echo foo	<properties><completionHelp><list>foo бар</list>
дозволено: cli-shell-api listNodes vpn ipsec esp-group	<properties><completionHelp><path>vpn ipsec esp-група</path> …
дозволено: /path/to/script	<properties><completionHelp><script> /path/to/script </script>…
за замовчуванням:	Жодного	Перемістити значення за замовчуванням у сценарії
commit:expression:	Жодного	Усі перевірки часу фіксації мають бути у функції verify() сценарію
початок:/створити:/видалити:	Жодного	Вся логіка повинна бути в скриптах

Базовий код C++

Синтаксичний аналізатор CLI, який використовується у VyOS, є сумішшю bash, помічника завершення bash і серверної бібліотеки C++ [vyatta-cfg](https://github.com/vyos/vyatta-cfg). У цьому розділі є посилання на загальні команди CLI та відповідну точку входу в код C/C++.

• набір

  • https://github.com/vyos/vyatta-cfg/blob/0f42786a0b3/src/cstore/cstore.cpp#L352

  • https://github.com/vyos/vyatta-cfg/blob/0f42786a0b3/src/cstore/cstore.cpp#L2549

• здійснити

  • https://github.com/vyos/vyatta-cfg/blob/0f42786a0b3/src/commit/commit-algorithm.cpp#L1252

Безперервна інтеграція

VyOS використовує Jenkins як службу постійної інтеграції (CI). Наш сервер VyOS CI є загальнодоступним тут: https://ci.vyos.net. Ви можете отримати короткий огляд усіх необхідних компонентів, що поставляються в VyOS ISO.

Для створення наших модулів ми використовуємо сценарій CI/CD Pipeline. Кожен компонент VyOS має власний Jenkinsfile, який є (більш-менш) копією. У конвеєрі використовується контейнер Docker із розділу Збірка ISO, але замість того, щоб створювати його з вихідних кодів під час кожного запуску, ми завжди отримуємо свіжу копію (за потреби) з Dockerhub.

Кожен модуль збирається на вимогу, якщо знайдено новий коміт у відповідній гілці. Після успішного запуску отриманий пакет(и) Debian буде розгорнуто в нашому репозиторії Debian, який використовується під час збирання. Він знаходиться тут: http://dev.packages.vyos.net/repositories/.