[devel] [I] rpm-build-vm: vm-run

[devel] [I] rpm-build-vm: vm-run

[Vitaly Chikunov]

Hi,

В hasher появилась возможность запускать тесты под QEMU root-ом.

  BuildRequires: rpm-build-vm

пример запуска:
 
  %check
  if [ -w /dev/kvm ]; then
    vm-run make check
  fi

(На архитектурах где нет QEMU (e2k) vm-run превращается в нооп.)

Наличие /dev/kvm не обязательно, но помогает. Скорее всего большие тесты
без KVM запускать не стоит.

Минимальный пример интерактивной работы:

  altair:~$ hsh --ini
  altair:~$ hsh-install rpm-build-vm
  altair:~$ hsh-shell --mountpoints=/proc,/dev/kvm
  builder@x86_64:/.in$ vm-run
  root@x86_64:/.in# id
  uid=0(root) gid=0(root) groups=0(root)
  root@x86_64:/.in# exit
  builder@x86_64:/.in$ 

Работает по аналогии vido/virtme/eudyptula-boot - запуск ядра и
монтирование корня через 9p.

Просьба тестировать, но не закладываться так как это альфа версия.
Feedback & commits welcome.

Спасибо ldv за хэшер с `allowed_devices=/dev/kvm' и glebfm за необходимый
фикс других пакетов для нового хэшера и первоначальную идею.

ps. Из текущих проблем:
- overlayfs (если используется) не поддерживает чтение root-owned файлов на lowerdir=
- tmpfs не поддерживает user xattr
- нет контроля над флайвором ядра.

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 14.10.2019 0:29, Vitaly Chikunov wrote:
> Просьба тестировать, но не закладываться так как это альфа версия.
> Feedback & commits welcome.

первое что бросилось в глаза - необходимость загружать модули ядра 
(например) для ipv6 и 256Mb ОЗУ внутри.

Но вообще выглядит интересно, спасибо.

Я правильно понимаю, что /usr/src там r/o и тесты, которые изменяют 
что-то на файловой системе - работать не будут ?

Re: [devel] [I] rpm-build-vm: vm-run

[Vitaly Chikunov]

On Mon, Oct 14, 2019 at 09:18:29AM +0300, Anton Farygin wrote:
> On 14.10.2019 0:29, Vitaly Chikunov wrote:
> > Просьба тестировать, но не закладываться так как это альфа версия.
> > Feedback & commits welcome.
> 
> первое что бросилось в глаза - необходимость загружать модули ядра
> (например) для ipv6 и 256Mb ОЗУ внутри.

Да может стоит сделать 1G по-умолчанию. И передавать все ядра хоста, а не одно.

> Но вообще выглядит интересно, спасибо.
> 
> Я правильно понимаю, что /usr/src там r/o и тесты, которые изменяют что-то
> на файловой системе - работать не будут ?

Там r/w и тесты работать будут. Кроме того все переменные окружения передаются
в запускаемый процесс, а код возврата в запустивший. (Не работает только xattr,
для его обхода я сделал опцию --overlay= чтоб можно было замонтировать ext4
поверх /usr/src, так как мне только для ima-evm-utils надо, чтоб тесты с user
xattr проходили. Другим, возможно, это не понадобится.)

  altair:~$ hsh-shell --mountpoints=/proc,/dev/kvm
  builder@x86_64:/.in$ cd
  builder@x86_64:~$ pwd
  /usr/src
  builder@x86_64:~$ vm-run
  root@x86_64:~# pwd
  /usr/src
  root@x86_64:~# date > a
  root@x86_64:~# exit 2
  builder@x86_64:~$ echo $?
  2
  builder@x86_64:~$ cat a
  Mon Oct 14 11:04:45 UTC 2019
  builder@x86_64:~$

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 14.10.2019 14:16, Vitaly Chikunov wrote:
> On Mon, Oct 14, 2019 at 09:18:29AM +0300, Anton Farygin wrote:
>> On 14.10.2019 0:29, Vitaly Chikunov wrote:
>>> Просьба тестировать, но не закладываться так как это альфа версия.
>>> Feedback & commits welcome.
>> первое что бросилось в глаза - необходимость загружать модули ядра
>> (например) для ipv6 и 256Mb ОЗУ внутри.
> Да может стоит сделать 1G по-умолчанию. И передавать все ядра хоста, а не одно.
Ну или хотя бы возможность выбора при запуске.
>
>> Но вообще выглядит интересно, спасибо.
>>
>> Я правильно понимаю, что /usr/src там r/o и тесты, которые изменяют что-то
>> на файловой системе - работать не будут ?
> Там r/w и тесты работать будут. Кроме того все переменные окружения передаются
> в запускаемый процесс, а код возврата в запустивший. (Не работает только xattr,
> для его обхода я сделал опцию --overlay= чтоб можно было замонтировать ext4
> поверх /usr/src, так как мне только для ima-evm-utils надо, чтоб тесты с user
> xattr проходили. Другим, возможно, это не понадобится.)
>
>    altair:~$ hsh-shell --mountpoints=/proc,/dev/kvm

Да, точно. Я забыл указать --mountpoints=/proc и получил в vm-run 
/usr/src как r/o

Эту ситуацию было бы неплохо отрабатывать и не запускать kvm с r/o образом.

Тут ещё возник вопрос - а нельзя ли репозиторий пакетов монтировать 
внутрь kvm образа ?
Это было бы полезно в некоторых случаях.

Re: [devel] [I] rpm-build-vm: vm-run

[Vitaly Chikunov]

On Mon, Oct 14, 2019 at 02:25:45PM +0300, Anton Farygin wrote:
> On 14.10.2019 14:16, Vitaly Chikunov wrote:
> > On Mon, Oct 14, 2019 at 09:18:29AM +0300, Anton Farygin wrote:
> > > On 14.10.2019 0:29, Vitaly Chikunov wrote:
> > > > Просьба тестировать, но не закладываться так как это альфа версия.
> > > > Feedback & commits welcome.
> > > первое что бросилось в глаза - необходимость загружать модули ядра
> > > (например) для ipv6 и 256Mb ОЗУ внутри.
> > Да может стоит сделать 1G по-умолчанию. И передавать все ядра хоста, а не одно.
> Ну или хотя бы возможность выбора при запуске.

Возможность передавать любые опции в QEMU есть: --qemu="". Ядру
--append="".

> > > Но вообще выглядит интересно, спасибо.
> > > 
> > > Я правильно понимаю, что /usr/src там r/o и тесты, которые изменяют что-то
> > > на файловой системе - работать не будут ?
> > Там r/w и тесты работать будут. Кроме того все переменные окружения передаются
> > в запускаемый процесс, а код возврата в запустивший. (Не работает только xattr,
> > для его обхода я сделал опцию --overlay= чтоб можно было замонтировать ext4
> > поверх /usr/src, так как мне только для ima-evm-utils надо, чтоб тесты с user
> > xattr проходили. Другим, возможно, это не понадобится.)
> > 
> >    altair:~$ hsh-shell --mountpoints=/proc,/dev/kvm
> 
> Да, точно. Я забыл указать --mountpoints=/proc и получил в vm-run /usr/src
> как r/o
> 
> Эту ситуацию было бы неплохо отрабатывать и не запускать kvm с r/o образом.

Выводит два больших варнинга, что что-то может не работать.

> Тут ещё возник вопрос - а нельзя ли репозиторий пакетов монтировать внутрь
> kvm образа ?
> Это было бы полезно в некоторых случаях.

По какому-то особому протоколу? Доступны все диры, что есть внутри
хэшера.

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 14.10.2019 15:22, Vitaly Chikunov wrote:
> On Mon, Oct 14, 2019 at 02:25:45PM +0300, Anton Farygin wrote:
>> On 14.10.2019 14:16, Vitaly Chikunov wrote:
>>> On Mon, Oct 14, 2019 at 09:18:29AM +0300, Anton Farygin wrote:
>>>> On 14.10.2019 0:29, Vitaly Chikunov wrote:
>>>>> Просьба тестировать, но не закладываться так как это альфа версия.
>>>>> Feedback & commits welcome.
>>>> первое что бросилось в глаза - необходимость загружать модули ядра
>>>> (например) для ipv6 и 256Mb ОЗУ внутри.
>>> Да может стоит сделать 1G по-умолчанию. И передавать все ядра хоста, а не одно.
>> Ну или хотя бы возможность выбора при запуске.
> Возможность передавать любые опции в QEMU есть: --qemu="". Ядру
> --append="".

Понял, спасибо.

Так же и объёмом ОЗУ можно управлять ?

>
>>>> Но вообще выглядит интересно, спасибо.
>>>>
>>>> Я правильно понимаю, что /usr/src там r/o и тесты, которые изменяют что-то
>>>> на файловой системе - работать не будут ?
>>> Там r/w и тесты работать будут. Кроме того все переменные окружения передаются
>>> в запускаемый процесс, а код возврата в запустивший. (Не работает только xattr,
>>> для его обхода я сделал опцию --overlay= чтоб можно было замонтировать ext4
>>> поверх /usr/src, так как мне только для ima-evm-utils надо, чтоб тесты с user
>>> xattr проходили. Другим, возможно, это не понадобится.)
>>>
>>>     altair:~$ hsh-shell --mountpoints=/proc,/dev/kvm
>> Да, точно. Я забыл указать --mountpoints=/proc и получил в vm-run /usr/src
>> как r/o
>>
>> Эту ситуацию было бы неплохо отрабатывать и не запускать kvm с r/o образом.
> Выводит два больших варнинга, что что-то может не работать.
Ну да, я только по ни и подумал что я как-то не так запускаюсь....
>
>> Тут ещё возник вопрос - а нельзя ли репозиторий пакетов монтировать внутрь
>> kvm образа ?
>> Это было бы полезно в некоторых случаях.
> По какому-то особому протоколу? Доступны все диры, что есть внутри
> хэшера.
>
Да, это вопрос скорее к ldv@ - можно ли каким-то образом сделать 
доступным внутри hasher репозиторий пакетов, из которого этот hasher 
root был создан ?

Re: [devel] [I] rpm-build-vm: vm-run

[Alexey V. Vissarionov]

On 2019-10-14 15:33:08 +0300, Anton Farygin wrote:

 >>>> Да может стоит сделать 1G по-умолчанию. И передавать все ядра
 >>>> хоста, а не одно.
 >>> Ну или хотя бы возможность выбора при запуске.
 >> Возможность передавать любые опции в QEMU есть: --qemu="". Ядру
 >> --append="".
 > Понял, спасибо. Так же и объёмом ОЗУ можно управлять ?

--qemu="-m 100500"


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] [I] rpm-build-vm: vm-run

[Vitaly Chikunov]

On Mon, Oct 14, 2019 at 03:33:08PM +0300, Anton Farygin wrote:
> > > > > первое что бросилось в глаза - необходимость загружать модули ядра
> > > > > (например) для ipv6 и 256Mb ОЗУ внутри.
> > > > Да может стоит сделать 1G по-умолчанию. И передавать все ядра хоста, а не одно.
> > > Ну или хотя бы возможность выбора при запуске.
> > Возможность передавать любые опции в QEMU есть: --qemu="". Ядру
> > --append="".
> 
> Понял, спасибо.
> 
> Так же и объёмом ОЗУ можно управлять ?

Да, эти опции перекроют -m 256M.

Default размер памяти может стоит тоже сделать на всю доступную, как будет
сделано с ядрами.

Re: [devel] [I] rpm-build-vm: vm-run

[Alexey V. Vissarionov]

On 2019-10-14 15:39:31 +0300, Vitaly Chikunov wrote:

 >>>>> Да может стоит сделать 1G по-умолчанию. И передавать все ядра
 >>>>> хоста, а не одно.
 >>>> Ну или хотя бы возможность выбора при запуске.
 >>> Возможность передавать любые опции в QEMU есть: --qemu="". Ядру
 >>> --append="".
 >> Понял, спасибо. Так же и объёмом ОЗУ можно управлять ?
 > Да, эти опции перекроют -m 256M.
 > Default размер памяти может стоит тоже сделать на всю доступную,
 > как будет сделано с ядрами.

Зачем на всю? 2...4 Гб в 99.9% случаев хватит по уши, для остальных
можно указать явно.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] [I] rpm-build-vm: vm-run

[Dmitry V. Levin]

On Mon, Oct 14, 2019 at 03:33:08PM +0300, Anton Farygin wrote:
[...]
> Да, это вопрос скорее к ldv@ - можно ли каким-то образом сделать 
> доступным внутри hasher репозиторий пакетов, из которого этот hasher 
> root был создан ?

В теории можно, на практике непонятно, как это специфицировать, поскольку
hasher (т.е. на самом деле apt-get) в сборочнице устанавливает пакеты из
двух источников, а в общем случае их может быть сколько угодно (и не
только files).


-- 
ldv

Re: [devel] [I] rpm-build-vm: vm-run

[Vladimir D. Seleznev]

On Mon, Oct 14, 2019 at 11:54:29PM +0300, Dmitry V. Levin wrote:
> On Mon, Oct 14, 2019 at 03:33:08PM +0300, Anton Farygin wrote:
> [...]
> > Да, это вопрос скорее к ldv@ - можно ли каким-то образом сделать 
> > доступным внутри hasher репозиторий пакетов, из которого этот hasher 
> > root был создан ?
> 
> В теории можно, на практике непонятно, как это специфицировать, поскольку
> hasher (т.е. на самом деле apt-get) в сборочнице устанавливает пакеты из
> двух источников, а в общем случае их может быть сколько угодно (и не
> только files).

Мне не нравится идея доступности произвольных репозиториев в сборочной
среде, т.к. они могу повлиять на результат сборки, а это то, чего на
самом деле надо стремиться избегать.  Я отмечу, что даже доступность
только альтовых репозиториев и только определённого бранча на этапе
сборке можно рассматривать как доступность произвольного репозитория,
для каждой итерации сборки этот репозиторий, вообще говоря,
отличный. Это несовместимо с концепцией воспроизводимости сборки.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 15.10.2019 0:53, Vladimir D. Seleznev wrote:
> On Mon, Oct 14, 2019 at 11:54:29PM +0300, Dmitry V. Levin wrote:
>> On Mon, Oct 14, 2019 at 03:33:08PM +0300, Anton Farygin wrote:
>> [...]
>>> Да, это вопрос скорее к ldv@ - можно ли каким-то образом сделать
>>> доступным внутри hasher репозиторий пакетов, из которого этот hasher
>>> root был создан ?
>> В теории можно, на практике непонятно, как это специфицировать, поскольку
>> hasher (т.е. на самом деле apt-get) в сборочнице устанавливает пакеты из
>> двух источников, а в общем случае их может быть сколько угодно (и не
>> только files).
> Мне не нравится идея доступности произвольных репозиториев в сборочной
> среде, т.к. они могу повлиять на результат сборки, а это то, чего на
> самом деле надо стремиться избегать.  Я отмечу, что даже доступность
> только альтовых репозиториев и только определённого бранча на этапе
> сборке можно рассматривать как доступность произвольного репозитория,
> для каждой итерации сборки этот репозиторий, вообще говоря,
> отличный. Это несовместимо с концепцией воспроизводимости сборки.
Нам нужен репозиторий в чруте исключительно для тестов.

Не совсем понятно как это может повлиять на результат сборки.

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 14.10.2019 23:54, Dmitry V. Levin wrote:
> On Mon, Oct 14, 2019 at 03:33:08PM +0300, Anton Farygin wrote:
> [...]
>> Да, это вопрос скорее к ldv@ - можно ли каким-то образом сделать
>> доступным внутри hasher репозиторий пакетов, из которого этот hasher
>> root был создан ?
> В теории можно, на практике непонятно, как это специфицировать, поскольку
> hasher (т.е. на самом деле apt-get) в сборочнице устанавливает пакеты из
> двух источников, а в общем случае их может быть сколько угодно (и не
> только files).
Если уж говорить про использование hasher для CI, то помимо репозитория 
может понадобится некий набор заранее подготовленных qemu образов.

Для начала достаточно передавать репозитории, из которого собирались 
hasher chroot'ы.
Для протоколов, отличных от hasher -  поднимать сеть в kvm до хоста, на 
котором есть эти самые репозитории.

Re: [devel] [I] rpm-build-vm: vm-run

[Alexey V. Vissarionov]

On 2019-10-15 07:04:12 +0300, Anton Farygin wrote:

 > Если уж говорить про использование hasher для CI, то помимо
 > репозитория может понадобится некий набор заранее подготовленных
 > qemu образов.

Вот так уж точно делать не надо: образы лучше генерировать на ходу
прямо перед запуском qemu - все необходимое для этого уже есть.

 > Для начала достаточно передавать репозитории, из которого
 > собирались hasher chroot'ы. Для протоколов, отличных от
 > hasher - поднимать сеть в kvm до хоста, на котором есть эти
 > самые репозитории.

И в чем сложности? nginx на ::1, rsync в crontab, --qemu="-net ..."


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 15.10.2019 7:16, Alexey V. Vissarionov wrote:
> On 2019-10-15 07:04:12 +0300, Anton Farygin wrote:
>
>   > Если уж говорить про использование hasher для CI, то помимо
>   > репозитория может понадобится некий набор заранее подготовленных
>   > qemu образов.
>
> Вот так уж точно делать не надо: образы лучше генерировать на ходу
> прямо перед запуском qemu - все необходимое для этого уже есть.
Новые образы мне не интересны, мне интересны старые, сгенерённые на 
годичной давности репозитории.
>
>   > Для начала достаточно передавать репозитории, из которого
>   > собирались hasher chroot'ы. Для протоколов, отличных от
>   > hasher - поднимать сеть в kvm до хоста, на котором есть эти
>   > самые репозитории.
>
> И в чем сложности? nginx на ::1, rsync в crontab, --qemu="-net ..."
crontab в hasher ?

Re: [devel] [I] rpm-build-vm: vm-run

[Alexey V. Vissarionov]

On 2019-10-15 08:22:07 +0300, Anton Farygin wrote:

 >>> Если уж говорить про использование hasher для CI, то помимо
 >>> репозитория может понадобится некий набор заранее
 >>> подготовленных qemu образов.
 >> Вот так уж точно делать не надо: образы лучше генерировать
 >> на ходу прямо перед запуском qemu - все необходимое для
 >> этого уже есть.
 > Новые образы мне не интересны, мне интересны старые,
 > сгенерённые на годичной давности репозитории.

Если есть прошлогодняя репа - можно сделать прошлогодний образ.

 >>> Для начала достаточно передавать репозитории, из которого
 >>> собирались hasher chroot'ы. Для протоколов, отличных от
 >>> hasher - поднимать сеть в kvm до хоста, на котором есть эти
 >>> самые репозитории.
 >> И в чем сложности? nginx на ::1, rsync в crontab, --qemu="-net ..."
 > crontab в hasher ?

Нет - на хосте. И nginx тоже (::1 - это про его локальность).


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] [I] rpm-build-vm: vm-run

[Vladimir D. Seleznev]

On Tue, Oct 15, 2019 at 06:56:07AM +0300, Anton Farygin wrote:
> On 15.10.2019 0:53, Vladimir D. Seleznev wrote:
> > On Mon, Oct 14, 2019 at 11:54:29PM +0300, Dmitry V. Levin wrote:
> >> On Mon, Oct 14, 2019 at 03:33:08PM +0300, Anton Farygin wrote:
> >> [...]
> >>> Да, это вопрос скорее к ldv@ - можно ли каким-то образом сделать
> >>> доступным внутри hasher репозиторий пакетов, из которого этот hasher
> >>> root был создан ?
> >> В теории можно, на практике непонятно, как это специфицировать, поскольку
> >> hasher (т.е. на самом деле apt-get) в сборочнице устанавливает пакеты из
> >> двух источников, а в общем случае их может быть сколько угодно (и не
> >> только files).
> > Мне не нравится идея доступности произвольных репозиториев в сборочной
> > среде, т.к. они могу повлиять на результат сборки, а это то, чего на
> > самом деле надо стремиться избегать.  Я отмечу, что даже доступность
> > только альтовых репозиториев и только определённого бранча на этапе
> > сборке можно рассматривать как доступность произвольного репозитория,
> > для каждой итерации сборки этот репозиторий, вообще говоря,
> > отличный. Это несовместимо с концепцией воспроизводимости сборки.
> Нам нужен репозиторий в чруте исключительно для тестов.

Всё-таки правильнее для тестирования результата сборки пакетов всё же
использовать те пакеты, которые имеются в сборочной среде в процессе
сборки. Тестировать что-то, для чего нужен целый репозиторий, лучше не в
процессе сборки пакета.

> Не совсем понятно как это может повлиять на результат сборки.

Это источник недетерминированного ввода.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 15.10.2019 9:19, Vladimir D. Seleznev wrote:
> Это источник недетерминированного ввода.

Почему же недетерминированного ? Политика тестирования будет прописана в 
исходниках пакета и как раз в тестах будет проверяться пакет на текущем 
состоянии репозитория.

К тому же кто сказал что для тестирования нужно предсказуемое состояние 
пакетной базы ? Как раз одна из методик тестирования предполагает 
непредсказуемость входных данных, в том числе использование мутаций для 
входных данных.

Re: [devel] [I] rpm-build-vm: vm-run

[Alexey V. Vissarionov]

On 2019-10-15 10:05:31 +0300, Anton Farygin wrote:

 >> Это источник недетерминированного ввода.
 > Почему же недетерминированного ? Политика тестирования
 > будет прописана в исходниках пакета и как раз в тестах будет
 > проверяться пакет на текущем состоянии репозитория.
 > К тому же кто сказал что для тестирования нужно предсказуемое
 > состояние пакетной базы ? Как раз одна из методик тестирования
 > предполагает непредсказуемость входных данных, в том числе
 > использование мутаций для входных данных.

Такое тестирование проводится уже после сборки.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] [I] rpm-build-vm: vm-run

[Michael Shigorin]

On Tue, Oct 15, 2019 at 10:05:31AM +0300, Anton Farygin wrote:
> On 15.10.2019 9:19, Vladimir D. Seleznev wrote:
> > Это источник недетерминированного ввода.

+1

> Почему же недетерминированного ?

Потому что от такого запуска qemu ты ожидаешь получить какую-то
информацию, которую не можешь вычислить из имеющегося hasher
chroot -- если это не так, то и запускать незачем.

Вариант с фиксацией именно того состояния репозитория, которое
применялось для создания чрута, конкретно это возражение снимает
-- но мне _кажется_, что снимок репозитория больше похож на
свойство объекта "задание" в рамках сборочницы, чем на свойство
hasher chroot (который сам уже производная) в рамках hasher.

> К тому же кто сказал что для тестирования нужно предсказуемое
> состояние пакетной базы ? Как раз одна из методик тестирования
> предполагает непредсказуемость входных данных, в том числе
> использование мутаций для входных данных.

Зачем это тащить в hasher, особенно если на сборочнице?
Собрал тестовое задание, гоняешь по нему спокойно тесты.

Есть плохой "паттерн", когда всех заставляют платить
(временем запуска, сложностью освоения, ...) за что-то,
что нужно очень мало кому.  Например, когда-то на ASPLinux
запускался ненастроенный sendmail, который тупил об типично
недоступный на домашнем ПК по тем временам DNS три минуты
(и всё равно требовал настройки для собственно работы
там, где предполагался к применению).

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 15.10.2019 10:32, Michael Shigorin wrote:
> Зачем это тащить в hasher, особенно если на сборочнице?
> Собрал тестовое задание, гоняешь по нему спокойно тесты.

Есть цель сделать автоматическое тестирование воспроизводимым образом и 
сразу в процессе сборки пакета.

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 15.10.2019 10:17, Alexey V. Vissarionov wrote:
> On 2019-10-15 10:05:31 +0300, Anton Farygin wrote:
>
>   >> Это источник недетерминированного ввода.
>   > Почему же недетерминированного ? Политика тестирования
>   > будет прописана в исходниках пакета и как раз в тестах будет
>   > проверяться пакет на текущем состоянии репозитория.
>   > К тому же кто сказал что для тестирования нужно предсказуемое
>   > состояние пакетной базы ? Как раз одна из методик тестирования
>   > предполагает непредсказуемость входных данных, в том числе
>   > использование мутаций для входных данных.
>
> Такое тестирование проводится уже после сборки.
Да, у нас и секция %check выполняется после секции %build. Всё верно.

Re: [devel] [I] rpm-build-vm: vm-run

[Dmitry V. Levin]

On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
> On 15.10.2019 10:32, Michael Shigorin wrote:
> > Зачем это тащить в hasher, особенно если на сборочнице?
> > Собрал тестовое задание, гоняешь по нему спокойно тесты.
> 
> Есть цель сделать автоматическое тестирование воспроизводимым образом и 
> сразу в процессе сборки пакета.

Вопрос, что мешает поместить всё необходимое в сборочную среду?


-- 
ldv

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 15.10.2019 21:22, Dmitry V. Levin wrote:
> On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
>> On 15.10.2019 10:32, Michael Shigorin wrote:
>>> Зачем это тащить в hasher, особенно если на сборочнице?
>>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
>> Есть цель сделать автоматическое тестирование воспроизводимым образом и
>> сразу в процессе сборки пакета.
> Вопрос, что мешает поместить всё необходимое в сборочную среду?
>
Я не совсем понимаю механизм, с помощью которого я могу поместить всё 
необходимое в сборочную среду.

Re: [devel] [I] rpm-build-vm: vm-run

[Dmitry V. Levin]

On Tue, Oct 15, 2019 at 09:28:09PM +0300, Anton Farygin wrote:
> On 15.10.2019 21:22, Dmitry V. Levin wrote:
> > On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
> >> On 15.10.2019 10:32, Michael Shigorin wrote:
> >>> Зачем это тащить в hasher, особенно если на сборочнице?
> >>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
> >> Есть цель сделать автоматическое тестирование воспроизводимым образом и
> >> сразу в процессе сборки пакета.
> > Вопрос, что мешает поместить всё необходимое в сборочную среду?
> >
> Я не совсем понимаю механизм, с помощью которого я могу поместить всё 
> необходимое в сборочную среду.

А что из себя представляет всё необходимое?


-- 
ldv

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 15.10.2019 21:33, Dmitry V. Levin wrote:
> On Tue, Oct 15, 2019 at 09:28:09PM +0300, Anton Farygin wrote:
>> On 15.10.2019 21:22, Dmitry V. Levin wrote:
>>> On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
>>>> On 15.10.2019 10:32, Michael Shigorin wrote:
>>>>> Зачем это тащить в hasher, особенно если на сборочнице?
>>>>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
>>>> Есть цель сделать автоматическое тестирование воспроизводимым образом и
>>>> сразу в процессе сборки пакета.
>>> Вопрос, что мешает поместить всё необходимое в сборочную среду?
>>>
>> Я не совсем понимаю механизм, с помощью которого я могу поместить всё
>> необходимое в сборочную среду.
> А что из себя представляет всё необходимое?
Для того теста, который я хотел бы попробовать сделать - это репозиторий 
apt, из которого собирался данный hasher root (или доступ к этому 
репозиторию через apt).

Грубо говоря - если мы хотим проверить инструментарий работы с 
репозиторием (apt, packagekit) во время сборки полноценно, то небольшого 
синтетического набора пакетов скорее всего будет недостаточно и его надо 
проверять на всей  доступной пакетной базе.

Re: [devel] [I] rpm-build-vm: vm-run

[Vladimir D. Seleznev]

On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
> On 15.10.2019 10:32, Michael Shigorin wrote:
> > Зачем это тащить в hasher, особенно если на сборочнице?
> > Собрал тестовое задание, гоняешь по нему спокойно тесты.
> 
> Есть цель сделать автоматическое тестирование воспроизводимым образом и 
> сразу в процессе сборки пакета.

Если воспроизводимым образом, то прокидывать репозитории в сборочную
среду не нужно: все требуемые пакеты нужно указать в BuildRequires.

Тестирование пакетов — это безусловно важно, однако нет задачи проводить
всеобъемлющее тестирование всевозможного поведения каждого пакета. От
репозитория пакетов программного обеспечения в первую очередь ожидают
других качеств: корректную доставку программного обеспечения,
т.е. корректную установку пакетов, удаление и бесшовного обновления,
консистентность самого репозитория. Консистентность репозитория по
большей части у нас проверяется сборочной системой, корректность
установки также тестируется в процессе сборки. Тестировать корректность
обновления сложнее, и тут уже больше требуется внимательность и
ответственность мейнтейнеров пакетов.

Отдельно замечу про стабильные ветки репозитория. Стабильность означает
неизменность общего поведения приложений. Т.е., не должно быть ситуации,
когда в результате обновления пакета в стабильной ветке его поведение
меняется, например, на противоположное. И стабильность невозможно в
общем случае гарантировать обширным тестированием пакетов: довольно
трудно формализовать неизменность поведения, в отличие от некорректного
поведения программы. В некоторых проектах в стабильных ветках
замораживают версии пакетов и бэкпортируют только security fixes. Это
довольно строгое требование, особенно для прикладных программ, но
оправданное для базовой системы. А когда, допустим, в стабильной ветке
находится некая MyNiceDB, которая к некоторому моменту уже устарела, и
хочется новую функциональность из новой версии (скажем, третьей), то
лучше не обновлять эту версию, а собрать новый пакет MyNiceDB3
(возможно, с правильным указанием конфликтов). Таким образом никому
поведение не будет сломано, и кому надо, сможет воспользоваться новой
версией с новой функциональностью. То же самое можно сказать и про
разделяемые библиотеки (shared library policy в т.ч. для этого
предлагалось).

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] [I] rpm-build-vm: vm-run

[Vladimir D. Seleznev]

On Tue, Oct 15, 2019 at 09:48:17PM +0300, Anton Farygin wrote:
> On 15.10.2019 21:33, Dmitry V. Levin wrote:
> > On Tue, Oct 15, 2019 at 09:28:09PM +0300, Anton Farygin wrote:
> >> On 15.10.2019 21:22, Dmitry V. Levin wrote:
> >>> On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
> >>>> On 15.10.2019 10:32, Michael Shigorin wrote:
> >>>>> Зачем это тащить в hasher, особенно если на сборочнице?
> >>>>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
> >>>> Есть цель сделать автоматическое тестирование воспроизводимым образом и
> >>>> сразу в процессе сборки пакета.
> >>> Вопрос, что мешает поместить всё необходимое в сборочную среду?
> >>>
> >> Я не совсем понимаю механизм, с помощью которого я могу поместить всё
> >> необходимое в сборочную среду.
> > А что из себя представляет всё необходимое?
> Для того теста, который я хотел бы попробовать сделать - это репозиторий 
> apt, из которого собирался данный hasher root (или доступ к этому 
> репозиторию через apt).
> 
> Грубо говоря - если мы хотим проверить инструментарий работы с 
> репозиторием (apt, packagekit) во время сборки полноценно, то небольшого 
> синтетического набора пакетов скорее всего будет недостаточно и его надо 
> проверять на всей  доступной пакетной базе.

Для этого можно подготовить тестовый репозиторий, и на нём
тестировать. Воспроизводимо, и всегда заранее понятно, как ой результат
ожидается.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] [I] rpm-build-vm: vm-run

[Dmitry V. Levin]

On Tue, Oct 15, 2019 at 09:48:17PM +0300, Anton Farygin wrote:
> On 15.10.2019 21:33, Dmitry V. Levin wrote:
> > On Tue, Oct 15, 2019 at 09:28:09PM +0300, Anton Farygin wrote:
> >> On 15.10.2019 21:22, Dmitry V. Levin wrote:
> >>> On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
> >>>> On 15.10.2019 10:32, Michael Shigorin wrote:
> >>>>> Зачем это тащить в hasher, особенно если на сборочнице?
> >>>>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
> >>>> Есть цель сделать автоматическое тестирование воспроизводимым образом и
> >>>> сразу в процессе сборки пакета.
> >>> Вопрос, что мешает поместить всё необходимое в сборочную среду?
> >>>
> >> Я не совсем понимаю механизм, с помощью которого я могу поместить всё
> >> необходимое в сборочную среду.
> > А что из себя представляет всё необходимое?
> Для того теста, который я хотел бы попробовать сделать - это репозиторий 
> apt, из которого собирался данный hasher root (или доступ к этому 
> репозиторию через apt).
> 
> Грубо говоря - если мы хотим проверить инструментарий работы с 
> репозиторием (apt, packagekit) во время сборки полноценно, то небольшого 
> синтетического набора пакетов скорее всего будет недостаточно и его надо 
> проверять на всей  доступной пакетной базе.

Давайте начнём с тех тестов, которые простые и воспроизводимые, и будем
его пополнять.
Проверять на всей пакетной базе тоже интересно, но это совсем другая задача.

У нас в уезде был аналогичный случай. (c)

У strace с 1991 года до 2011 года не было тестов.
Начало положили 2 теста, написанные в феврале 2011 года.
На данный момент в strace уже 721 тест, большая их часть синтетические,
покрытие составляет 85.8% кода на x86-64.

Конечно, этого набора тестов недостаточно, strace надо проверять на всех
доступных процессах. :)


-- 
ldv

Re: [devel] [I] rpm-build-vm: vm-run

[Vitaly Chikunov]

On Tue, Oct 15, 2019 at 10:24:40PM +0300, Dmitry V. Levin wrote:
> On Tue, Oct 15, 2019 at 09:48:17PM +0300, Anton Farygin wrote:
> > On 15.10.2019 21:33, Dmitry V. Levin wrote:
> > > On Tue, Oct 15, 2019 at 09:28:09PM +0300, Anton Farygin wrote:
> > >> On 15.10.2019 21:22, Dmitry V. Levin wrote:
> > >>> On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
> > >>>> On 15.10.2019 10:32, Michael Shigorin wrote:
> > >>>>> Зачем это тащить в hasher, особенно если на сборочнице?
> > >>>>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
> > >>>> Есть цель сделать автоматическое тестирование воспроизводимым образом и
> > >>>> сразу в процессе сборки пакета.
> > >>> Вопрос, что мешает поместить всё необходимое в сборочную среду?
> > >>>
> > >> Я не совсем понимаю механизм, с помощью которого я могу поместить всё
> > >> необходимое в сборочную среду.
> > > А что из себя представляет всё необходимое?
> > Для того теста, который я хотел бы попробовать сделать - это репозиторий 
> > apt, из которого собирался данный hasher root (или доступ к этому 
> > репозиторию через apt).
> > 
> > Грубо говоря - если мы хотим проверить инструментарий работы с 
> > репозиторием (apt, packagekit) во время сборки полноценно, то небольшого 
> > синтетического набора пакетов скорее всего будет недостаточно и его надо 
> > проверять на всей  доступной пакетной базе.
> 
> Давайте начнём с тех тестов, которые простые и воспроизводимые, и будем
> его пополнять.
> Проверять на всей пакетной базе тоже интересно, но это совсем другая задача.
> 
> У нас в уезде был аналогичный случай. (c)
> 
> У strace с 1991 года до 2011 года не было тестов.
> Начало положили 2 теста, написанные в феврале 2011 года.
> На данный момент в strace уже 721 тест, большая их часть синтетические,
> покрытие составляет 85.8% кода на x86-64.
> 
> Конечно, этого набора тестов недостаточно, strace надо проверять на всех
> доступных процессах. :)

Я делаю ещё один инструмент тестирования, но пока разработка идет тайно.
Первоначальная идея в том, чтоб делать на любую дату (скажем из архива
репозитория за неделю до проверяемой таски) делать загружаемый образ
(altbootstrap), бутиться в него (в qemu), dist-upgrade, ребут ещё раз и
проверка, что всё ок. Если это сработает, то к этому можно будет
добавлять ещё тестов.

Re: [devel] [I] rpm-build-vm: vm-run

[Alexey V. Vissarionov]

On 2019-10-15 22:24:40 +0300, Dmitry V. Levin wrote:

 >> Грубо говоря - если мы хотим проверить инструментарий работы с
 >> репозиторием (apt, packagekit) во время сборки полноценно, то
 >> небольшого синтетического набора пакетов скорее всего будет
 >> недостаточно и его надо проверять на всей доступной пакетной базе.
 > Давайте начнём с тех тестов, которые простые и воспроизводимые,
 > и будем его пополнять. Проверять на всей пакетной базе тоже
 > интересно, но это совсем другая задача.
 > У нас в уезде был аналогичный случай. (c)

s/уезде/местечке/

 > У strace с 1991 года до 2011 года не было тестов. Начало положили
 > 2 теста, написанные в феврале 2011 года. На данный момент в strace
 > уже 721 тест, большая их часть синтетические, покрытие составляет
 > 85.8% кода на x86-64.
 > Конечно, этого набора тестов недостаточно, strace надо проверять
 > на всех доступных процессах. :)

Увы, на недоступных процессах это сделать гораздо сложнее...


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 15.10.2019 22:08, Vladimir D. Seleznev wrote:
> On Tue, Oct 15, 2019 at 09:48:17PM +0300, Anton Farygin wrote:
>> On 15.10.2019 21:33, Dmitry V. Levin wrote:
>>> On Tue, Oct 15, 2019 at 09:28:09PM +0300, Anton Farygin wrote:
>>>> On 15.10.2019 21:22, Dmitry V. Levin wrote:
>>>>> On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
>>>>>> On 15.10.2019 10:32, Michael Shigorin wrote:
>>>>>>> Зачем это тащить в hasher, особенно если на сборочнице?
>>>>>>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
>>>>>> Есть цель сделать автоматическое тестирование воспроизводимым образом и
>>>>>> сразу в процессе сборки пакета.
>>>>> Вопрос, что мешает поместить всё необходимое в сборочную среду?
>>>>>
>>>> Я не совсем понимаю механизм, с помощью которого я могу поместить всё
>>>> необходимое в сборочную сред
>>> А что из себя представляет всё необходимое?
>> Для того теста, который я хотел бы попробовать сделать - это репозиторий
>> apt, из которого собирался данный hasher root (или доступ к этому
>> репозиторию через apt).
>>
>> Грубо говоря - если мы хотим проверить инструментарий работы с
>> репозиторием (apt, packagekit) во время сборки полноценно, то небольшого
>> синтетического набора пакетов скорее всего будет недостаточно и его надо
>> проверять на всей  доступной пакетной базе.
> Для этого можно подготовить тестовый репозиторий, и на нём
> тестировать. Воспроизводимо, и всегда заранее понятно, как ой результат
> ожидается

Да, так и сделали. Я хочу непонятный результат, о чём выше и написал.

Re: [devel] [I] rpm-build-vm: vm-run

[Alexey V. Vissarionov]

On 2019-10-16 07:48:40 +0300, Anton Farygin wrote:

 >>> Грубо говоря - если мы хотим проверить инструментарий работы с
 >>> репозиторием (apt, packagekit) во время сборки полноценно, то
 >>> небольшого синтетического набора пакетов скорее всего будет
 >>> недостаточно и его надо проверять на всей доступной пакетной
 >>> базе.
 >> Для этого можно подготовить тестовый репозиторий, и на нём
 >> тестировать. Воспроизводимо, и всегда заранее понятно, какой
 >> результат ожидается
 > Да, так и сделали. Я хочу непонятный результат, о чём выше и
 > написал.

Для непонятных результатов полагается создавать тестовую среду, а
не колхозить хрен пойми что в сборочной.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 15.10.2019 22:44, Vitaly Chikunov wrote:
> On Tue, Oct 15, 2019 at 10:24:40PM +0300, Dmitry V. Levin wrote:
>> On Tue, Oct 15, 2019 at 09:48:17PM +0300, Anton Farygin wrote:
>>> On 15.10.2019 21:33, Dmitry V. Levin wrote:
>>>> On Tue, Oct 15, 2019 at 09:28:09PM +0300, Anton Farygin wrote:
>>>>> On 15.10.2019 21:22, Dmitry V. Levin wrote:
>>>>>> On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
>>>>>>> On 15.10.2019 10:32, Michael Shigorin wrote:
>>>>>>>> Зачем это тащить в hasher, особенно если на сборочнице?
>>>>>>>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
>>>>>>> Есть цель сделать автоматическое тестирование воспроизводимым образом и
>>>>>>> сразу в процессе сборки пакета.
>>>>>> Вопрос, что мешает поместить всё необходимое в сборочную среду?
>>>>>>
>>>>> Я не совсем понимаю механизм, с помощью которого я могу поместить всё
>>>>> необходимое в сборочную среду.
>>>> А что из себя представляет всё необходимое?
>>> Для того теста, который я хотел бы попробовать сделать - это репозиторий
>>> apt, из которого собирался данный hasher root (или доступ к этому
>>> репозиторию через apt).
>>>
>>> Грубо говоря - если мы хотим проверить инструментарий работы с
>>> репозиторием (apt, packagekit) во время сборки полноценно, то небольшого
>>> синтетического набора пакетов скорее всего будет недостаточно и его надо
>>> проверять на всей  доступной пакетной базе.
>> Давайте начнём с тех тестов, которые простые и воспроизводимые, и будем
>> его пополнять.
>> Проверять на всей пакетной базе тоже интересно, но это совсем другая задача.
>>
>> У нас в уезде был аналогичный случай. (c)
>>
>> У strace с 1991 года до 2011 года не было тестов.
>> Начало положили 2 теста, написанные в феврале 2011 года.
>> На данный момент в strace уже 721 тест, большая их часть синтетические,
>> покрытие составляет 85.8% кода на x86-64.
>>
>> Конечно, этого набора тестов недостаточно, strace надо проверять на всех
>> доступных процессах. :)
> Я делаю ещё один инструмент тестирования, но пока разработка идет тайно.
> Первоначальная идея в том, чтоб делать на любую дату (скажем из архива
> репозитория за неделю до проверяемой таски) делать загружаемый образ
> (altbootstrap), бутиться в него (в qemu), dist-upgrade, ребут ещё раз и
> проверка, что всё ок. Если это сработает, то к этому можно будет
> добавлять ещё тестов.
>
Да, такая задача тоже есть, но чуть сложнее - вместо образа из архива 
нужно автоматически устанавливать дистрибутив(ы), обновлять до даты, 
потом обновлять до таска.
Сейчас это делается отдельными системами, но такая задача вполне 
переносима в сборочницу.

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 16.10.2019 2:41, Leonid Krivoshein wrote:
>
>
> 15.10.2019 21:48, Anton Farygin пишет:
>> On 15.10.2019 21:33, Dmitry V. Levin wrote:
>>> On Tue, Oct 15, 2019 at 09:28:09PM +0300, Anton Farygin wrote:
>>>> On 15.10.2019 21:22, Dmitry V. Levin wrote:
>>>>> On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
>>>>>> On 15.10.2019 10:32, Michael Shigorin wrote:
>>>>>>> Зачем это тащить в hasher, особенно если на сборочнице?
>>>>>>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
>>>>>> Есть цель сделать автоматическое тестирование воспроизводимым 
>>>>>> образом и
>>>>>> сразу в процессе сборки пакета.
>>>>> Вопрос, что мешает поместить всё необходимое в сборочную среду?
>>>>>
>>>> Я не совсем понимаю механизм, с помощью которого я могу поместить всё
>>>> необходимое в сборочную среду.
>>> А что из себя представляет всё необходимое?
>> Для того теста, который я хотел бы попробовать сделать - это 
>> репозиторий apt, из которого собирался данный hasher root (или доступ 
>> к этому репозиторию через apt).
>>
>> Грубо говоря - если мы хотим проверить инструментарий работы с 
>> репозиторием (apt, packagekit) во время сборки полноценно, то 
>> небольшого синтетического набора пакетов скорее всего будет 
>> недостаточно и его надо проверять на всей  доступной пакетной базе.
>>
>
> Мне кажется, что сильно ограниченный чрут, коим является hasher, равно 
> как и vm-run, для решения данной задачи не подходят. С 
> qemu-виртуалками я без проблем пробрасываю /ALT внутрь через 9p. Как я 
> понимаю, запрос не на фичу в vm-run -- она может пробросить через 9p 
> из хэшера что угодно. Вопрос на предоставление /ALT/чего-то/там через 
> механизм хэшера allowed_mountpoints на публичной сборочнице. Обычно в 
> хэшере не нужен APT, поскольку он снаружи вместе со своим aptbox'ом. 
> Но ничто не мешает положить ещё один APT внутрь. Наверное, для себя 
> пропатчить hasher-priv можно, но будет ли такая фича полезна в 
> публичной сборочнице -- вопрос к ldv@ и команде glebfm@.
>
> По-моему, такую автоматизацию проще выполнять на виртуалках, а не в 
> хэшере. При этом должен быть доступ ко всем состояниям репозитория. 
> Для автоматизации сборки/изменения/наполнения виртуалки можно 
> использовать мой autorun и полезную возможность qemu --no-reboot. Не 
> для всех архитектур пока, правда.

Такая автоматизация вне сборочницы уже есть и в целом работает.

Вопрос в том, что бы сделать её работу доступной для всех сборочных 
заданий и разработчиков. С публичными отчётами и логами о тестировании. 
Появление vm-run делает её в принципе возможной.

>
> В этой связи есть призыв (адресую всем, кто ведёт свои тайные 
> разработки) -- максимально унифицировать механизмы взаимодействия с 
> hasher, qemu, sudo-root a.k.a. tar2fs, потенциально возможными в 
> степях obivalger@ и shaba@ аналогичными инструментами контейнеризации. 
> Чтобы внутренние скрипты, выполняющие что-то полезное "как бы под 
> рутом" внутри этой среды были не очень сильно зависимыми от того, кто 
> и какую среду им смоделировал снаружи. А главное, чтобы в процессе 
> моделирования можно было, в зависимости от архитектуры и задачи, 
> определять более подходящий инструмент моделирования. Воспроизводимой 
> сборки пакетов это, конечно, не касается, речь об автоматизации 
> тестирования, сборки и перепаковки образов, моделирования сетевого 
> взаимодействия, построения сложных стендов, итп.

Сложные стенды вообще тяжело строить унифицированными инструментами. 
Часто так случается, что для сложных стендов наши инструменты в принципе 
не существуют (простой пример - стенд, одна из составляющих которых 
работает под Windows).

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 15.10.2019 22:06, Vladimir D. Seleznev wrote:
> On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
>> On 15.10.2019 10:32, Michael Shigorin wrote:
>>> Зачем это тащить в hasher, особенно если на сборочнице?
>>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
>> Есть цель сделать автоматическое тестирование воспроизводимым образом и
>> сразу в процессе сборки пакета.
> Если воспроизводимым образом, то прокидывать репозитории в сборочную
> среду не нужно: все требуемые пакеты нужно указать в BuildRequires.
>
> Тестирование пакетов — это безусловно важно, однако нет задачи проводить
> всеобъемлющее тестирование всевозможного поведения каждого пакета. От
> репозитория пакетов программного обеспечения в первую очередь ожидают
> других качеств: корректную доставку программного обеспечения,
> т.е. корректную установку пакетов, удаление и бесшовного обновления,
> консистентность самого репозитория. Консистентность репозитория по
> большей части у нас проверяется сборочной системой, корректность
> установки также тестируется в процессе сборки. Тестировать корректность
> обновления сложнее, и тут уже больше требуется внимательность и
> ответственность мейнтейнеров пакетов.

Тестирование консистентности установки в нашей сборочнице явно не 
покрывает тех сложных случаев, когда пакетная база обновляемой системы 
ощутимо влияет на  инструменты обновления.

Из последних примеров - это lua в p8 и mod_php5 в том же p8.

В нашем apt есть такая особенность, что если установленный в системе 
пакет требуется достаточно большому количеству установленных в системе 
пакетов - то удалить (заменить) его средствами межпакетных 
зависимостей/конфликтов практически нереально для тех случаев, когда 
Obsoletes использовать нельзя.

при этом любой пакет из уже установленных в систему может стать ошибкой 
обновления при сборке его с новой версией из конфликтующих.


Отчётливо это видно на mod_php5, который конфликтует с mod_php7 и не 
заменяется mod_php7.

Если у тебя был установлен пакет с mod_php5 в зависимостях, то даже при 
обновлении этого пакета и замене такой зависимости на mod_php7 - apt 
сообщит о конфликте и не будет продолжать работу.

Такая же проблема существует с разделяемыми библиотеками.

>
> Отдельно замечу про стабильные ветки репозитория. Стабильность означает
> неизменность общего поведения приложений. Т.е., не должно быть ситуации,
> когда в результате обновления пакета в стабильной ветке его поведение
> меняется, например, на противоположное. И стабильность невозможно в
> общем случае гарантировать обширным тестированием пакетов: довольно
> трудно формализовать неизменность поведения, в отличие от некорректного
> поведения программы. В некоторых проектах в стабильных ветках
> замораживают версии пакетов и бэкпортируют только security fixes. Это
> довольно строгое требование, особенно для прикладных программ, но
> оправданное для базовой системы. А когда, допустим, в стабильной ветке
> находится некая MyNiceDB, которая к некоторому моменту уже устарела, и
> хочется новую функциональность из новой версии (скажем, третьей), то
> лучше не обновлять эту версию, а собрать новый пакет MyNiceDB3
> (возможно, с правильным указанием конфликтов). Таким образом никому
> поведение не будет сломано, и кому надо, сможет воспользоваться новой
> версией с новой функциональностью. То же самое можно сказать и про
> разделяемые библиотеки (shared library policy в т.ч. для этого
> предлагалось).

Я не знаю дистрибутивов Linux, в которых замораживается 100% версий 
стабильного дистрибутива и идёт только бэкпорт патчей.

Хотя идея конечно, замечательная. Но тяжело реализуемая.

Re: [devel] [I] rpm-build-vm: vm-run

[Vladimir D. Seleznev]

On Wed, Oct 16, 2019 at 08:05:51AM +0300, Anton Farygin wrote:
> On 15.10.2019 22:06, Vladimir D. Seleznev wrote:
> > On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
> >> On 15.10.2019 10:32, Michael Shigorin wrote:
> >>> Зачем это тащить в hasher, особенно если на сборочнице?
> >>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
> >> Есть цель сделать автоматическое тестирование воспроизводимым образом и
> >> сразу в процессе сборки пакета.
> > Если воспроизводимым образом, то прокидывать репозитории в сборочную
> > среду не нужно: все требуемые пакеты нужно указать в BuildRequires.
> >
> > Тестирование пакетов — это безусловно важно, однако нет задачи проводить
> > всеобъемлющее тестирование всевозможного поведения каждого пакета. От
> > репозитория пакетов программного обеспечения в первую очередь ожидают
> > других качеств: корректную доставку программного обеспечения,
> > т.е. корректную установку пакетов, удаление и бесшовного обновления,
> > консистентность самого репозитория. Консистентность репозитория по
> > большей части у нас проверяется сборочной системой, корректность
> > установки также тестируется в процессе сборки. Тестировать корректность
> > обновления сложнее, и тут уже больше требуется внимательность и
> > ответственность мейнтейнеров пакетов.
> 
> Тестирование консистентности установки в нашей сборочнице явно не 
> покрывает тех сложных случаев, когда пакетная база обновляемой системы 
> ощутимо влияет на  инструменты обновления.

Поэтому я и написал по большей части, а тестирование обновляемости
сборочницой вообще не проводится.

> Из последних примеров - это lua в p8 и mod_php5 в том же p8.

Ровно по той же причине, что и в ответе выше.

> В нашем apt есть такая особенность, что если установленный в системе 
> пакет требуется достаточно большому количеству установленных в системе 
> пакетов - то удалить (заменить) его средствами межпакетных 
> зависимостей/конфликтов практически нереально для тех случаев, когда 
> Obsoletes использовать нельзя.
> 
> при этом любой пакет из уже установленных в систему может стать ошибкой 
> обновления при сборке его с новой версией из конфликтующих.
> 
> 
> Отчётливо это видно на mod_php5, который конфликтует с mod_php7 и не 
> заменяется mod_php7.
> 
> Если у тебя был установлен пакет с mod_php5 в зависимостях, то даже при 
> обновлении этого пакета и замене такой зависимости на mod_php7 - apt 
> сообщит о конфликте и не будет продолжать работу.
> 
> Такая же проблема существует с разделяемыми библиотеками.

Верно. Но это не то, для чего нужно тестировать сам apt, для этого как
раз нужно тестирование этих пакетов на обновляемость.

Тестировать apt, конечно же, нужно, но не в самом сборочном задании.

> > Отдельно замечу про стабильные ветки репозитория. Стабильность означает
> > неизменность общего поведения приложений. Т.е., не должно быть ситуации,
> > когда в результате обновления пакета в стабильной ветке его поведение
> > меняется, например, на противоположное. И стабильность невозможно в
> > общем случае гарантировать обширным тестированием пакетов: довольно
> > трудно формализовать неизменность поведения, в отличие от некорректного
> > поведения программы. В некоторых проектах в стабильных ветках
> > замораживают версии пакетов и бэкпортируют только security fixes. Это
> > довольно строгое требование, особенно для прикладных программ, но
> > оправданное для базовой системы. А когда, допустим, в стабильной ветке
> > находится некая MyNiceDB, которая к некоторому моменту уже устарела, и
> > хочется новую функциональность из новой версии (скажем, третьей), то
> > лучше не обновлять эту версию, а собрать новый пакет MyNiceDB3
> > (возможно, с правильным указанием конфликтов). Таким образом никому
> > поведение не будет сломано, и кому надо, сможет воспользоваться новой
> > версией с новой функциональностью. То же самое можно сказать и про
> > разделяемые библиотеки (shared library policy в т.ч. для этого
> > предлагалось).
> 
> Я не знаю дистрибутивов Linux, в которых замораживается 100% версий 
> стабильного дистрибутива и идёт только бэкпорт патчей.

Вроде бы по крайней мере раньше Debian делал очень близкое к этому, но
опять-таки, я не говорю про 100% пакетов.

> Хотя идея конечно, замечательная. Но тяжело реализуемая.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 18.10.2019 3:40, Vladimir D. Seleznev wrote:
> On Wed, Oct 16, 2019 at 08:05:51AM +0300, Anton Farygin wrote:
>> On 15.10.2019 22:06, Vladimir D. Seleznev wrote:
>>> On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
>>>> On 15.10.2019 10:32, Michael Shigorin wrote:
>>>>> Зачем это тащить в hasher, особенно если на сборочнице?
>>>>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
>>>> Есть цель сделать автоматическое тестирование воспроизводимым образом и
>>>> сразу в процессе сборки пакета.
>>> Если воспроизводимым образом, то прокидывать репозитории в сборочную
>>> среду не нужно: все требуемые пакеты нужно указать в BuildRequires.
>>>
>>> Тестирование пакетов — это безусловно важно, однако нет задачи проводить
>>> всеобъемлющее тестирование всевозможного поведения каждого пакета. От
>>> репозитория пакетов программного обеспечения в первую очередь ожидают
>>> других качеств: корректную доставку программного обеспечения,
>>> т.е. корректную установку пакетов, удаление и бесшовного обновления,
>>> консистентность самого репозитория. Консистентность репозитория по
>>> большей части у нас проверяется сборочной системой, корректность
>>> установки также тестируется в процессе сборки. Тестировать корректность
>>> обновления сложнее, и тут уже больше требуется внимательность и
>>> ответственность мейнтейнеров пакетов.
>> Тестирование консистентности установки в нашей сборочнице явно не
>> покрывает тех сложных случаев, когда пакетная база обновляемой системы
>> ощутимо влияет на  инструменты обновления.
> Поэтому я и написал по большей части, а тестирование обновляемости
> сборочницой вообще не проводится.
Именно, и в этом месте чаще всего взрывается.
>
>> Из последних примеров - это lua в p8 и mod_php5 в том же p8.
> Ровно по той же причине, что и в ответе выше.
Конечно.
>
>> В нашем apt есть такая особенность, что если установленный в системе
>> пакет требуется достаточно большому количеству установленных в системе
>> пакетов - то удалить (заменить) его средствами межпакетных
>> зависимостей/конфликтов практически нереально для тех случаев, когда
>> Obsoletes использовать нельзя.
>>
>> при этом любой пакет из уже установленных в систему может стать ошибкой
>> обновления при сборке его с новой версией из конфликтующих.
>>
>>
>> Отчётливо это видно на mod_php5, который конфликтует с mod_php7 и не
>> заменяется mod_php7.
>>
>> Если у тебя был установлен пакет с mod_php5 в зависимостях, то даже при
>> обновлении этого пакета и замене такой зависимости на mod_php7 - apt
>> сообщит о конфликте и не будет продолжать работу.
>>
>> Такая же проблема существует с разделяемыми библиотеками.
> Верно. Но это не то, для чего нужно тестировать сам apt, для этого как
> раз нужно тестирование этих пакетов на обновляемость.
>
> Тестировать apt, конечно же, нужно, но не в самом сборочном задании.

Я не вижу причин это делать не в сборочном задании. И не только apt.


>
>>> Отдельно замечу про стабильные ветки репозитория. Стабильность означает
>>> неизменность общего поведения приложений. Т.е., не должно быть ситуации,
>>> когда в результате обновления пакета в стабильной ветке его поведение
>>> меняется, например, на противоположное. И стабильность невозможно в
>>> общем случае гарантировать обширным тестированием пакетов: довольно
>>> трудно формализовать неизменность поведения, в отличие от некорректного
>>> поведения программы. В некоторых проектах в стабильных ветках
>>> замораживают версии пакетов и бэкпортируют только security fixes. Это
>>> довольно строгое требование, особенно для прикладных программ, но
>>> оправданное для базовой системы. А когда, допустим, в стабильной ветке
>>> находится некая MyNiceDB, которая к некоторому моменту уже устарела, и
>>> хочется новую функциональность из новой версии (скажем, третьей), то
>>> лучше не обновлять эту версию, а собрать новый пакет MyNiceDB3
>>> (возможно, с правильным указанием конфликтов). Таким образом никому
>>> поведение не будет сломано, и кому надо, сможет воспользоваться новой
>>> версией с новой функциональностью. То же самое можно сказать и про
>>> разделяемые библиотеки (shared library policy в т.ч. для этого
>>> предлагалось).
>> Я не знаю дистрибутивов Linux, в которых замораживается 100% версий
>> стабильного дистрибутива и идёт только бэкпорт патчей.
> Вроде бы по крайней мере раньше Debian делал очень близкое к этому, но
> опять-таки, я не говорю про 100% пакетов.

Не 100% пакетов у нас часто замораживаются даже между стабильными 
релизами. Это не показатель.

Re: [devel] [I] rpm-build-vm: vm-run

[Michael Shigorin]

On Fri, Oct 18, 2019 at 03:40:29AM +0300, Vladimir D. Seleznev wrote:
> > Тестирование консистентности установки в нашей сборочнице
> > явно не покрывает тех сложных случаев, когда пакетная база
> > обновляемой системы ощутимо влияет на  инструменты
> > обновления.
> Поэтому я и написал по большей части, а тестирование
> обновляемости сборочницой вообще не проводится.

И не должно: это дорогостоящая операция (см. installcheck
того же полного kf5*/kde5*) при невысоком шансе выловить
что-то действительно полезное -- такое практически всегда
лучше выполнять асинхронно, как по мне.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 18.10.2019 11:32, Michael Shigorin wrote:
> On Fri, Oct 18, 2019 at 03:40:29AM +0300, Vladimir D. Seleznev wrote:
>>> Тестирование консистентности установки в нашей сборочнице
>>> явно не покрывает тех сложных случаев, когда пакетная база
>>> обновляемой системы ощутимо влияет на  инструменты
>>> обновления.
>> Поэтому я и написал по большей части, а тестирование
>> обновляемости сборочницой вообще не проводится.
> И не должно: это дорогостоящая операция (см. installcheck
> того же полного kf5*/kde5*) при невысоком шансе выловить
> что-то действительно полезное -- такое практически всегда
> лучше выполнять асинхронно, как по мне.
>
Если так порассуждать, то тесты вообще не надо выполнять. Ну а что, жили 
же раньше без них.

Нет, тестирование во время сборки нужно, а если не хватает на это сил, 
то можно подумать об оптимизации этого процесса и увеличении 
производительности оборудования.

В идеале базовые тестовые сценарии должны выполняться после каждого 
коммита, но нам пока это реализовать у себя слабо.

Re: [devel] [I] rpm-build-vm: vm-run

[Michael Shigorin]

On Fri, Oct 18, 2019 at 12:12:00PM +0300, Anton Farygin wrote:
> >> Поэтому я и написал по большей части, а тестирование
> >> обновляемости сборочницой вообще не проводится.
> > И не должно: это дорогостоящая операция
> Если так порассуждать, то тесты вообще не надо выполнять.

Знаешь, мил друг, а давай-ка тогда исошки заодно собирать
на каждый пакет -- мало ли что развалится!

(сколько раз в год я тут размахивал руками, мол, опять вы
мне со вторника на среду всё сломали -- вспоминать не так
важно, это же тесты, а иначе их выполнять вообще не надо)

> Нет, тестирование во время сборки нужно, а если не хватает
> на это сил, то можно подумать об оптимизации этого процесса
> и увеличении производительности оборудования.
> 
> В идеале базовые тестовые сценарии должны выполняться после
> каждого коммита, но нам пока это реализовать у себя слабо.

Есть такое наблюдение, что когда сделали J2EE как набор
технологий и методологий ("пусть небыстро, зато предсказуемо
даже в случае погонщика с горизонтально масштабируемым
количеством индусов") -- индустрия разработки в целом взяла
курс на деградацию с массированным копипастом, полным
непониманием того, что вообще происходит за пределами
вот этого экрана кода, и т.д. и т.п.

Это не к тому, что CI не надо.  Может быть полезно, только
с умом и без истерик.  Иначе у тебя без особых вариантов
со временем процессы подменяют людей, что приводит к западной
колее, в которой ты тягаться с тем же редхатом не сможешь уже
по ресурсам и опыту.

А наш путь -- он не такой вот тупой индуктивный, он дедуктивный.
Про малые силы со светлой головой.  Про постановку и решение
полезных задач, а не просто решаемых.  Про ресурсы туда, где они
нужны, а не because we can.

И к тестированию это всё относится тоже в полной мере.

Так думаю.

PS: почитай разбор полётов по Boeing 737 MAX с киванием,
мол, свалили разработку контрактору за четверть цены своих
разработчиков -- вдруг расхочется разводить обсуждалово:
https://www.zerohedge.com/news/2019-06-29/boeing-outsourced-its-737-max-software-9-hour-engineers-0

Не работает замена людей на "процессы", доведённая до крайности.
Фиг потом разберёшься, где на самом деле проблема/чинить...

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 18.10.2019 12:29, Michael Shigorin wrote:
> On Fri, Oct 18, 2019 at 12:12:00PM +0300, Anton Farygin wrote:
>>>> Поэтому я и написал по большей части, а тестирование
>>>> обновляемости сборочницой вообще не проводится.
>>> И не должно: это дорогостоящая операция
>> Если так порассуждать, то тесты вообще не надо выполнять.
> Знаешь, мил друг, а давай-ка тогда исошки заодно собирать
> на каждый пакет -- мало ли что развалится!
Отличная идея! Если пакет входит в образ или в инсталятор - то надо 
собрать ISO и попробовать её установить (автоматически). Значительно 
облегчило бы работу тем, кто собирает дистрибутивы.
>
> (сколько раз в год я тут размахивал руками, мол, опять вы
> мне со вторника на среду всё сломали -- вспоминать не так
> важно, это же тесты, а иначе их выполнять вообще не надо)
Вот я как раз про это же - что бы у тебя не было необходимости 
размахивать руками - это должна делать автоматика.
>
>> Нет, тестирование во время сборки нужно, а если не хватает
>> на это сил, то можно подумать об оптимизации этого процесса
>> и увеличении производительности оборудования.
>>
>> В идеале базовые тестовые сценарии должны выполняться после
>> каждого коммита, но нам пока это реализовать у себя слабо.
<skip>
>
> Это не к тому, что CI не надо.  Может быть полезно, только
> с умом и без истерик.  Иначе у тебя без особых вариантов
> со временем процессы подменяют людей, что приводит к западной
> колее, в которой ты тягаться с тем же редхатом не сможешь уже
> по ресурсам и опыту.

Миша, люди и CI должны дополнять друг друга.

То, что можно делать автоматически - надо делать автоматически. Ручной 
работы это никак не отменяет.

[devel] [JT] сборочница 3.0, qa/ci, ресурсы, приоритеты (was: [I] rpm-build-vm: vm-run)

[Michael Shigorin]

On Fri, Oct 18, 2019 at 12:36:50PM +0300, Anton Farygin wrote:
> >>> И не должно: это дорогостоящая операция
> >> Если так порассуждать, то тесты вообще не надо выполнять.
> > Знаешь, мил друг, а давай-ка тогда исошки заодно собирать
> > на каждый пакет -- мало ли что развалится!
> Отличная идея! Если пакет входит в образ или в инсталятор - то
> надо собрать ISO и попробовать её установить (автоматически).
> Значительно облегчило бы работу тем, кто собирает дистрибутивы.

Но этого мало: надо сперва поставить предыдущий ISO и попробовать
обновиться с него до полученного пакета.  Это сильно облегчит
жизнь тем, кто обновляет дистрибутив. </>

Если не доводить до абсурда -- думаю, компромиссом при текущей
ресурсоёмкости сборки пакетов и исошек была бы для начала ночная
сборка исошек с отбрасыванием "такого же" результата, т.е. лишь
изменения становятся заметными в отчёте.  Возможно, при наличии
лишних ресурсов и электроэнергии затем с переходом к асинхронной
проверке уже собранных заданий, но там понадобится либо кратное
превышение ресурсов над сборочными (т.к. hasher применяет один
чрут, а mkimage -- минимум два, обычно с полдюжины и больше),
либо какое-то хитрое построение очереди (на которое есть спрос
и в самой сборочнице, но там критерии предложить ещё сложнее,
чем для карманов, я порой возвращаюсь к обдумыванию этого),
либо в "плотные" дни очередь на проверку будет до ближайшего
затишья заметно отставать от очереди на сборку.

В любом из первых двух случаев _сперва_ потребуется переводить
сборочницу с раздачи заданий исполнителям на разбор ими заданий,
о чём думает Глеб (и если ему чем-то получится помочь по другим
проектам, может, быстрее доберётся).  Тогда по крайней мере
должно стать возможно разделение ресурсов сборочных узлов между
hsh, собирающими пакеты, и hsh, занимающимися кусочками образов
(плюс более плотная загрузка уже имеющихся ядер и памяти).

Ну и напомню, что более насущным кандидатом на вагон
дополнительных ресурсов у нас является синхронная пересборка
пакетов, в сборочное окружение которых входят пакеты из вновь
собираемого задания -- о чём давно мечтал вслух at@ и что сейчас
аппроксимируется пересборками всего сизифа.

> > Это не к тому, что CI не надо.  Может быть полезно, только
> > с умом и без истерик.  Иначе у тебя без особых вариантов
> > со временем процессы подменяют людей, что приводит к западной
> > колее, в которой ты тягаться с тем же редхатом не сможешь уже
> > по ресурсам и опыту.
> Миша, люди и CI должны дополнять друг друга.  То, что можно
> делать автоматически - надо делать автоматически. Ручной работы
> это никак не отменяет.

Да.  И особенно на этапе постановки (и фильтрации) задач.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] [JT] сборочница 3.0, qa/ci, ресурсы, приоритеты

[Anton Farygin]

On 18.10.2019 13:39, Michael Shigorin wrote:
> On Fri, Oct 18, 2019 at 12:36:50PM +0300, Anton Farygin wrote:
>>>>> И не должно: это дорогостоящая операция
>>>> Если так порассуждать, то тесты вообще не надо выполнять.
>>> Знаешь, мил друг, а давай-ка тогда исошки заодно собирать
>>> на каждый пакет -- мало ли что развалится!
>> Отличная идея! Если пакет входит в образ или в инсталятор - то
>> надо собрать ISO и попробовать её установить (автоматически).
>> Значительно облегчило бы работу тем, кто собирает дистрибутивы.
> Но этого мало: надо сперва поставить предыдущий ISO и попробовать
> обновиться с него до полученного пакета.  Это сильно облегчит
> жизнь тем, кто обновляет дистрибутив. </>

Это просто другой тест.

Ночная сборка ISO образов не поможет. В идеале нужно сделать так, что бы 
ломающий систему пакет шёл сразу с её исправлением.

Re: [devel] [I] rpm-build-vm: vm-run

[Vladimir D. Seleznev]

On Fri, Oct 18, 2019 at 07:48:30AM +0300, Anton Farygin wrote:
> On 18.10.2019 3:40, Vladimir D. Seleznev wrote:
> > On Wed, Oct 16, 2019 at 08:05:51AM +0300, Anton Farygin wrote:
> >> On 15.10.2019 22:06, Vladimir D. Seleznev wrote:
> >>> On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
> >>>> On 15.10.2019 10:32, Michael Shigorin wrote:
> >>>>> Зачем это тащить в hasher, особенно если на сборочнице?
> >>>>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
> >>>> Есть цель сделать автоматическое тестирование воспроизводимым образом и
> >>>> сразу в процессе сборки пакета.
> >>> Если воспроизводимым образом, то прокидывать репозитории в сборочную
> >>> среду не нужно: все требуемые пакеты нужно указать в BuildRequires.
> >>>
> >>> Тестирование пакетов — это безусловно важно, однако нет задачи проводить
> >>> всеобъемлющее тестирование всевозможного поведения каждого пакета. От
> >>> репозитория пакетов программного обеспечения в первую очередь ожидают
> >>> других качеств: корректную доставку программного обеспечения,
> >>> т.е. корректную установку пакетов, удаление и бесшовного обновления,
> >>> консистентность самого репозитория. Консистентность репозитория по
> >>> большей части у нас проверяется сборочной системой, корректность
> >>> установки также тестируется в процессе сборки. Тестировать корректность
> >>> обновления сложнее, и тут уже больше требуется внимательность и
> >>> ответственность мейнтейнеров пакетов.
> >> Тестирование консистентности установки в нашей сборочнице явно не
> >> покрывает тех сложных случаев, когда пакетная база обновляемой системы
> >> ощутимо влияет на  инструменты обновления.
> > Поэтому я и написал по большей части, а тестирование обновляемости
> > сборочницой вообще не проводится.
> Именно, и в этом месте чаще всего взрывается.

Я не спорю, наоборот: я изначально написал, что именно это и надо лучше
тестировать. Но это не задача сборочницы. Более того, практически
невозможно формализовать автоматическое тестирование такого на стороне
сборочницы.

> > [...]
> > Тестировать apt, конечно же, нужно, но не в самом сборочном задании.
> 
> Я не вижу причин это делать не в сборочном задании. И не только apt.

Сборочница для этого не предназначена.

> >>> [...]
> >> Я не знаю дистрибутивов Linux, в которых замораживается 100% версий
> >> стабильного дистрибутива и идёт только бэкпорт патчей.
> > Вроде бы по крайней мере раньше Debian делал очень близкое к этому, но
> > опять-таки, я не говорю про 100% пакетов.
> 
> Не 100% пакетов у нас часто замораживаются даже между стабильными 
> релизами. Это не показатель.

Эти "не 100% пакетов" — о-малое, не надо переиначивать мою мысль. Если
называете бранчи стабильными, то нужно, чтобы они были стабильными.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 18.10.2019 20:43, Vladimir D. Seleznev wrote:
> On Fri, Oct 18, 2019 at 07:48:30AM +0300, Anton Farygin wrote:
>> On 18.10.2019 3:40, Vladimir D. Seleznev wrote:
>>> On Wed, Oct 16, 2019 at 08:05:51AM +0300, Anton Farygin wrote:
>>>> On 15.10.2019 22:06, Vladimir D. Seleznev wrote:
>>>>> On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
>>>>>> On 15.10.2019 10:32, Michael Shigorin wrote:
>>>>>>> Зачем это тащить в hasher, особенно если на сборочнице?
>>>>>>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
>>>>>> Есть цель сделать автоматическое тестирование воспроизводимым образом и
>>>>>> сразу в процессе сборки пакета.
>>>>> Если воспроизводимым образом, то прокидывать репозитории в сборочную
>>>>> среду не нужно: все требуемые пакеты нужно указать в BuildRequires.
>>>>>
>>>>> Тестирование пакетов — это безусловно важно, однако нет задачи проводить
>>>>> всеобъемлющее тестирование всевозможного поведения каждого пакета. От
>>>>> репозитория пакетов программного обеспечения в первую очередь ожидают
>>>>> других качеств: корректную доставку программного обеспечения,
>>>>> т.е. корректную установку пакетов, удаление и бесшовного обновления,
>>>>> консистентность самого репозитория. Консистентность репозитория по
>>>>> большей части у нас проверяется сборочной системой, корректность
>>>>> установки также тестируется в процессе сборки. Тестировать корректность
>>>>> обновления сложнее, и тут уже больше требуется внимательность и
>>>>> ответственность мейнтейнеров пакетов.
>>>> Тестирование консистентности установки в нашей сборочнице явно не
>>>> покрывает тех сложных случаев, когда пакетная база обновляемой системы
>>>> ощутимо влияет на  инструменты обновления.
>>> Поэтому я и написал по большей части, а тестирование обновляемости
>>> сборочницой вообще не проводится.
>> Именно, и в этом месте чаще всего взрывается.
> Я не спорю, наоборот: я изначально написал, что именно это и надо лучше
> тестировать. Но это не задача сборочницы. Более того, практически
> невозможно формализовать автоматическое тестирование такого на стороне
> сборочницы.
Почему ? Очень даже хорошо формализуется.
>
>>> [...]
>>> Тестировать apt, конечно же, нужно, но не в самом сборочном задании.
>> Я не вижу причин это делать не в сборочном задании. И не только apt.
> Сборочница для этого не предназначена.
Ну это же не проблема.
>
>>>>> [...]
>>>> Я не знаю дистрибутивов Linux, в которых замораживается 100% версий
>>>> стабильного дистрибутива и идёт только бэкпорт патчей.
>>> Вроде бы по крайней мере раньше Debian делал очень близкое к этому, но
>>> опять-таки, я не говорю про 100% пакетов.
>> Не 100% пакетов у нас часто замораживаются даже между стабильными
>> релизами. Это не показатель.
> Эти "не 100% пакетов" — о-малое, не надо переиначивать мою мысль. Если
> называете бранчи стабильными, то нужно, чтобы они были стабильными.
Тогда надо начинать с описания формулы стабильности бранча. Т.е. - каких 
целей мы хотим достигнуть в "стабильности" ?

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 14.10.2019 0:29, Vitaly Chikunov wrote:
> ps. Из текущих проблем:
> - overlayfs (если используется) не поддерживает чтение root-owned файлов на lowerdir=
> - tmpfs не поддерживает user xattr
> - нет контроля над флайвором ядра.

А как быть с переменными окружения ? они попадают в vm-run ?

Re: [devel] [I] rpm-build-vm: vm-run

[Vitaly Chikunov]

On Wed, Dec 11, 2019 at 02:15:49PM +0300, Anton Farygin wrote:
> 
> А как быть с переменными окружения ? они попадают в vm-run ?

Попадают.

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 11.12.2019 15:33, Vitaly Chikunov wrote:
> On Wed, Dec 11, 2019 at 02:15:49PM +0300, Anton Farygin wrote:
>> А как быть с переменными окружения ? они попадают в vm-run ?
> Попадают.
>
Что-то у меня не получается питоновские тесты запускать. Будут разбираться.

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 11.12.2019 19:48, Anton Farygin wrote:
> On 11.12.2019 15:33, Vitaly Chikunov wrote:
>> On Wed, Dec 11, 2019 at 02:15:49PM +0300, Anton Farygin wrote:
>>> А как быть с переменными окружения ? они попадают в vm-run ?
>> Попадают.
>>
> Что-то у меня не получается питоновские тесты запускать. Будут 
> разбираться.
А оттранслировать builder на рута в виртуалке никак нельзя ?

А то получается вот так:
[root@(none) ~]# id
uid=0(root) gid=0(root) groups=0(root)
[root@(none) ~]# touch s
[root@(none) ~]# ls -al s
-rw-r--r-- 1 builder builder 0 Dec 12 15:11 s

У меня, правда, тест падает по какой-то другой причине:

....

   File "/usr/lib/python3/site-packages/_pytest/capture.py", line 627, 
in snap

     res = super().snap()
   File "/usr/lib/python3/site-packages/_pytest/capture.py", line 587, 
in snap
     self.tmpfile.truncate()
FileNotFoundError: [Errno 2] No such file or directory

без vm-run тест проходит.

Re: [devel] [I] rpm-build-vm: vm-run

[Vitaly Chikunov]

On Thu, Dec 12, 2019 at 06:12:44PM +0300, Anton Farygin wrote:
> On 11.12.2019 19:48, Anton Farygin wrote:
> > On 11.12.2019 15:33, Vitaly Chikunov wrote:
> > > On Wed, Dec 11, 2019 at 02:15:49PM +0300, Anton Farygin wrote:
> > > > А как быть с переменными окружения ? они попадают в vm-run ?
> > > Попадают.
> > > 
> > Что-то у меня не получается питоновские тесты запускать. Будут
> > разбираться.
> А оттранслировать builder на рута в виртуалке никак нельзя ?
> 
> А то получается вот так:
> [root@(none) ~]# id
> uid=0(root) gid=0(root) groups=0(root)
> [root@(none) ~]# touch s
> [root@(none) ~]# ls -al s
> -rw-r--r-- 1 builder builder 0 Dec 12 15:11 s

Да.
В 9p такого не знаю разве что писать свой 9p сервер.
Варианты решений - overlayfs, tmpfs, или генерировать при
запуске свой диск с которым и работать.

> 
> У меня, правда, тест падает по какой-то другой причине:
> 
> ....
> 
>   File "/usr/lib/python3/site-packages/_pytest/capture.py", line 627, in
> snap
> 
>     res = super().snap()
>   File "/usr/lib/python3/site-packages/_pytest/capture.py", line 587, in
> snap
>     self.tmpfile.truncate()
> FileNotFoundError: [Errno 2] No such file or directory
> 
> без vm-run тест проходит.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] [I] rpm-build-vm: vm-run (update 1.3)

[Vitaly Chikunov]

Добавил, чтоб по умолчанию были все ядра и MemAvailable памяти.

Так же поддержка share_network=1. Демо:

  $ hsh-install iproute2 telnet

  $ share_network=1 hsh-shell --mountpoints=/proc,/dev/kvm

  builder@x86_64:/.in$ vm-run

  root@x86_64:/.in# nproc
  32

  root@x86_64:/.in# free -h
		total        used        free      shared  buff/cache   available
  Mem:           13Gi        78Mi        13Gi          0B        14Mi        12Gi

  root@x86_64:/.in# telnet yandex.ru 80
  Trying 77.88.55.88...
  Connected to yandex.ru.
  Escape character is '^]'.
  ...

Есть возможность выбрать ядро если заинсталлировать его вручную перед инсталлом
rpm-build-vm. (Пока) обязательно _перед_, иначе не будет initrd.

  $ hsh-install kernel-image-std-def kernel-image-rt
  $ hsh-install rpm-build-vm
  <13>Dec 12 16:17:41 rpmi: rpm-build-vm-1.2-alt1 1576165647 installed

  $ hsh-shell --mountpoints=/proc,/dev/kvm

  builder@x86_64:/.in$ ls -la /boot/initrd*
  -rw-r--r-- 1 rooter rooter 13334528 Dec 12 16:17 /boot/initrd-4.19.59-rt-alt8.rt24.img
  -rw-r--r-- 1 rooter rooter 12400128 Dec 12 16:17 /boot/initrd-4.19.88-std-def-alt1.img
  -rw-r--r-- 1 rooter rooter 12431872 Dec 12 16:17 /boot/initrd-5.3.15-un-def-alt1.img

  builder@x86_64:/.in$ vm-run --kernel=rt

  root@x86_64:/.in# uname -a
  Linux (none) 4.19.59-rt-alt8.rt24 #1 SMP PREEMPT RT Sun Nov 24 02:02:59 UTC 2019 x86_64 GNU/Linux

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 12.12.2019 19:06, Vitaly Chikunov wrote:
> On Thu, Dec 12, 2019 at 06:12:44PM +0300, Anton Farygin wrote:
>> On 11.12.2019 19:48, Anton Farygin wrote:
>>> On 11.12.2019 15:33, Vitaly Chikunov wrote:
>>>> On Wed, Dec 11, 2019 at 02:15:49PM +0300, Anton Farygin wrote:
>>>>> А как быть с переменными окружения ? они попадают в vm-run ?
>>>> Попадают.
>>>>
>>> Что-то у меня не получается питоновские тесты запускать. Будут
>>> разбираться.
>> А оттранслировать builder на рута в виртуалке никак нельзя ?
>>
>> А то получается вот так:
>> [root@(none) ~]# id
>> uid=0(root) gid=0(root) groups=0(root)
>> [root@(none) ~]# touch s
>> [root@(none) ~]# ls -al s
>> -rw-r--r-- 1 builder builder 0 Dec 12 15:11 s
> Да.
> В 9p такого не знаю разве что писать свой 9p сервер.
> Варианты решений - overlayfs, tmpfs, или генерировать при
> запуске свой диск с которым и работать.
>
Я пока так и не понял, почему у меня падают тесты. Что-то не то с p9.

Увеличение объёма памяти не помогает.

Re: [devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 15.12.2019 18:49, Leonid Krivoshein wrote:
>>
>
> Тесты с vm-run должны работать с содержимым файлов хостовой системы, 
> но не с файловой системой, атрибутами и каталогами. Иначе сюрпризов не 
> избежать. Если нужна полноценная файловая система на госте, можно 
> сделать файл truncate'ом и передать его виртуалке в качестве диска 
> через --qemu=...

тесты записывают отчёты о своей работе.

Есть ещё вот такая штука:

https://virtio-fs.gitlab.io/

Может быть она работает получше p9 ?

Re: [devel] [I] rpm-build-vm: vm-run

[Oleg Solovyov]

[-- Attachment #1: Type: text/plain, Size: 2046 bytes --]

On понедельник, 14 октября 2019 г. 00:29:47 MSK Vitaly Chikunov wrote:
> Hi,
> 
> В hasher появилась возможность запускать тесты под QEMU root-ом.
> 
>   BuildRequires: rpm-build-vm
> 
> пример запуска:
> 
>   %check
>   if [ -w /dev/kvm ]; then
>     vm-run make check
>   fi
> 
> (На архитектурах где нет QEMU (e2k) vm-run превращается в нооп.)
> 
> Наличие /dev/kvm не обязательно, но помогает. Скорее всего большие тесты
> без KVM запускать не стоит.
> 
> Минимальный пример интерактивной работы:
> 
>   altair:~$ hsh --ini
>   altair:~$ hsh-install rpm-build-vm
>   altair:~$ hsh-shell --mountpoints=/proc,/dev/kvm
>   builder@x86_64:/.in$ vm-run
>   root@x86_64:/.in# id
>   uid=0(root) gid=0(root) groups=0(root)
>   root@x86_64:/.in# exit
>   builder@x86_64:/.in$
> 
> Работает по аналогии vido/virtme/eudyptula-boot - запуск ядра и
> монтирование корня через 9p.
> 
> Просьба тестировать, но не закладываться так как это альфа версия.
> Feedback & commits welcome.
> 
> Спасибо ldv за хэшер с `allowed_devices=/dev/kvm' и glebfm за необходимый
> фикс других пакетов для нового хэшера и первоначальную идею.
> 
> ps. Из текущих проблем:
> - overlayfs (если используется) не поддерживает чтение root-owned файлов на
> lowerdir= - tmpfs не поддерживает user xattr
> - нет контроля над флайвором ядра.

Можно как-то проверить с помощью этой утилиты собирающееся в данный момент 
ядро или поддерживаются только ядра из репозитория?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [devel] [I] rpm-build-vm: vm-run

[Vitaly Chikunov]

Hi,

On Tue, Feb 18, 2020 at 10:56:54AM +0300, Oleg Solovyov wrote:
> Можно как-то проверить с помощью этой утилиты собирающееся в данный момент 
> ядро или поддерживаются только ядра из репозитория?

Если сможете сделать make-initrd для собирающегося в данный момент
ядра.