ошибка подкоманды dcos cassandra

Я в команде, которая создает сервис Cassandra. Спасибо, что попробовали!

Мы только что обновили пакет CLI Cassandra, чтобы лучше определить его зависимости от pip. В вашем случае похоже, что он пытался повторно использовать старую версию библиотеки requests? Чтобы запустить модуль Cassandra CLI до последней версии, попробуйте запустить dcos package uninstall --cli cassandra; dcos package install --cli cassandra. Обратите внимание, что --cli важен; его отсутствие может привести к удалению самой службы Cassandra, в то время как все, что нам нужно, это переустановить локальный модуль CLI.

Имейте в виду, что вы также должны иметь доступ к службе Cassandra напрямую через HTTP. Модуль CLI фактически представляет собой тонкий интерфейс для HTTP API службы. Например, curl -H "Authorization:token=$(dcos config show core.dcos_acs_token)" http://<your-dcos-host>/service/cassandra/v1/plan | jq '.'. См. curl примеры в документации Cassandra 1.7 для других конечных точек.

После того, как вы запустили и запустили CLI, это должно дать более полное представление о состоянии службы, но журналы могут предоставить более подробную информацию, особенно если служба не запускается. Вы можете получить доступ к журналам службы напрямую, посетив панель управления по адресу http://<your-dcos-host>/:

1. Нажмите Services слева, затем выберите marathon из списка. Менеджер службы Cassandra запускается как задача Marathon.
2. Появится панель со списком всех задач, которыми управляет Marathon. Щелкните cassandra в этом списке, чтобы отобразить его рабочий каталог, включая доступные файлы журналов.
3. При наведении курсора на файлы появляется увеличительное стекло. Щелкните увеличительное стекло, чтобы отобразить соответствующий файл в строке.

К сожалению, у нас все еще есть та же проблема, хотя нам удалось найти обходной путь. Похоже, что с DC/OS в Azure существует несколько различных проблем, но в любом случае я предоставлю дополнительный отзыв. Если вы используете версию DC/OS 1.7.0 из Marketplace, Cassandra не развертывается, она застревает в Marathon на этапе 1/2, при проверке журналов у нее возникает проблема с доступом к портам по умолчанию.

Вставить в файл журнала

С другой стороны, эта проблема не возникает в ACS DC/OS, развертывание Cassandra правильно отображается на вкладке «Служба DC/OS», а также в Marathon. CLI DCOS Cassandra не работает ни на одном из них. При не очень тщательном осмотре кажется, что когда мы устанавливали CLI DCOS с использованием метода, описанного выше, есть некоторые проблемы с зависимостями, особенно с учетом переменной $PYTHONPATH.

/opt/mesosphere/lib/python3.4/site-packages

Мы смогли решить проблему зависимостей, выполнив два действия:

• Первая проблема с зависимостями была связана с модулем запросов, которая была решена с помощью следующих действий после установки cli для подкоманды Cassandra.

  cd ~/.dcos/subcommands/cassandra
  source env/bin/activate
  pip install -Iv requests
  

Мы использовали -Iv, так как обычная процедура обновления завершается с ошибкой из-за внешней зависимости в пути $PYTHONPATH, поэтому зависимость запросов решена.

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

  pip install -Iv docopt
  

Это кажется немного хакерским, интересно, есть ли что-нибудь более подходящее, чтобы сделать.

вывод соединения dcos cassandra после выполнения вышеуказанных шагов

{
"address": [
    "10.32.0.9:9042",
    "10.32.0.6:9042",
    "10.32.0.8:9042"
],
"dns": [
    "node-0.cassandra.mesos:9042",
    "node-1.cassandra.mesos:9042",
    "node-2.cassandra.mesos:9042"
]
}

То же самое происходит и с другими подкомандами DC/OS, такими как, например, команда Kafka.