Bottle и плагины

Судя по всему — это производительность. Сами для написания API выбрали Falcon (из-за скорости) и у них как раз есть страница с бенчмарками — falconframework.org/#Metrics. Насколько это правда — это уж не знаю. Сами не гоняли.
Сами видите где там Flask, а где Bottle. Bottle не сильно проседает относительно Falcon, но более удобен.
И если не ошибаюсь у Flask-а нет такого типа плагинов, как в статье описывается.

Несколько интересных особенностей MySQL

Тогда разница в скорости какая-либо есть — между двумя раздельными и одним составным? Я на эту тему информации не видел.

Несколько интересных особенностей MySQL

Но тем не менее в пострегсе составные индексы есть или нет?

Несколько интересных особенностей MySQL

Да, с этим уже столкнулся и лично, но спасибо, что еще раз отметили.

Несколько интересных особенностей MySQL

Большое спасибо, буду разбираться.

Несколько интересных особенностей MySQL

Мне пока из первого, что бесило в MySQL — понравилась возможность добавления столбцов и индексов без table locking.
А то не редко бывали случаи, когда долбаный ALTER TABLE на > 1 млн. записей убивал весь продакшн на часы.
Не подскажите где посмотреть про «известные крутилки в базе»?
Т.к. в MySQL давно про всякие innodb_flush_method, atrx и прочее в курсе, а вот PostgreSQL в это плане пока темный лес. Хотелось бы высокий порог вхождения сделать менее шершавым :)

Несколько интересных особенностей MySQL

В том-то и проблема, что взял, попробовал и не понял надо оно мне или нет. Все немного не так, как раньше. "\dt", система пользователей… А явных плюсов уцепить за несколько дней использования не удалось.

Несколько интересных особенностей MySQL

Эта компиляция показывает как при некоторых запросах MySQL может вести себя странно. Лично я с такими проблемами ни разу не столкнулся до сих пор… Поэтому чтобы попробовать PostgreSQL хочется чего-то еще… Не видели какого-нибудь why to choose PostgreSQL?

Организация своего хоста виртуализации на Hetzner

Наверное имеется в виду, что openvz официально перестали поддерживать в штатном ядре Debian.

ah — лучше, чем history

Спасибо. Не нашел этого в документации на github-е.

Виртуальные ресурсы в Puppet

class virtual::users {
  @user { 'bob' :  ensure => present }
  @user { 'john' : ensure => present }
}

class someAction {
  file { '/home/bob/.bashrc' :
    ensure => present,
    require => User['bob']
   }
}

class anotherAction {
  file { '/home/john/.bashrc' :
    ensure => present,
    require => User['john']
  }
}

node 'testnode.example.com' {
  include virtual::users
  include someAction, anotherAction
  realize User['john'], User['bob']
}

Если ресурс не определить через realize/spaceship получите ошибку

Invalid relationship… because User['john'] doesn't seem to be in the catalog.

ah — лучше, чем history

Прекрасно, спасибо.
Подскажите как у вас работает garbage collecting? Оно удаляет все или что-то определенное? Просто сборка муссора ассоциируется с чем-то, что работает само в фоне и удаляет мусор по каким-то критериям :)

Виртуальные ресурсы в Puppet

Если приведете пример кода смогу прикинуть как это работает с виртуальными ресурсами. Пока не совсем понимаю какой фокус и почему не сработает.

Виртуальные ресурсы в Puppet

Видимо человека смущает то, что Puppet позволяет писать как absent, так и 'absent' и т.д. :)
Но для этого есть puppet style guide где просто четко сказано КАК писать. Есть puppet-lint, который можно прикрутить к vim через syntastic и получать это все в режиме реального времени.
Тоже не понимаю где проблема в общем.

Виртуальные ресурсы в Puppet

Нет, важно приводить примеры того, как это работает с другими погремушками. По крайней мере у меня теперь есть информация для размышления.
Спасибо.

Виртуальные ресурсы в Puppet

В моем случае я просто попросил разработчиков создать env переменную FACTER_serverID. Так как у нее префикс «FACTER_» она автоматически появляется у меня в puppet и я могу с нею работать $::serverID.
Еще делать описание самих нод я могу с помощью любого другого внешего скрипта. Поэтому я могу у себя в каком-нибудь биллинге прописать, что такой-то VPS надо поставить LAMP, puppet при подключении VPS запустит мой скрипт и я на лету сгенерирую ему описание ноды с включенным в нее mysql, apache и php. В ansible по-моему такого нет.

Виртуальные ресурсы в Puppet

Просто, к примеру, у одного заказчика парк серверов и начиная с какого-то момента часть из них ушла под определенный проект, в котором есть БД со списком этих серверов и у каждого сервера свой ID. Т.е. на хостнеймы я опираться не могу.
В зависимости от ID я должен предпринимать какие-то определенные телодвижение в puppet. Я просто добавил дополнительные факт someConcreteID, который мне присылает сам сервер. Выплевывает его PHP код проекта, мне даже не интересно как.
На Ansible как я понимаю я должен писать на Python-е какой-то код с urllib, который через GET запрос стучится в БД проекта, получает ID и начинает какие-то телодвижения. Т.е. решение есть но оно как мне кажется менее удобное.

Виртуальные ресурсы в Puppet

Мне сложно спорить, так как я пока не знаю ansible. Я, например, не совсем понял можно ли в ansible писать свои факты и модифицировать плагинами работу существующих модулей.

Виртуальные ресурсы в Puppet

Я в вашем примере одного не понял: зачем вводить виртуальные ресурсы?

В самом первом примере можно выкрутиться одним if-ом. Но данное решение совсем не scalable и в последующих примерах одним if-ом уже не отделаться.

Задачу можно решить без виртуальных ресурсов, в том числе и:

И делать include каждого такого класса-пользователя. Эффект будет точно таким же.

И эффект будет таким же, но сравните код:

class myUser {
    user { 'user1' : ensure => present }
}
class myUser2 {
    user { 'user2' : ensure => present }
}
class myUser3 {
    user { 'user3' : ensure => present }
}
class myUser4 {
    user { 'user4' : ensure => present }
}

node 'supernode.example.com' {
   include myUser4
   include myUser2

И вариант с виртуальными ресурсами:

class virtual::users {
    @user { 'user1' : ensure => present }
    @user { 'user2' : ensure => present }
    @user { 'user3' : ensure => present }
    @user { 'user4' : ensure => present }
}
node 'supernode.example.com' {
   include virtual::users
   #Подключаем только определенных пользователей
   realize User['user2'], User['user4']
   #Вместо 5 include-ов можем сделать так
   User <| |>

Виртуальные ресурсы в Puppet

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