Пара багов (или фич?), которые я умудрился найти в GCP

Раз уж приходится в последнее время работать с Deployment Manager из Google Cloud Platform, то как-то тяжело не заметить, что гугл иногда…  делает баги. Серьёзно. Не то, чтобы очень много, я определённо сделал больше, но достаточно, чтобы время от времени сталкиваться с чем-то загадочным. За последний месяц я их нашёл штуки четыре. Ещё что-то нашли мои товарищи по проекту, так что баги действительно есть. Вот, например, что мне попалось.

Deployment Manager и Cloud Functions

‘v1beta2’ или всё-таки ‘v1’?

На заре карьеры один товарищ как-то рассказал, в чём заключается разница между багом и фичей: «Если штука задокументирована, то это фича. А если нет — то баг». С таким определением следующая находка — определённо баг.

Если вы начнёте искать, какой тип ресурса нужно использовать, чтобы создать облачную функцию (она же lambda в AWS, она же serverless в жизни) с Deployment Manager, то скорее всего наткнётесь на cloudfunctions.v1beta2.function. Можно даже посмотреть доступные типы с gcloud deployment-manager types list, или сходить в документацию, и убедиться, что ответ действительно правильный.

Или всё-таки нет? Есть ещё одна страничка в документации, согласно которой v1beta2 уже очень устарел, и пользоваться нужно исключительно v1.

Проблема в том, что гугловый же DM абсолютно ничего не знает о v1.function. Я проверил везде, даже в сам гугл запрос отправлял. Нет такого. Если попробовать скормить v1  насильно, то DM ругнётся на неизвестный тип и свалится. В общем, печаль.

Хотя оно и не особо проблема, это всё-таки и неудобство, ведь придётся использовать заведомо устаревший апи, который уходит в Валгаллу уже в декабре, и который к тому же не полностью совместим с новым. Придётся ставить будильник и раз в неделю проверять, действительно ли v1 уже доступен, или как всегда.

Мистика Nodejs 8 билдов

От второй ошибки мой мозг немного взорвался.

В общем, написал я шаблон, который разворачивал жаваскриптовую Cloud Function через Deployment Manager и Cloud Build API. После того, как шаблон стал работать как часы, я решил написать и юнит тест для него, и вот в этом моменте начались проблемы. Тот самый шаблон, который работал безошибочно, в юнит тесте уже валился процентах в семидесяти случаев. Как..?

ОК. Спустя некоторое, потраченное на мат и недоумение, время, я всё-таки заметил, что параметры шаблона для юнит теста хоть немного, но отличаются от «эталонного». Прикол в том, что Cloud Functions могут использовать разный рантайм, и по умолчанию они идут с nodejs6. Для тестов же я включил nodejs8 — проверить передачу параметров и т.п. Всё равно там hello-world приложение, какая ему разница.

Лажа в том, что nodejs8 в гугле до сих пор ходит в бетах, и видимо это настолько бета, что ей можно запросто свалить DM. Но не всегда. Почему — без понятия. Но все проблемы ушли, как только я поменял 8 на 6.

Deployment Manager и Dataproc.

Не удаляй тот сервисный аккаунт!

Гугловый Dataproc, по сути, обычный Hadoop кластер, живущий на виртуалках из Google Compute Engine. И то, и другое обкатано годами, так что чему там ломаться.

Ну-у-у…

Вот в чём прикол. Dataproc’у нужны два сервисных аккаунта, чтобы нормально работать. Оба, насколько я помню, идут по умолчанию и пермишенов обоим тоже хватает. Но не в моём случае. Мы надругали свой дефолтный аккаунт, прав доступа ему не хватало, так что я создал новый, дал ему Dataproc.Worker роль, случайно накосячил в процессе, удалил бедолагу, создал снова и, наконец, подал на вход Dataproc кластеру. Но тот почему-то всё равно был недоволен:

То есть как это? Я же вот только что дал тебе Worker роль. И имя правильное. Акей, иногда IAM роли и права обновляются не сразу, так что стоит пару минут подождать и попробовать снова. Но даже подождав пять минут и убедившись через командную строку и гугловую консоль, что у аккаунта с его правами нет никаких проблем, я так и не смог поднять Dataproc.

В общем, воспользовавшись гуглом по назначению, я нашёл-таки интересное описание бага, который проявляется так: удали сервисный аккаунт, создай его снова, а Dataproc не будет видеть его ролей. В общем, всё как у меня. Добавив цифру 2 в имя аккаунта, проблема решилась мгновенно.

И лучше бы деплойменту завершиться хорошо

Наконец, я слажал с Dataproc ещё дважды, за один подход. Во-первых, создал огроменный Deployment Manager шаблон, который разворачивал Dataproc кластер со своими сервисными аккаунтами, новой сетью и правилами для файрвола в один присест. Только вот пару правил для файрвола я всё-таки попустил, так что машины к кластере общаться между собой не смогли бы. Мне-то что, исправил бы и всего делов. Но для Deployment Manager’а, оказывается, развернуть такой невалидный кластер — трагедия. Он ушёл в какой-то полубесконечный цикл ожидания того, когда Dataproc доделается, чего, естественно, никогда бы не произошло в поломанной сети. Я было попробовал удалить этот деплоймент, но безуспешно. Наконец, через полчаса какой-то таймаут таки сработал, и деплоймент упал.

Правда, нарисовалась следующая проблема. Деплоймент всё ещё нельзя было удалить. Он падал с каким-то race condition при удалении сервисного аккаунта и даже ручное удаление оного ему не помогло.

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

Мораль

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