Puppet не обновляет пакет после изменения репо

Согласно https://docs.gitlab.com/runner/install/linux-repository.html#upgrading-to-gitlab-runner-10 репозитории изменились, поэтому мы пытаемся обновить gitlab-runner всех узлов. Нам нужно удалить старое репо и добавить новое, а затем обновить пакет.

В нашем манифесте марионетки [1] мы обновляем репозиторий, проверяем наличие последней версии пакета, и после этого обновления мы должны запустить сценарий, прежде чем убедиться, что служба запущена. Наша проблема в том, что мы должны запускать этот скрипт только после обновления.

Прямо сейчас, даже если репо обновлено, пакет - нет. Пакет обновляется только при запуске distro_sync или при запуске «yum update gitlab-runner», а не при запуске марионетки. Кажется, что пакет никогда не обновляется, как если бы он проверял последнюю версию старого репо вместо сравнения с недавно добавленным репо.

[1]

# Installs a GitLab-CI runner for CERN GitLab
class gitlab::gitlab_ci_runner (
  String $ensure = 'latest', # passed to the gitlab-runner package. Can be used to force a version
) {
  ensure_resource('yumrepo', 'gitlab-runner', {
      descr    => 'gitlab-runner for EL6/7',
      baseurl  => "http://packages.gitlab.com/runner/gitlab-runner/el/${::operatingsystemmajorrelease}/${::architecture}",
      gpgcheck => 0,
      enabled  => 1,
      exclude  => absent,
  })

  ensure_packages(['gitlab-runner'], {
    ensure  => $ensure,
    require => Yumrepo['gitlab-runner'],
  })

  exec {"post-install":
    command => 'sudo /usr/share/gitlab-runner/post-install',
    provider => shell,
    onlyif  => 'test -e /usr/share/gitlab-runner/post-install',
    refreshonly => true,
    subscribe => Package['gitlab-runner'],
  }

  service { 'gitlab-runner':
    ensure  => running,
    enable  => true,
    require => [Package['gitlab-runner'], Exec["post-install"]]
  }

}

person djuarezg    schedule 10.10.2018    source источник
comment
Вероятно, это связано с тем, что ensure => <value> оценивается предварительной выборкой ресурсов, поэтому метаданные репозитория для последней версии обрабатываются до приложения каталога. Следовательно, изменение подписки репо не влияет на ensure => latest ресурса пакета, как это происходит во время приложения после предварительной выборки. Хотя это очень вероятно, я не могу однозначно сказать, что это так, поэтому оставляю это как комментарий.   -  person Matt Schuchard    schedule 10.10.2018
comment
@MattSchuchard Именно в этом и заключалась проблема: указание версии действительно работало. Вы знаете, есть ли способ обновить метаданные? В любом случае, пожалуйста, дайте это объяснение в качестве ответа.   -  person djuarezg    schedule 10.10.2018
comment
Не лучший обходной путь, но если он обновляет пакет до последней версии в последовательном приложении каталога, тогда моя теория с большей вероятностью будет правильной. Хорошо, ничего, я только что нашел исходный код, чтобы проверить свою теорию.   -  person Matt Schuchard    schedule 10.10.2018
comment
Не могли бы вы связать исходный код? В любом случае да, последовательные запуски марионетки работают должным образом, поэтому я бы сказал, что это обходной путь, если нет какого-либо способа принудительного обновления.   -  person djuarezg    schedule 10.10.2018


Ответы (1)


Причина, по которой вы наблюдаете такое поведение, заключается в том, что марионетка предварительно выбирает метаданные репозитория для ресурса пакета перед применением ресурсов в каталоге. Обратите внимание на соответствующий исходный код для текущего состояния исходного кода здесь для yum и здесь для общего провайдера. Обратите внимание, что широкая функциональность связанного кода не изменилась с течением времени, поэтому, хотя тонкости могут измениться, общее поведение изменилось / не изменится.

В связи с этим определение latest версии пакета происходит до применения ресурса. Следовательно, в вашей ситуации репозитории, на которые вы подписаны при компиляции каталога, будут определять latest версию пакета. Изменение подписки на репозиторий во время применения каталога не повлияет на поведение ensure => latest.

Как вы, вероятно, догадались, обеспечение того, чтобы конкретная версия по-прежнему имела желаемый эффект, поскольку он будет использовать новый репозиторий и не будет предварительной выборки ресурсов для latest (другая предварительная выборка все еще выполняется). В качестве альтернативы, последовательное применение каталога будет иметь желаемый эффект для ensure => latest. Подводя итог, ваши варианты обхода здесь следующие:

  • Дважды последовательно примените каталог Puppet.
  • ensure => <version> где вы указываете точную версию или выпуск версии, например 10.0.5-el7.

Как и следовало ожидать, отличным дополнительным источником информации о предварительной выборке ресурсов является статья в блоге Гэри здесь. Прокрутите вниз до заголовка, который начинается с «Предварительная выборка, очистка, кеширование и прочее». Обратите внимание на обычное предостережение о том, что в блоге Гэри "ненормативная лексика". Официальная документация к нему по сути бесполезна.

person Matt Schuchard    schedule 10.10.2018
comment
Применение марионетки дважды не приводит к обновлению пакета, а только гарантирует, что версия обновляется (с помощью sl6). - person djuarezg; 10.10.2018
comment
Я запутался, @djuarez. В предыдущем комментарии к самому вопросу вы, кажется, сказали, что выполнение двух последовательных запусков привело к выполнению обновления пакета. Однако здесь вы, похоже, противоречите предыдущему комментарию. Я бы очень ожидал, что если один запуск успешно обновит конфигурацию репозитория, то второй, который гарантирует, что ваши пакеты будут последними, применит любое соответствующее обновление пакета. Если на самом деле этого не происходит, то у вас должно быть что-то более тонкое, возможно, за пределами самого Puppet. - person John Bollinger; 11.10.2018
comment
1- Запустите с помощью sure = ›‹version› 2- sure =› 'latest'. Это гарантирует любое обновление. Запуск дважды с помощью sure = ›‹version› не работает, извините за недоразумение. - person djuarezg; 11.10.2018