мы добрые

мы добрые

не не не, я раз на такое уже купился по молодости

кстати, что не так с хазелкастом?

кстати, что не так с хазелкастом?

детская травма

его неправильно использовали, но виноваты были админы

ну ок

https://jepsen.io/analyses/hazelcast-3-8-3

там был сакс с мультикаст дискавери

ну и 14 год на дворе

https://jepsen.io/analyses/hazelcast-3-8-3

Тю, написали ему же ответ

лол что

ну и 14 год на дворе

ага, не первый раз такое встречаю

чинить баги ответами - это, конечно, лучший вариант

чинить баги ответами - это, конечно, лучший вариант

https://blog.hazelcast.com/jepsen-analysis-hazelcast-3-8-3/

Я это все читал, только там локи не локи. Каким образом мне поможет очередной классический ответ очередного СТО, который и так под каждым постом кайла висит, на которые он так же упорно отвечает "ребят, у вас все равно не работает"?

никак

Я не продовал CTO

С разрабами разговоры разговаривал

кстити, если CTO знает про кайла, то с таким даже приятно поговорить бывает

Так что все ок

Я все пытаюсь донести мысль, что сколько не пиши ответы на провалы в тестах и не разговаривай с разрабами, неработающая машина от этого работающей не станет

я не умею в хазелькаст (и вообще ничего о нем не знаю), но насколько я помню (поправьте меня, если я неправ), Кайл проверяет лишь то что софт ведет себя так как сам же и обещает. и если принять это как данность, то возможны два варианта: 1) Кайл долбоеб и не разобрался 2) Разработчики пиздаболы и софт ведет себя действительно не так, как обещает. Кайл, с моей точки зрения, отнюдь не долбоеб.

я не умею в хазелькаст (и вообще ничего о нем не знаю), но насколько я помню (поправьте меня, если я неправ), Кайл проверяет лишь то что софт ведет себя так как сам же и обещает. и если принять это как данность, то возможны два варианта: 1) Кайл долбоеб и не разобрался 2) Разработчики пиздаболы и софт ведет себя действительно не так, как обещает. Кайл, с моей точки зрения, отнюдь не долбоеб.

тонко зашел

Well. зато он Кафку хвалит

так что мне ок

Кажется, мой пассаж про то, что инструменты определяются не личным отношением, не зашел

Кажется, мой пассаж про то, что инструменты определяются не личным отношением, не зашел

На самом деле нет

Кажется, мой пассаж про то, что инструменты определяются не личным отношением, не зашел

это тебе они определяются не личным отношением :)

а кому-то - люблю перл, нимагу

Иногда инструменты определяются именно личным предпочтением

поэтому много где хазелкаст заходил где Gridgain не заходил

потому что на бумаге на GG были фичи, а по факту не очень они работали

я не умею в хазелькаст (и вообще ничего о нем не знаю), но насколько я помню (поправьте меня, если я неправ), Кайл проверяет лишь то что софт ведет себя так как сам же и обещает. и если принять это как данность, то возможны два варианта: 1) Кайл долбоеб и не разобрался 2) Разработчики пиздаболы и софт ведет себя действительно не так, как обещает. Кайл, с моей точки зрения, отнюдь не долбоеб.

Солженицина не читал ©, ага. Кайл проверяет consistency и data safety.

Пастернака

Солженицина не читал ©, ага. Кайл проверяет consistency и data safety.

Кайл проверяет соответствие поведения документации

И претензии были про то что в доках не пойми что

Тупо же в статье последний абзац: These problems are not bugs; they are fundamental design decisions. Hazelcast has placed sequential or linearizable datatypes atop an eventually-consistent replication system which makes unjustifiably optimistic assumptions about node and network reliability. Jepsen has not filed specific bug reports for these issues with Hazelcast; instead, we feel that a comprehensive re-evaluation of Hazelcast’s documentation, datatypes, and replication algorithms is in order.

Ну поглядим как исправят

я уж как полгода на Hazelcast не глядел

О, раз мы тут про кубер

а хазелкаст под кубером пробовал заводить?

Ну поглядим как исправят

Пост-ответ и был о том что "да, у нас лажа в документации, в 3.9 поправим"

https://blog.hazelcast.com/hazelcast-imdg-3-9/ - вышел в октябре

из ответочки: We agree making the contract explicit, with warnings on what can happen to the JavaDoc, is important. We have been adding these over the last few weeks in time for the 3.9 release which is expected at the end of October.

Ребят, читаю вот это https://cloud.google.com/kubernetes-engine/ я правильно понимаю, что при использовании GKE вся имплементация от меня отгорожена KubeAPI и если я например хочу но kube ноду что-то свое поставить, ну какой нибудь netdata для мониторинга, то у меня это уже не получится кроме того мои Pods в GKE будут крутиться на том же физическом железе что и Pods других клиентов?

