Перенос FreeIPA на Python 3 или как мы танцевали Samba (Александр Боковой, OSSDEVCONF-2017)

Ссылки сюда (4) →

Короткая ссылка: 20170924A

Докладчик

Александр Боковой

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

Для систем с долгосрочной коммерческой поддержкой это решение проекта Python означает существенное увеличение рисков и вложений ресурсов. Уже несколько лет в Fedora Project идет процесс по освобождению базовой системы от зависимостей на Python 2.7.

О том, во что это вылилось для проекта FreeIPA — этот доклад.

Видео

on youtube

Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.

Презентация

Thesis

Первая стабильная версия Python 3 (3.0) вышла в 2008 году. Разработчики интерпретатора CPython активно пытаются убедить пользователей переписать свои приложения с Python 2.x (2.7) на Python 3 с тем, чтобы прекратить поддерживать две несовместимые реализации. Fedora Project занят практическим вопросом перевода всего дистрибутива на Python 3 уже несколько лет. На сайте можно посмотреть текущее состояние этой работы.

• На середину сентября 2017 года отслеживалось 3494 пакета.
• Из них 455 были выпущены с поддержкой только Python 3, 1591 мог использоваться как с Python 3, так и Python 2.7, 100 пакетов были неправильно собраны, но не были проблематичными с точки зрения кода.
• Наконец, 857 пакетами никто не занимался, 405 пакетов зависили от работы над другими, а 86 пакетов портировать не собирались, поэтому зависящие от них проекты вынуждены переписывать свой код полностью.

Проект FreeIPA направлен на создание инфраструктуры уровня предприятия. Он объединяет в себя средства развертывания серверов LDAP, Kerberos, Samba, DNS и других, а также развитую среду по управлению ресурсами. Эта среда, как ее серверная, так и клиентская части, написана на Python и отслеживается в рамках проекта портирования как группа «Identity Management»: Эта четвертая по величине группа пакетов: 224 пакета, из которых перенос 180 практически завершен.

Во многих случаях поддержка Python 3 не означает отказ от поддержки Python 2.7. Это так в случае FreeIPA, поскольку требуется поддерживать уже выпущенные версии FreeIPA в рамках Red Hat Enterprise Linux, где Python 2.7 выступает в роли основного интерпретатора, а версии FreeIPA все еще обновляются.

Так, RHEL 7.4 вышел с версией FreeIPA 4.5 и скорее всего в следующей версии RHEL 7 произойдет обновление FreeIPA. Поддержка двух параллельных веток кода на Python 2 и Python 3 экономически неэффективна, поэтому основной целью ставилась задача приведения имеющегося кода в совместимое состояние с обеими версиями Python.

По счастью, эта задача интересует многих в сообществе и были написаны специальные библиотеки, которые позволяют сгладить разницу в синтаксисе и семантике между Python 2.7 и Python 3.5/3.6 для прикладных разработчиков. В рамках проекта по переносу приложений на Python 3 в Red Hat было написано руководство по «консервативной миграции», которое и рекомендуется к прочтению.

Одним из сдерживающих факторов при переносе приложений являюся зависимости, написанные на C и интегрируемые в приложения на Python с помощью внутреннего API интерпретатора CPython. Структуры данных и вызываемые функции между интерпретаторами Python 2 и Python 3 различаются, да и рекомендуемые способы интеграции библиотек на C тоже изменились. Для большинства приложений это не так и важно, потому что переход на новый метод интеграции не критичен, но FreeIPA использует библиотеки из проекта Samba, где почти весь код модулей для Python автоматически генерируется из описаний IDL и тесно интегрирован с управлением памяти в Samba.

В Samba Team было решено обеспечить поддержку как Python 2.7, так и Python 3, поэтому сотрудниками Red Hat были написаны специальные макросы, которые позволяют компилировать один и тот же код модуля на C для обоих семейств интерпретаторов Python, py3c.

Результат использования этого набора макросов существенно упрощает поддержку модулей для двух языков. В качестве примера можно привести исправление, добавляющее поддержку Python 3 для модуля samba.messaging:

<source lang="diff> diff --git a/source4/lib/messaging/pymessaging.c b/source4/lib/messaging/pymessaging.c index d83f5e6a637..514f6d16970 100644 --- a/source4/lib/messaging/pymessaging.c +++ b/source4/lib/messaging/pymessaging.c @@ -20,6 +20,7 @@

*/

#include <Python.h>

+#include "python/py3compat.h"

#include "includes.h"
#include "python/modules.h"
#include "libcli/util/pyerrors.h"

@@ -36,7 +37,6 @@

#include <pytalloc.h>
#include "messaging_internal.h"

-void initmessaging(void);

extern PyTypeObject imessaging_Type;

@@ -505,19 +505,29 @@ PyTypeObject imessaging_Type = {

                 "Create a new object that can be used to communicate with the peers in the specified messaging path.\n"
};

-void initmessaging(void) +static struct PyModuleDef moduledef = { + PyModuleDef_HEAD_INIT, + .m_name = "messaging", + .m_doc = "Internal RPC", + .m_size = -1, + .m_methods = NULL, +}; + +MODULE_INIT_FUNC(messaging)

{
  PyObject *mod;

  if (PyType_Ready(&imessaging_Type) < 0)
          return;

+ return NULL;

- mod = Py_InitModule3("messaging", NULL, "Internal RPC"); + mod = PyModule_Create(&moduledef);

  if (mod == NULL)

- return; + return NULL;

  Py_INCREF((PyObject *)&imessaging_Type);
  PyModule_AddObject(mod, "Messaging", (PyObject *)&imessaging_Type);
  PyModule_AddObject(mod, "IRPC_CALL_TIMEOUT", PyInt_FromLong(IRPC_CALL_TIMEOUT));
  PyModule_AddObject(mod, "IRPC_CALL_TIMEOUT_INF", PyInt_FromLong(IRPC_CALL_TIMEOUT_INF));

+ + return mod;

}

</source>

Samba 4.7.0, вышедшая 21 сентября 2017 года, стала первой версией Samba, поддерживающей сборку модулей Python для версии Python 3.6. Это дало возможность полностью мигрировать на Python 3 и FreeIPA. Однако прежде чем, это произошло, нужно было перенести на Python 3 и ряд других проектов, написанных на Python.

Одним из наиболее сложных стал модуль поддержки работы с LDAP. Автор python-ldap принял решение полностью переписать модуль с нуля при переносе на Python 3, сделал его несовместимым с версией для Python 2, а также более соответствующим RFC, описывающим LDAP. Как результат, новая версия не только стала неудобной для миграции (требуется разный код для разных версий Python), но и просто не поддерживает работу с разнообразными реальными серверами LDAP, поскольку реальность достаточно серьезно расходится с академичностью оригинальных RFC. В результате, ряд пользователей оригинальной версии python-ldap сделали форк, который перенесли на Python 3, сохранив совместимость с предыдущей версией Python. Этот новый проект получил название pyldap.

Поскольку представление данных при передаче по сети у протокола LDAP базируется на правилах кодирования данных ASN.1, еще одним препятствием стала библиотека pyasn1. При переносе на Python 3 поведение некоторых ее компонент было изменено и привело к неработоспособности pyldap и других библиотек, используемых FreeIPA. Автор pyasn1, Илья Этингоф, активно помогал с миграцией и переписывал pyasn1 так, чтобы вернуть совместимость или улучшить код в других проектах.

Для того, чтобы успешно отслеживать изменения, ведущие к неработоспособности в той или иной версии Python, в процесс CI во FreeIPA были добавлены целевые тесты всего кода на соответствие Python 2.7 и Python 3.6, а также работоспособность как одной, так и второй версии. Также был добавлен тест устанавливаемости клиента средствами pypi — этот клиент активно применяется в OpenStack для автоматической регистрации машин во FreeIPA. Всё это увеличивает время тестирования каждого отдельного исправления (типичный тест среды с двумя репликами и одним клиентом занимает около получаса), но позволит сэкономить время в поддержке в будущем. Учитывая, что сам процесс миграции на Python 3 занял более трех лет, это достаточно важный фактор.

FreeIPA 4.6 стал первой версией с поддержкой Python 3. Эта ветка FreeIPA станет основной в дистрибутиве Fedora 27.

Примечания и ссылки

• Discuss on Facebook
• Discuss on VK

Plays:479   Comments:0