Webzilla corporate blog
Comments 13
0
А как насчет протестировать всю цепочку целиком? Попробуйте

echo «ioc0: attempting task abort!» > /dev/kmsg

из-под рута.
0
Тут всё сложно — для того, чтобы тестировать «с помощью kmsg», нужно иметь поднятую связку dmesg->netconsole->logstash<-dns<-chief. А это много двигающихся частей, и сложная «тестовая конфигурация», которую поднимать только ради проверки «регэкспы не попортились» смысла нет.

Да и в чём смысл пересылать сообщение через ядро, когда stdin то же самое даёт, только с меньшими сайд-эффектами? (Да и netconsole есть только на linux, а часть сотрудников маками пользуется — там как быть?).
0
Ну я имел в виду скорее полноценное интеграционное тестирование. Проверить регексы — это хорошо. И их надо проверять при каждом изменении. Это юнит-тестирование.
Но ведь надо иногда проверять и всю цепочку целиком, что быть уверенным что ты действительно получишь алерт при таком вот конкретном сообщении от ядра.
0
Это предпродакшен стенд, и под него есть отдельный environment. Но переподнимать его по каждому чиху — очевидный оверкил.
0
" nova-compute (написана на python) не отвечает на heartbeat'ы. "

Вот поэтому мы и стали писать свое а не использовать опенстек — ввиду того что данный продукт фундаментально крив, а если какие-то проблемы выплывут — будут в первую очередь претензии к нам.

IBM как-бы наш конкурент, но очень правильно сами пишут

• OpenStack remains an emerging technology
• It is not mature yet
• Error handling not robust
• Understanding the flow of calls and messages is needed
• Large volume of message based rpc calls
• Logging is not optimal (either too much or too little)
• You must be willing to look at code
• Networking (nova-network) is complicated
• Multiple bridges
• IPTables configuration not straight forward
© IBM Corporation
+1
О да, вы нашли фатальный недостаток в чужом продукте. И только вы его можете устранить.

Nova используется в продакшене не менее чем парой сотен компаний (я за продакшен считаю только public self-serving) уже минимум три года.

Ту вы приходите и говорите, что вы сделаете лучше.

okay.jpg
+1
Недостаток далеко не один к сожалению, и даже не 100.

OpenStack сегодня это как Apache Web Server.

Жутко перегружен, крив до безобразия. Ситуация с сотнями / тысячами разработчиков (и компаний которые очень хотят денег) — рак / лебедь /щука.

Потом пришел Сысоев и сделал все (nginx) как надо.

Насчет «сделаете» — сделали уже. Статья была тут на хабре но пришлось ненадолго выключить по ряду политических причин.
+1
Скажите, вы его дальше маркетинга смотрели? Из всего опенстека keystone и nova — самые сильные компоненты (свифт не знаю, им другие люди занимаются), neutron тащится в отдалении.

К nova (при правильном планировании инфраструктуры) у меня лично комплект претензий микроскопический, в основном связанный либо с багами в edge cases (да, разумеется, баги в чужом ПО — это Фатальный Недостаток), либо с желанием как нибудь так исхитриться, чтобы и на ёлку влезть и ресурсов не потратить.

Насчёт «You must be willing to look at code» — я не верю в существование крупного проекта без этого.

А ваше исправление Фатального Недостатка подразумевает, что никому на этот код смотреть лучше не надо не придётся?
0
Уважаемый автор
а можно как нибудь увидеть список вот этих волшебных строк ЦЕЛИКОМ?

[message] =~ /ioc0: attempting task abort!/ or
[message] =~ /mptbase: ioc0:.+Code=\{Abort\}/ or
[message] =~ /Device offlined/ or

ну и с разбором кейсов… что откуда взялось?
0
Я попробую собрать. Начиная с определённого момента у нас для каждого сообщения полная строка и линк в багтрекере, но комплекты более ранних просто добавлялись по возникшим ситуациям.
0
Знаете это было бы офигенно даже хотя бы просто сам список куда нибудь на gist.github.com скопипастить =)
а если с разбором кейсов, то вообще очень круто
0
Ну, тут надо понимать, что делаем мы их под себя — чуть-чуть меняется железо, и комплект сообщений от других драйверов и совсем другой. А реакция на все сообщения с приоритетом ERROR/critical — откровенный перебор. На dell'овых серверах, например, можно получить «ошибку чтения» с CD-привода (виртуального, через IPMI) — и всем на неё пофигу. А у кого-то это может быть бизнес-критикал сообщение.

Например, kvm пишет как ошибку действия гостей: kvm [12599]: vcpu0 unhandled wrmsr: 0x682 data 0, хотя ничего такого это не означает. Просто реагировать на все error от ядра не стоит. Более того, местами имеет смысл реагировать на debug/info (флап интерфейса, который не должен флапать), и всё это исключительно business specific.

Так что имеет смысл это всё делать под конкретную инсталляцию.
Only those users with full accounts are able to leave comments. , please.