| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-15 | |||
| 15:34:42 | sean-k-mooney | so for me l1 is simulating a cloud and l2 is my test workload | |
| 15:34:51 | sean-k-mooney | and yes but not with tripleO | |
| 15:35:13 | MarkMielke | tripleO doesn't even mean tripleO anymore, right? doesn't it mean OpenStack on K8? haha | |
| 15:35:26 | sean-k-mooney | not yet | |
| 15:35:43 | sean-k-mooney | but yat they are slowlow dismanteling the undercloud | |
| 15:36:04 | sean-k-mooney | personally i much prefer kolla-ansible or OSA | |
| 15:36:13 | MarkMielke | me too | |
| 15:36:14 | sean-k-mooney | triplo is too complicated | |
| 15:36:29 | sean-k-mooney | and has too much techdebt in all its layers | |
| 15:36:45 | MarkMielke | it's somewhat purist without regard to consequences | |
| 15:37:02 | MarkMielke | my view :-) | |
| 15:37:26 | sean-k-mooney | im not sure i would agree. i think it use to be more pure and simple | |
| 15:37:42 | sean-k-mooney | and now with contariation its less pure and more complicated | |
| 15:38:51 | sean-k-mooney | lucally while i have to debug customer systems ocationally (mainly via logs) i dont actuly need to use triplO day to day | |
| 15:39:16 | MarkMielke | Kayobe is the one that was appealing to me | |
| 15:39:22 | MarkMielke | Ironic in stand-alone mode | |
| 15:39:23 | MarkMielke | Kolla | |
| 15:39:26 | MarkMielke | Ansible | |
| 15:39:43 | sean-k-mooney | yep when i work at intel i pitched basically what they implemented internlaly | |
| 15:39:59 | sean-k-mooney | i wrote the original kolla biforst container | |
| 15:40:03 | MarkMielke | cool | |
| 15:40:50 | sean-k-mooney | i really wanted to see koll ansibel become the default openstack installer but i dont really work on the installer anymore | |
| 15:42:25 | MarkMielke | I think it will pick up. | |
| 15:42:48 | sean-k-mooney | if kaobe does then yes | |
| 15:42:59 | sean-k-mooney | *kayobe | |
| 15:43:00 | MarkMielke | It's so much simpler. | |
| 15:43:04 | sean-k-mooney | yep | |
| 15:43:12 | sean-k-mooney | its simple to debug and extend | |
| 15:43:34 | sean-k-mooney | the config overrde mechanisum is easy to use | |
| 15:43:40 | sean-k-mooney | and no puppet/ruby | |
| 15:43:46 | sean-k-mooney | which is defintly a win | |
| 15:43:48 | MarkMielke | Running Kubernetes on hypervisors seems overly complex to me personally. It's not really the right use case for it. | |
| 15:44:14 | MarkMielke | If you were running Docker containers - sure... but virtual machines from within Nova/libvirtd/qemu? I don't think so. | |
| 15:44:33 | sean-k-mooney | the last thing i was trying to push in kolla before i stope working on it was move to running the contaienr using systemd service file | |
| 15:44:50 | sean-k-mooney | so that tehre was a determinisitc order to them on host reboot | |
| 15:45:05 | MarkMielke | the move away from "Docker" may help with that :-) | |
| 15:45:20 | sean-k-mooney | what are they moving too | |
| 15:45:20 | MarkMielke | podman, etc. | |
| 15:45:24 | sean-k-mooney | ah ok | |
| 15:45:35 | sean-k-mooney | ya podman now create the unit file for you | |
| 15:45:38 | MarkMielke | RHEL 8 pushing that hard | |
| 15:45:40 | sean-k-mooney | in the lates version | |
| 15:45:47 | MarkMielke | doesn't come with Docker even in Extras. :-) | |
| 15:45:50 | sean-k-mooney | not as much as you would think | |
| 15:46:24 | sean-k-mooney | well docker yes | |
| 15:46:37 | MarkMielke | we didn't move up to RHEL 8 yes - will start to soon - but Docker being gone was a surprise to me | |
| 15:46:43 | sean-k-mooney | but redhat is not really encouraging use to work upstream in kolla | |
| 15:46:51 | sean-k-mooney | to move kolla ansible to podman | |
| 15:46:52 | MarkMielke | right | |
| 15:47:40 | sean-k-mooney | i was thinking about getting involved again to help with that but people internally didnt care that much so i focused on nova | |
| 15:47:56 | MarkMielke | only so much time in day :-) | |
| 15:48:16 | sean-k-mooney | they didnt disucrage me but suggested i look at getting involved in triplo instead | |
| 15:48:36 | sean-k-mooney | and i have no interst in that | |
| 15:48:44 | MarkMielke | at OpenStack conference, I thought it was amusing when they were talking about future of TripleO | |
| 15:48:57 | MarkMielke | and one of the Kayobe people spoke up "we've already done this" | |
| 15:49:35 | MarkMielke | it's fine though - community needs to develop ideas and then discover intersection of common objectives | |
| 15:49:54 | sean-k-mooney | well i mention trying to adopt kayobe when the topic of simplify triople o came up and it was more or less ignored | |
| 15:50:20 | sean-k-mooney | there is too much of a sunken cost falacy around triplo | |
| 15:50:32 | MarkMielke | yeah i see that | |
| 15:51:09 | MarkMielke | but despite working a bit in parallel and duplication of work | |
| 15:51:12 | sean-k-mooney | they have a vaild point that we would have to support migarate all existing customer to it | |
| 15:51:20 | MarkMielke | they're converging | |
| 15:51:28 | sean-k-mooney | but that seams simpler to solve then simplfying triple0 | |
| 15:51:51 | MarkMielke | if TripleO is using containers and Ansible for deployment by the end of it | |
| 15:51:55 | sean-k-mooney | they will diverge again when triplo moves to k8s | |
| 15:51:56 | MarkMielke | it's not really that different from Kayobe | |
| 15:52:17 | MarkMielke | more superficial than not | |
| 15:52:37 | MarkMielke | just taking the long way around to get to that point | |
| 15:52:37 | MarkMielke | :-) | |
| 15:53:03 | sean-k-mooney | well kayobe and kolla-ansible will not move to running the contaienr in k8s | |
| 15:53:11 | sean-k-mooney | so while the continer may be the same | |
| 15:53:24 | sean-k-mooney | all the tooling around upgrades and operation will diverge | |
| 15:53:34 | MarkMielke | yeah, the orchestration around how runc launches will be different | |
| 15:53:42 | MarkMielke | but fundamentally, it'll be the same technology doing the same thing underneath | |
| 15:54:24 | MarkMielke | two groups vehemently disagreeing | |
| 15:54:28 | MarkMielke | but fundamentally agreeing :-) | |
| 15:55:21 | MarkMielke | you can see how I am jaded :-) | |
| 15:56:15 | MarkMielke | i haven't used podman yet much - but the idea that it supports Kubernetes pods, | |
| 15:56:22 | MarkMielke | is interesting | |
| 15:56:34 | sean-k-mooney | well it does and it does not | |
| 15:56:54 | sean-k-mooney | it suport the cncf cri | |
| 15:57:23 | sean-k-mooney | it also provides cli compatiablity with docker | |
| 15:58:02 | sean-k-mooney | so you can use it to interact/manage pods but on its own it would do any of the orchstartion fo the pods that k8s does | |
| 15:58:12 | MarkMielke | probably with some limitations, it still means that something designer for Kubernetes | |
| 15:58:18 | MarkMielke | can almost work in stand-alone capacity | |
| 15:58:26 | sean-k-mooney | for example without the newst version it wont start the contaner after a host reboot | |
| 15:58:44 | MarkMielke | systemd :-) | |
| 15:58:50 | sean-k-mooney | the newest version will creat systemd files for you to implement docker restart policies | |
| 15:58:58 | sean-k-mooney | before that you had to do it by hand | |
| 15:59:07 | MarkMielke | as you mentioned earlier - | |
| 15:59:17 | MarkMielke | i like the systemd model of managing containers | |
| 15:59:22 | MarkMielke | vs the brainless auto-restart | |
| 15:59:35 | sean-k-mooney | where as the k8s kubelet would have done that via the podsepc | |
| 15:59:40 | MarkMielke | dependency management, as well as notification of when an application is up and healthy | |
| 16:00:03 | sean-k-mooney | so its more a tool for defineing pods on a local system without any of the orchetration | |
| 16:00:28 | MarkMielke | primarily for development stand-alone vs running in a production cluster with overhead | |
| 16:00:34 | MarkMielke | right? | |
| 16:00:52 | sean-k-mooney | kind of but it can be used as a building block for you orchelstartion | |
| 16:01:02 | sean-k-mooney | it does support heatbeat continer for examle | |
| 16:01:12 | sean-k-mooney | but no direct graphs fo dependce | |