Повсеместная телефонная связь посредством станций, можно связаться с любым абонентом в мире. Не понимаю, чего нового дала нам сотовая связь, чтобы нужно было это особо фантастически предсказывать.
Из того, что приходит в голову похоожего — скажем, умная пыль вполне себе была предсказана :)
А что такого в них особенного? Чем АТС телефонной связи начала XX-го века отличается от базовой станции сотовой связи начала XXI-го, кроме технологий физического подключения?
Как раз потому пишу, что логичность и стройность ведь сейчас закладываете :)
Фик с ним с амазоном, тащемта, лишь бы shell-обвязка была, навроде supload.
Насчет лимитированных операций — я опишу use case со своей точки зрения.
1. Компания с одним аккаунтом на Selectel занимается разработкой и хостингом многих веб-проектов.
2. Каждый проект включает в себя 1-2 постоянно включенных сервера (типа, 24/7 продакшен + в рабочее время общий dev) плюс что-нибудь вроде ночной сборки, которая включает в себя создание и уничтожение сервера или их набора.
3. Для каждого проекта сервера создаются и конфигурируются полностью автоматически, т.е. ваше API — наше все. Все это заворачивается в скрипты, джобы, права на которые раздаются внутри компании, ручная работа минимальна. Как раз недавно в этом ключе писали про Jenkins.
Для меня как для одмина всего аккаунта было бы приятнее всего завести подаккаунт для каждого проекта, который бы мог рулить своими облачными ресурсами в следующих пределах:
1. Создавать сервера (доступные по умолчанию только для этого подаккаунта), с ограничением, что не более N серверов всего может быть активно на подаккаунт (чтобы создавалка не зациклилась ночью).
2. Управлять своими серверами (вкл, reset).
3. Деструктивные операции (жесткий poweroff, удаление) — по умолчанию можно. Но, если из джоба создали продакшн, то потом для конкретного инстанса хочется руками из из админки запретить деструктивные операции, чтобы его потом другой джоб не мог снести даже по ошибке.
Теоретически также может захотеться наоборот какому-то подаккаунту ручками надавать прав на сервера, которые он не создавал в соответствии с п.1.
Как-то так. Спасибо, что дочитали. Публикуйте API, посмотрим конкретнее :)
Тут вот какая штука — хотелось бы уметь из тулзов создавать новые сервера и полностью их настраивать. Это подразумевает операцию «создать сервер» в админке облака (сейчас руками). Как бы сделать так, чтобы можно было и это скриптом делать?.. Положим, хочу, запаковать все развертывание в jenkins job или что-то подобное, по одной кнопке чтоб.
И в то же время не хотелось бы в эти тулзы закладывать credentials от всего селектель-аккаунта, т.к. проектов там много.
А дальше так: я права на этот job даю разработчикам и одминам этого проекта — и они спокойно рулят своими серверами на общем аккаунте компании.
А > 1 сервера на проект — это более чем частотный случай, взять хотя бы dev/prod.
А вот еще вопрос: планируется разделение прав по серверам?
Положим, я хочу в одни тулзы положить один auth токен для одного проекта (пусть создает и рулит своими серверами, и только), а в другие тулзы — другой токен. Вобщем, по аналогии с хранилищем.
Во-во. По-моему, они столько вещей делают правильно, что не пройдет и пары лет, как они зохавают мир. Танки, корабли, самолеты, исторический реализм, общий мир, стратегия на картах, видюхи, мультики, трансляции игр с разрабами (!), книги по истории техники, сувенирка… Не говоря о том, что игра за 2 года жизни уже квалифицировались в качестве дисциплины на WCG (!!)
Из того, что приходит в голову похоожего — скажем, умная пыль вполне себе была предсказана :)
wat.
Фик с ним с амазоном, тащемта, лишь бы shell-обвязка была, навроде supload.
Насчет лимитированных операций — я опишу use case со своей точки зрения.
1. Компания с одним аккаунтом на Selectel занимается разработкой и хостингом многих веб-проектов.
2. Каждый проект включает в себя 1-2 постоянно включенных сервера (типа, 24/7 продакшен + в рабочее время общий dev) плюс что-нибудь вроде ночной сборки, которая включает в себя создание и уничтожение сервера или их набора.
3. Для каждого проекта сервера создаются и конфигурируются полностью автоматически, т.е. ваше API — наше все. Все это заворачивается в скрипты, джобы, права на которые раздаются внутри компании, ручная работа минимальна. Как раз недавно в этом ключе писали про Jenkins.
Для меня как для одмина всего аккаунта было бы приятнее всего завести подаккаунт для каждого проекта, который бы мог рулить своими облачными ресурсами в следующих пределах:
1. Создавать сервера (доступные по умолчанию только для этого подаккаунта), с ограничением, что не более N серверов всего может быть активно на подаккаунт (чтобы создавалка не зациклилась ночью).
2. Управлять своими серверами (вкл, reset).
3. Деструктивные операции (жесткий poweroff, удаление) — по умолчанию можно. Но, если из джоба создали продакшн, то потом для конкретного инстанса хочется руками из из админки запретить деструктивные операции, чтобы его потом другой джоб не мог снести даже по ошибке.
Теоретически также может захотеться наоборот какому-то подаккаунту ручками надавать прав на сервера, которые он не создавал в соответствии с п.1.
Как-то так. Спасибо, что дочитали. Публикуйте API, посмотрим конкретнее :)
И в то же время не хотелось бы в эти тулзы закладывать credentials от всего селектель-аккаунта, т.к. проектов там много.
А дальше так: я права на этот job даю разработчикам и одминам этого проекта — и они спокойно рулят своими серверами на общем аккаунте компании.
А > 1 сервера на проект — это более чем частотный случай, взять хотя бы dev/prod.
А вот еще вопрос: планируется разделение прав по серверам?
Положим, я хочу в одни тулзы положить один auth токен для одного проекта (пусть создает и рулит своими серверами, и только), а в другие тулзы — другой токен. Вобщем, по аналогии с хранилищем.
«— Спасибо, что не забывате научный отдел. Я уже отправила новичков в лабораторию» — мимими.