когда я с этим игрался, создавались машины в GCE (Google Compute Engine), на которые можно было зайти по ssh; насколько понимаю, вне них держится только etcd (скорее всего кто-нибудь это уточнит); другое дело, что я совершенно точно не знаю, как производится апгрейд (не введением ли совершенно новой машины)

ок, спасибо ну апгрейд в таком случае да, введение новой машины если без даунтайма а когда заходил по ssh там внутри какой дистрибутив? RPM based или DEB based? или можно выбрать?

Таких настроек не припомню, просто при создании кластера кубернетеса магически поднимаются уже сконфигурированные машины

#whois : ИП, Neural Networks & Deep Learning, AWS, GCP. Специалист по автоматизации, микросервисам, Docker и Kubernetes. Сообществу могу быть полезен знаниями и в качестве работодателя. Сообщество интересно в первую очередь контактами правильных инженеров, во вторую в качестве источника дополнительных знаний. В настоящее время нахожусь в Москве. P.S. Правила прочел.

когда я с этим игрался, создавались машины в GCE (Google Compute Engine), на которые можно было зайти по ssh; насколько понимаю, вне них держится только etcd (скорее всего кто-нибудь это уточнит); другое дело, что я совершенно точно не знаю, как производится апгрейд (не введением ли совершенно новой машины)

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

$ kubectl get deploy --no-headers ghc-bome 1 1 1 1 3m $ kubectl get all --no-headers deploy/ghc-bome 1 1 1 1 3m rs/ghc-bome-2039839483 1 1 1 3m deploy/ghc-bome 1 1 1 1 3m po/ghc-bome-2039839483-30c45 1/1 Running 0 3m Викторина: почему во втором случае два деплоймента?

А кто сказал что деплоймента два?

get all же

Один деплой, одна реплика, и один под. Всё вроно так как и должно быть

Ну так..ты извлекаешь все сущности (почти все -)) Ключевым словом all

ладно, намекну поподробнее: $ kubectl get all --no-headers | grep deploy | wc -l 2

И эти сущности 3. Деплой Реплика и Под

Ein deploy, ein replica, ein pod прям

-)

Ребят, читаю вот это https://cloud.google.com/kubernetes-engine/ я правильно понимаю, что при использовании GKE вся имплементация от меня отгорожена KubeAPI и если я например хочу но kube ноду что-то свое поставить, ну какой нибудь netdata для мониторинга, то у меня это уже не получится кроме того мои Pods в GKE будут крутиться на том же физическом железе что и Pods других клиентов?

ноды это простые компьют инстансы убунты или кореос, можно зайти по ssh и сделать что угодно

Максим, во втором (там, где all) случае 4 сущности, две из них — деплоймент.

ERROR: S client not available

Я сначала решил, что первый доплой относит к строке вызова.

Перенос строки меня подловил

ну конечно же нет, иначе зачем бы я спрашивал

ну не что угодно конечно, но чтото можно )))

когда я с этим игрался, создавались машины в GCE (Google Compute Engine), на которые можно было зайти по ssh; насколько понимаю, вне них держится только etcd (скорее всего кто-нибудь это уточнит); другое дело, что я совершенно точно не знаю, как производится апгрейд (не введением ли совершенно новой машины)

по дефолту в GKE ноды создаются под Chrome OS, в kops (aws) - деб. Но доступа к мастеру нет, более того, через kubectl не видно вообще никаких компонентов, которые принадлежат мастеру. Т.е. доступ к нодам эксклюзивно.

а что он соорудит при хедерах?

Максим, для all?

f[f

аха

с деплоем всё понятно, прочто хочу посмотреть как оно его разобъёт

$ kubectl get all NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deploy/ghc-bome 1 1 1 1 14m NAME DESIRED CURRENT READY AGE rs/ghc-bome-2039839483 1 1 1 14m NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deploy/ghc-bome 1 1 1 1 14m NAME READY STATUS RESTARTS AGE po/ghc-bome-2039839483-30c45 1/1 Running 0 14m

оч интересно-)

удалить/создать не помогает, сто раз пробовал

на это issue даже есть: https://github.com/kubernetes/kubectl/issues/167

Всем привет

Ребзя, если взять кореос+кубернет+аппАрмор+докер

Я могу уверенно отдавать доступ к докеру сторонним людям, не рискуя быть взломанным?

Запуск образов или самих программ внутри докера

Я могу уверенно отдавать доступ к докеру сторонним людям, не рискуя быть взломанным?

Можно быть уверенным только в том, что нельзя быть ни в чем уверенным

Вы доступ к докеру или к кубернетесу давать посторонним хотите?

Я хочу разрешить запуск чужих программ внутри системы

Хочу но боюсь

Или может даже образов

А вот с этим кто-нибудь работал? https://github.com/clearcontainers

http://www.opennet.ru/opennews/art.shtml?num=47252

А вот с этим кто-нибудь работал? https://github.com/clearcontainers

Из переименовали в kata containers. Они только начали.

Приходите через год.

Учитывая последние просчёты intel я бы не доверял их секурным начинаниям )))

??

Так и думал что кто-нибудь про это пошутит