| kfox1111 | I'd skip the ceph in k8s part of it, and deploy it with kolla-ansible or native ceph-deploy. | 00:01 |
|---|---|---|
| kfox1111 | the rest should apply. | 00:01 |
| kfox1111 | should be pretty close to the existing multinode setup. | 00:01 |
| kfox1111 | I broke up the gate job so that in theory you could reuse large chunks of the scripts. | 00:01 |
| kfox1111 | haven't tried it outside the gate yet though, so if you run into any issues where its not generic enough, please let me know and I can fix it. | 00:02 |
| Pavo | ok that link for the script doesn't work btw | 00:02 |
| Pavo | I'm watching the summit of kolla-kubernetes right now btw | 00:03 |
| sdake_ | pavo its earl ydays for kolla-kubernetes | 00:07 |
| sdake_ | for example, no workflow is implemented | 00:07 |
| sdake_ | pavo my recommendation for you - if deploying today, is to stick with kolla-ansible | 00:07 |
| sdake_ | oh well, maybe sleep will make it better | 00:08 |
| sdake_ | later cats | 00:08 |
| Pavo | I agree but would like to help do somethings with you guys so testing is probably my best area since I still have to learn the coding part | 00:08 |
| *** sdake_ has quit IRC | 00:10 | |
| kfox1111 | if nothing else, going through th emultinode stuff and documenting along the way would be great. | 00:10 |
| Pavo | yeah thats what I was thinking | 00:10 |
| Pavo | and actually getting the guide better | 00:11 |
| kfox1111 | that would be awesome. :) | 00:11 |
| Pavo | but need help setting it up is all | 00:11 |
| kfox1111 | if you have any questions / run into any bugs, please let me know. | 00:12 |
| Pavo | never even looked at k8 before | 00:12 |
| kfox1111 | I gota head out for now. though. | 00:12 |
| Pavo | no problem I am off tomorrow also | 00:12 |
| kfox1111 | mnight run through the minikube document then. | 00:12 |
| kfox1111 | might get a better idea how it works that way. | 00:12 |
| kfox1111 | bbl. | 00:12 |
| *** chas_ has joined #openstack-kolla | 00:15 | |
| *** neilus has quit IRC | 00:19 | |
| *** chas_ has quit IRC | 00:20 | |
| *** neilus has joined #openstack-kolla | 00:20 | |
| *** bjolo_ has quit IRC | 00:26 | |
| *** duonghq has joined #openstack-kolla | 00:46 | |
| *** sdake has joined #openstack-kolla | 00:48 | |
| *** tonanhngo has joined #openstack-kolla | 00:53 | |
| *** tonanhngo has quit IRC | 00:56 | |
| *** zhubingbing has joined #openstack-kolla | 00:57 | |
| *** diogogmt has quit IRC | 00:58 | |
| *** Pavo has quit IRC | 01:04 | |
| openstackgerrit | zhubingbing proposed openstack/kolla: Fix trove dockerfile https://review.openstack.org/396928 | 01:05 |
| *** xiangxinyong has quit IRC | 01:05 | |
| *** Pavo has joined #openstack-kolla | 01:07 | |
| openstackgerrit | zhubingbing proposed openstack/kolla: grafana added to haproxy to listen on VIP https://review.openstack.org/393183 | 01:09 |
| *** tovin07_ has joined #openstack-kolla | 01:11 | |
| *** chas_ has joined #openstack-kolla | 01:16 | |
| *** chas_ has quit IRC | 01:20 | |
| openstackgerrit | zhubingbing proposed openstack/kolla: Fix trove dockerfile https://review.openstack.org/396928 | 01:22 |
| openstackgerrit | zhubingbing proposed openstack/kolla: Fix trove dockerfile https://review.openstack.org/396928 | 01:24 |
| *** pprokop has quit IRC | 01:27 | |
| *** pprokop has joined #openstack-kolla | 01:27 | |
| *** tonanhngo has joined #openstack-kolla | 01:27 | |
| *** tonanhngo has quit IRC | 01:30 | |
| *** sdake has quit IRC | 01:30 | |
| *** zhurong has joined #openstack-kolla | 01:30 | |
| *** sdake has joined #openstack-kolla | 01:32 | |
| *** sdake has quit IRC | 01:33 | |
| *** eaguilar has joined #openstack-kolla | 01:33 | |
| *** v1k0d3n has joined #openstack-kolla | 01:36 | |
| *** asalkeld has joined #openstack-kolla | 01:42 | |
| *** tonanhngo has joined #openstack-kolla | 01:44 | |
| *** tonanhngo has quit IRC | 01:45 | |
| *** asalkeld has quit IRC | 01:47 | |
| *** mtaylor22 has joined #openstack-kolla | 01:53 | |
| *** tonanhngo has joined #openstack-kolla | 02:04 | |
| *** v1k0d3n has quit IRC | 02:04 | |
| *** tonanhngo has quit IRC | 02:06 | |
| *** v1k0d3n has joined #openstack-kolla | 02:16 | |
| *** chas_ has joined #openstack-kolla | 02:17 | |
| *** v1k0d3n has quit IRC | 02:20 | |
| *** chas_ has quit IRC | 02:21 | |
| *** bjolo_ has joined #openstack-kolla | 02:22 | |
| *** tonanhngo has joined #openstack-kolla | 02:24 | |
| *** tonanhngo has quit IRC | 02:26 | |
| *** g3ek has quit IRC | 02:29 | |
| *** haplo37 has quit IRC | 02:30 | |
| *** haplo37 has joined #openstack-kolla | 02:31 | |
| *** g3ek has joined #openstack-kolla | 02:36 | |
| *** dims has quit IRC | 02:43 | |
| *** awiddersheim has quit IRC | 02:45 | |
| *** eaguilar has quit IRC | 02:48 | |
| *** tonanhngo has joined #openstack-kolla | 02:54 | |
| sp_ | Jeffrey4l: hi I know this can be a lame query, if we compare kolla-ansible's pre-check and kolla-k8s's operator in terms of dependency check and resolution. Then how these two are differ. | 02:55 |
| *** tonanhngo has quit IRC | 02:55 | |
| sp_ | please provide your view, if I am going wrong | 02:56 |
| *** f13o has joined #openstack-kolla | 02:59 | |
| sp_ | pbourke: can you please help to understand these two suppose if we compare kolla-ansible's pre-check and kolla-k8s's operator in terms of dependency check and resolution. Then how these two are differ. please provide your view, if I am going wrong. | 03:00 |
| *** awiddersheim has joined #openstack-kolla | 03:02 | |
| *** Pavo has quit IRC | 03:04 | |
| *** Pavo has joined #openstack-kolla | 03:09 | |
| openstackgerrit | Larry Rensing proposed openstack/kolla-kubernetes: Adding prechecks script https://review.openstack.org/394569 | 03:10 |
| *** tonanhngo has joined #openstack-kolla | 03:13 | |
| *** tonanhngo has quit IRC | 03:15 | |
| *** v1k0d3n has joined #openstack-kolla | 03:24 | |
| *** v1k0d3n has quit IRC | 03:30 | |
| *** tonanhngo has joined #openstack-kolla | 03:34 | |
| *** tonanhngo has quit IRC | 03:36 | |
| Jeffrey4l | sp_, no idea about the operator. let me check first. | 03:43 |
| *** Pavo has quit IRC | 03:47 | |
| *** Pavo has joined #openstack-kolla | 03:51 | |
| *** tonanhngo has joined #openstack-kolla | 03:54 | |
| *** tonanhngo has quit IRC | 03:55 | |
| *** f13o has quit IRC | 04:05 | |
| sp_ | Jeffrey4l: it's fine. Thanks for reply. May be @pbourke, @sdake or someone else can help | 04:05 |
| *** tonanhngo has joined #openstack-kolla | 04:14 | |
| *** tonanhngo has quit IRC | 04:15 | |
| *** chas_ has joined #openstack-kolla | 04:18 | |
| *** chas_ has quit IRC | 04:23 | |
| *** zhurong has quit IRC | 04:37 | |
| *** tonanhngo has joined #openstack-kolla | 04:43 | |
| *** tonanhngo has quit IRC | 04:46 | |
| *** coolsvap has joined #openstack-kolla | 05:24 | |
| *** zhurong has joined #openstack-kolla | 05:33 | |
| *** tonanhngo has joined #openstack-kolla | 05:44 | |
| *** tonanhngo has quit IRC | 05:45 | |
| *** Pavo has quit IRC | 05:50 | |
| *** Pavo has joined #openstack-kolla | 05:55 | |
| mtaylor22 | hrm | 05:56 |
| mtaylor22 | has anyone else seen heka spew out logs like this: error: can't deliver matched message: Queue is full | 05:57 |
| *** skramaja_ has quit IRC | 05:59 | |
| *** skramaja has joined #openstack-kolla | 06:03 | |
| *** hyakuhei has quit IRC | 06:04 | |
| *** tonanhngo has joined #openstack-kolla | 06:04 | |
| *** tonanhngo has quit IRC | 06:06 | |
| *** mtaylor22 has quit IRC | 06:09 | |
| openstackgerrit | Wei Cao proposed openstack/kolla: Add karbor container https://review.openstack.org/395006 | 06:23 |
| *** tonanhngo has joined #openstack-kolla | 06:24 | |
| *** tonanhngo has quit IRC | 06:26 | |
| openstackgerrit | Jeffrey Zhang proposed openstack/kolla: corrects invalid logrotate option maxsize https://review.openstack.org/397012 | 06:34 |
| *** v1k0d3n has joined #openstack-kolla | 06:34 | |
| *** v1k0d3n has quit IRC | 06:39 | |
| *** tonanhngo has joined #openstack-kolla | 06:44 | |
| *** tonanhngo has quit IRC | 06:44 | |
| openstackgerrit | Jeffrey Zhang proposed openstack/kolla: Add neutron vpnaas code into neutron-server container https://review.openstack.org/397015 | 06:45 |
| openstackgerrit | zhubingbing proposed openstack/kolla: Fix trove dockerfile https://review.openstack.org/396928 | 07:07 |
| openstackgerrit | Wei Cao proposed openstack/kolla: [WIP] Add karbor ansible role https://review.openstack.org/395022 | 07:11 |
| *** haplo37 has quit IRC | 07:15 | |
| *** g3ek has quit IRC | 07:15 | |
| *** g3ek has joined #openstack-kolla | 07:21 | |
| *** haplo37 has joined #openstack-kolla | 07:21 | |
| *** neilus has quit IRC | 07:25 | |
| *** neilus has joined #openstack-kolla | 07:25 | |
| *** neilus has quit IRC | 07:26 | |
| *** f13o has joined #openstack-kolla | 07:32 | |
| openstackgerrit | Merged openstack/kolla: grafana added to haproxy to listen on VIP https://review.openstack.org/393183 | 07:36 |
| *** tonanhngo has joined #openstack-kolla | 07:44 | |
| *** unicell has joined #openstack-kolla | 07:45 | |
| *** tonanhngo has quit IRC | 07:45 | |
| *** unicell1 has quit IRC | 07:46 | |
| *** f13o has quit IRC | 07:50 | |
| *** Pavo has quit IRC | 07:50 | |
| *** Pavo has joined #openstack-kolla | 07:55 | |
| *** shardy has joined #openstack-kolla | 07:58 | |
| *** neilus has joined #openstack-kolla | 08:01 | |
| *** neilus has quit IRC | 08:06 | |
| *** sdake has joined #openstack-kolla | 08:07 | |
| *** unicell has quit IRC | 08:11 | |
| *** unicell has joined #openstack-kolla | 08:13 | |
| *** matrohon has joined #openstack-kolla | 08:17 | |
| *** f13o has joined #openstack-kolla | 08:28 | |
| *** egonzalez90 has joined #openstack-kolla | 08:30 | |
| duonghq | morning egonzalez90 | 08:31 |
| egonzalez90 | morning duonghq | 08:31 |
| duonghq | have a nice week ;) | 08:31 |
| egonzalez90 | hope so, this week is global docker mentor meetup, some fun at the evening | 08:32 |
| duonghq | egonzalez90, are you joining? | 08:32 |
| egonzalez90 | yes | 08:33 |
| duonghq | so, your work is docker-related? or just for personal interested? | 08:33 |
| sdake | evening peeps | 08:33 |
| duonghq | evening sdake | 08:34 |
| egonzalez90 | personal, I don't do anything about docker at job (even nothing about OpenStack) | 08:34 |
| egonzalez90 | sdake, how was k8s conferences? | 08:35 |
| duonghq | have fun "D | 08:35 |
| sdake | me eithe egonzalez90 :) | 08:35 |
| sdake | cloudnativecon was interesting | 08:35 |
| sdake | learned alot | 08:35 |
| *** Serlex has joined #openstack-kolla | 08:35 | |
| duonghq | I'm not sure why each recheck 1-2 gate(s) failed (the policy.json ps) | 08:35 |
| sdake | alot of waht i have learned was fed into ryan's spec | 08:35 |
| egonzalez90 | share knowledge ;) | 08:36 |
| duonghq | #link https://review.openstack.org/#/c/394260/ | 08:36 |
| egonzalez90 | duonghq: i think is unrelated to the change | 08:36 |
| duonghq | egonzalez90, you think it's just gate unstable? | 08:37 |
| duonghq | anybody use reposync of yum yet? | 08:37 |
| egonzalez90 | pbourke: any idea why oracle gates are failing? | 08:37 |
| egonzalez90 | duonghq: yes, other changes are failing too | 08:38 |
| sdake | http://logs.openstack.org/60/394260/5/check/gate-kolla-dsvm-deploy-oraclelinux-binary-centos-7-nv/8ff7fbc/console.html#_2016-11-14_08_11_27_564126 | 08:38 |
| sdake | our gates are generally flakey on rax : http://logs.openstack.org/60/394260/5/check/gate-kolla-dsvm-deploy-oraclelinux-binary-centos-7-nv/8ff7fbc/console.html#_2016-11-14_07_34_16_636652 | 08:39 |
| duonghq | yeah, it failed at this step every time it failed | 08:39 |
| sdake | too bad we can't eliminate rax as a cloud provider for our jobs | 08:40 |
| sdake | i've already investigte if this possible and it is not | 08:40 |
| sdake | maybe Jeffrey4l can fix that gate - not sure | 08:40 |
| sdake | its hard to fix because it does not schedule often in our jobs | 08:40 |
| *** tonanhngo has joined #openstack-kolla | 08:44 | |
| *** tonanhngo has quit IRC | 08:46 | |
| *** mgoddard has joined #openstack-kolla | 08:49 | |
| openstackgerrit | Merged openstack/kolla: Add bindep environment to tox https://review.openstack.org/396856 | 08:56 |
| *** f13o has quit IRC | 08:57 | |
| *** chas_ has joined #openstack-kolla | 08:57 | |
| *** f13o has joined #openstack-kolla | 08:57 | |
| duonghq | sdake, can you explain what does fencing do in kolla-k8s context? | 08:58 |
| *** tonanhngo has joined #openstack-kolla | 09:04 | |
| *** sdake has quit IRC | 09:05 | |
| *** tonanhngo has quit IRC | 09:06 | |
| *** berendt has joined #openstack-kolla | 09:12 | |
| *** f13o_ has joined #openstack-kolla | 09:23 | |
| *** tonanhngo has joined #openstack-kolla | 09:24 | |
| *** tonanhngo has quit IRC | 09:26 | |
| *** strigazi_AFK is now known as strigazi | 09:26 | |
| *** f13o has quit IRC | 09:27 | |
| *** athomas has joined #openstack-kolla | 09:30 | |
| *** zhurong has quit IRC | 09:34 | |
| *** magicboiz has joined #openstack-kolla | 09:34 | |
| magicboiz | Hi, is prameswar here? | 09:39 |
| *** tonanhngo has joined #openstack-kolla | 09:43 | |
| openstackgerrit | Wei Cao proposed openstack/kolla: [WIP] Add karbor ansible role https://review.openstack.org/395022 | 09:44 |
| *** tonanhngo has quit IRC | 09:44 | |
| openstackgerrit | narasimha18sv proposed openstack/kolla: update missing dispatcher configurations for ceilometer when backend is database https://review.openstack.org/397089 | 09:46 |
| *** openstackgerrit has quit IRC | 09:47 | |
| *** openstackgerrit has joined #openstack-kolla | 09:48 | |
| *** Pavo has quit IRC | 09:50 | |
| *** Pavo has joined #openstack-kolla | 09:55 | |
| pprokop | HI kfox1111: stackanetes uses kolla images with custom last layer | 09:56 |
| pprokop | a kubernetes-entrypoint | 09:56 |
| duonghq | egonzalez90, so, can my patchset be merged? | 09:56 |
| *** msimonin has joined #openstack-kolla | 09:59 | |
| openstackgerrit | zhubingbing proposed openstack/kolla: Add trove role https://review.openstack.org/354901 | 10:01 |
| *** tovin07_ has quit IRC | 10:03 | |
| openstackgerrit | Jeffrey Zhang proposed openstack/kolla: Use check_mode no instead of always_run https://review.openstack.org/397094 | 10:04 |
| zhubingbing | hi | 10:04 |
| *** tonanhngo has joined #openstack-kolla | 10:05 | |
| zhubingbing | who can help me look trove ~) | 10:05 |
| openstackgerrit | Jeffrey Zhang proposed openstack/kolla: Add neutron vpnaas code into neutron-server container https://review.openstack.org/397015 | 10:05 |
| *** portdirect_away is now known as portdirect | 10:06 | |
| *** tonanhngo has quit IRC | 10:07 | |
| openstackgerrit | Jeremy Liu proposed openstack/kolla: Word choice for back end https://review.openstack.org/390788 | 10:16 |
| *** duonghq has quit IRC | 10:19 | |
| portdirect | morning :) | 10:19 |
| *** tonanhngo has joined #openstack-kolla | 10:24 | |
| *** tonanhngo has quit IRC | 10:25 | |
| openstackgerrit | Merged openstack/kolla: Add karbor container https://review.openstack.org/395006 | 10:27 |
| openstackgerrit | Merged openstack/kolla: Fix trove dockerfile https://review.openstack.org/396928 | 10:33 |
| *** jmccarthy has left #openstack-kolla | 10:35 | |
| *** v1k0d3n has joined #openstack-kolla | 10:36 | |
| *** v1k0d3n has quit IRC | 10:40 | |
| *** stvnoyes has quit IRC | 10:43 | |
| *** stvnoyes has joined #openstack-kolla | 10:43 | |
| *** tonanhngo has joined #openstack-kolla | 10:44 | |
| *** tonanhngo has quit IRC | 10:46 | |
| openstackgerrit | Merged openstack/kolla: Allow operators to customise pip packages in nova_compute https://review.openstack.org/396687 | 10:47 |
| *** ppalacios has joined #openstack-kolla | 10:50 | |
| *** Serlex has quit IRC | 10:59 | |
| *** zhubingbing has quit IRC | 11:05 | |
| *** athomas has quit IRC | 11:08 | |
| *** mliima has joined #openstack-kolla | 11:13 | |
| *** athomas has joined #openstack-kolla | 11:13 | |
| *** duonghq has joined #openstack-kolla | 11:17 | |
| *** chas_ has quit IRC | 11:29 | |
| *** f13o_ has quit IRC | 11:31 | |
| *** f13o_ has joined #openstack-kolla | 11:31 | |
| openstackgerrit | Surya Prakash Singh proposed openstack/kolla: Consistent home directory creation for all the services https://review.openstack.org/390179 | 11:31 |
| *** zhurong has joined #openstack-kolla | 11:35 | |
| *** zhurong has quit IRC | 11:42 | |
| *** Pavo has quit IRC | 11:50 | |
| *** haplo37 has quit IRC | 11:53 | |
| *** Pavo has joined #openstack-kolla | 11:55 | |
| *** tonanhngo has joined #openstack-kolla | 11:55 | |
| *** g3ek has quit IRC | 11:56 | |
| *** tonanhngo has quit IRC | 11:57 | |
| *** stvnoyes has quit IRC | 11:58 | |
| *** dave-mccowan has joined #openstack-kolla | 12:01 | |
| *** haplo37 has joined #openstack-kolla | 12:02 | |
| *** g3ek has joined #openstack-kolla | 12:03 | |
| *** nihilifer has joined #openstack-kolla | 12:04 | |
| *** shardy is now known as shardy_lunch | 12:09 | |
| *** DTadrzak has joined #openstack-kolla | 12:11 | |
| *** tonanhngo has joined #openstack-kolla | 12:13 | |
| *** tonanhngo has quit IRC | 12:15 | |
| *** zhurong has joined #openstack-kolla | 12:16 | |
| *** zhurong has quit IRC | 12:19 | |
| *** zhurong has joined #openstack-kolla | 12:21 | |
| pomac | FYI, ansible/roles/neutron/templates/neutron.conf.j2:18:metadata_works = {{ openstack_service_workers }} - feels like that should be metadata_workers ;) | 12:25 |
| *** neilus has joined #openstack-kolla | 12:25 | |
| berendt | pomac can you provide a patch for it? | 12:25 |
| pomac | berendt: sure, I just have to see if this could be related to our issues | 12:26 |
| pomac | Humm should i fork and do a pull req or just send the patch somewhere? I'm not really in to the general workflow here | 12:29 |
| *** neilus has quit IRC | 12:29 | |
| berendt | we work with gerrit and do not use the common github workflow | 12:31 |
| *** rhallisey has joined #openstack-kolla | 12:32 | |
| berendt | pomac simply open a bug report for it on launchpad, this way somebody else can fix it | 12:32 |
| berendt | pomac https://launchpad.net/kolla | 12:32 |
| pomac | berendt: oki | 12:33 |
| *** tonanhngo has joined #openstack-kolla | 12:34 | |
| *** tonanhngo has quit IRC | 12:35 | |
| *** srwilkers has joined #openstack-kolla | 12:48 | |
| *** Serlex has joined #openstack-kolla | 12:52 | |
| *** ayoung has quit IRC | 12:54 | |
| *** schwicht has joined #openstack-kolla | 13:06 | |
| *** f13o__ has joined #openstack-kolla | 13:07 | |
| *** f13o_ has quit IRC | 13:10 | |
| *** srwilkers has quit IRC | 13:13 | |
| *** srwilkers has joined #openstack-kolla | 13:13 | |
| *** srwilkers has quit IRC | 13:15 | |
| *** srwilkers has joined #openstack-kolla | 13:16 | |
| *** neilus has joined #openstack-kolla | 13:16 | |
| *** neilus has quit IRC | 13:19 | |
| *** schwicht has quit IRC | 13:20 | |
| *** stvnoyes has joined #openstack-kolla | 13:20 | |
| *** lamt has joined #openstack-kolla | 13:21 | |
| *** neilus has joined #openstack-kolla | 13:21 | |
| *** neilus has quit IRC | 13:21 | |
| *** chas_ has joined #openstack-kolla | 13:22 | |
| *** lamt has quit IRC | 13:22 | |
| *** lamt has joined #openstack-kolla | 13:23 | |
| *** sdake has joined #openstack-kolla | 13:24 | |
| sdake | Jeffrey4l morning | 13:24 |
| *** schwicht has joined #openstack-kolla | 13:24 | |
| sdake | duonghq still around? | 13:24 |
| Jeffrey4l | sdake, morning | 13:24 |
| sdake | sup jeffrey4l | 13:25 |
| sdake | repo split should hapen shortly btw | 13:25 |
| Jeffrey4l | nothing special ;) | 13:26 |
| Jeffrey4l | cool. | 13:26 |
| duonghq | sdake, hi | 13:26 |
| duonghq | evening | 13:26 |
| Jeffrey4l | so the new repo is already prepared? | 13:26 |
| sdake | duonghq so that fencing agent | 13:27 |
| sdake | Jeffrey4l yes its ready to go awaiting inc0's ack on the reviews | 13:27 |
| Jeffrey4l | i saw that. it is just create a new repo, right? | 13:27 |
| openstackgerrit | Ryan Hallisey proposed openstack/kolla-kubernetes: Spec - Kolla-Kubernetes Deployment Architecture https://review.openstack.org/392257 | 13:27 |
| duonghq | sdake, which agent? do you meen the OpenStack service one or something? | 13:28 |
| sdake | Jeffrey4l check out http://github.com/sdake/kolla | 13:28 |
| sdake | duonghq question you had asked me last night | 13:28 |
| rhallisey | 1 more day on the spec folks | 13:28 |
| rhallisey | it's it pretty good shape | 13:28 |
| sdake | duonghq what it does is kill connections for rbd driver i think | 13:28 |
| sdake | rhallisey i'm glad you got rid of the marketing speak ;) | 13:30 |
| *** neilus has joined #openstack-kolla | 13:30 | |
| rhallisey | :) wasn't intentional | 13:30 |
| sdake | I was like "huh" | 13:30 |
| sdake | of course you failed to work dovetail into the spec | 13:30 |
| sdake | oh well | 13:30 |
| rhallisey | :) | 13:31 |
| *** shardy_lunch is now known as shardy | 13:31 | |
| sp_ | dear sdake: hi, i need your precious 2 minutes | 13:31 |
| sdake | sp_ shoot | 13:32 |
| duonghq | sdake, I'm sorry but something jam my mind, last weekend I do not join IRC much (1 OpenStack meetup, some hang out and many other thing), so I can pretty sure I do not ask you anything last weekend (in my timezone). About the fencing question, last IRC meeting, some guys mentioned fencing and deps, I can understood the deps but do not get idea of fencing, it's general or for some service? | 13:32 |
| openstackgerrit | bjorn lofdahl proposed openstack/kolla: Fix neutron.conf.j2 metadata_workers spelling error https://review.openstack.org/397186 | 13:32 |
| sdake | duonghq not totally sure | 13:32 |
| *** fguillot has joined #openstack-kolla | 13:33 | |
| duonghq | ok, so I will comeback with fencing later, | 13:33 |
| sp_ | what can be plan from community side for this BP https://blueprints.launchpad.net/kolla/+spec/kolla-gui because we didn't had any design discussion on this in Barcelona summit Your opinion would be quite helpful to me. | 13:34 |
| duonghq | for the repo-split, will any bp be written? | 13:34 |
| *** neilus has quit IRC | 13:35 | |
| *** dims has joined #openstack-kolla | 13:35 | |
| duonghq | sp_, I have not got idea of this bp too, but anybody see mdnadeem around? | 13:35 |
| bjolo_ | sp_, not to push my own bp, but i think a gui and cli goes hand in hand https://blueprints.launchpad.net/kolla/+spec/kolla-multicloud-cli | 13:36 |
| sdake | sp_ not sure ask inc0 | 13:37 |
| bjolo_ | implement the functions desired as an API and both gui and cli can be built on top of that | 13:37 |
| sdake | bjolo_ yes thats a BKP for implementing guis/clis | 13:37 |
| duonghq | bjolo_, just skim through your bp, very nice idea | 13:37 |
| sdake | bjolo_ and further how i assumed the work would be done | 13:38 |
| duonghq | but I do not think GUI is good idea atm, | 13:38 |
| *** v1k0d3n has joined #openstack-kolla | 13:39 | |
| *** v1k0d3n has quit IRC | 13:39 | |
| duonghq | CLI and under mechanism is totally ok | 13:39 |
| bjolo_ | to me a cli comes first | 13:39 |
| bjolo_ | gui is just a visual version of the cli :) | 13:39 |
| duonghq | but for GUI, it should be deferred for some cycle | 13:39 |
| duonghq | sure, but we must care some more implementation details, | 13:39 |
| sdake | i think a gui is a good idea, i think inc0 does not | 13:40 |
| sdake | i've heard conflciting thoughts on this | 13:40 |
| sdake | my take is as follows | 13:40 |
| sdake | We will have cmplete parity with everyone with a gui | 13:41 |
| sdake | without a gui we lack parity | 13:41 |
| sdake | other people think its the job of the product companies taking kolla to market to make a gui out of it | 13:41 |
| *** v1k0d3n has joined #openstack-kolla | 13:41 | |
| sdake | i dont have time to write code either way for it,s o ymmv ;) | 13:42 |
| duonghq | sdake, agreed, but I still do not think it should be done in very near future, | 13:42 |
| sdake | race is on to kubernete-ize the datacenter | 13:43 |
| *** janonymous has joined #openstack-kolla | 13:43 | |
| duonghq | but do you think bjolo_'s bp is very useful if it's done well, sdake | 13:43 |
| *** janonymous has left #openstack-kolla | 13:43 | |
| sdake | ansible has won baremetal deployments | 13:43 |
| sp_ | sdake: I agree with you and GUI would be a killer feature for kolla | 13:43 |
| sdake | for virtual deployments (kubernetes) i think it makes more sense to focus there | 13:43 |
| bjolo_ | yea the discussion if kolla is a project or a product is part of the divide. One can argue either way. If it is only a project, why do we have containers for monitoring, central logging, etc right | 13:43 |
| sdake | bjolo_ it is a project | 13:43 |
| sdake | bjolo_ not a product | 13:43 |
| sdake | i can answer that without hesitation | 13:44 |
| sp_ | sdake: I had discussion with mdnadeem: | 13:44 |
| sdake | it has monitoring central logging because those things are needed by operators absolutely | 13:44 |
| sdake | a gui is a pretty thing that helps "sell" a product | 13:44 |
| sdake | most ops wont use a gui | 13:44 |
| *** krtaylor has quit IRC | 13:45 | |
| sdake | if it is to be done, please use a rest api :) | 13:45 |
| bjolo_ | depends on what we visualize in the gui | 13:45 |
| bjolo_ | i agree that guis are most in the way | 13:45 |
| *** eaguilar has joined #openstack-kolla | 13:45 | |
| *** v1k0d3n has quit IRC | 13:46 | |
| sp_ | sdake: Yes agree, we will provide some sort of rest api that matches our kolla-ansible api | 13:47 |
| bjolo_ | a gui can serve as the unified frontend for the visual components we have in kolla | 13:47 |
| bjolo_ | ops log into the gui, from there they have links to kibana, haproxy status page, rabbitmq manager | 13:47 |
| bjolo_ | etc | 13:48 |
| duonghq | sdake, can you take a look at my ansbile-become ps serie: https://review.openstack.org/#/c/358539/ | 13:48 |
| bjolo_ | metrics from grafana etc | 13:48 |
| duonghq | bjolo_, sure, but, many work come here | 13:48 |
| sdake | just woke up - dont review patch sets until my brain is working sorry duonghq | 13:48 |
| duonghq | sdake, oops, I thought you have wake up for one or two hours, sorry | 13:49 |
| bjolo_ | visual LLDP topology maps | 13:49 |
| bjolo_ | just to make my standpoint clear | 13:50 |
| duonghq | bjolo_, IMO, somebody should jot down your ideas to the bp | 13:50 |
| sp_ | sdake: Thanks for your valuable opinion, I would be working on this. | 13:50 |
| bjolo_ | i dont really use guis to administrate stuff. command line is way better for that. however, guis do help visualise stuff and that should be capitalized upon | 13:50 |
| *** Pavo has quit IRC | 13:50 | |
| *** schwicht has quit IRC | 13:50 | |
| *** krtaylor has joined #openstack-kolla | 13:51 | |
| * sdake wishes my amex points were 1 point per 1 dollar | 13:52 | |
| sdake | i have 140k points atm.. :) | 13:52 |
| *** schwicht has joined #openstack-kolla | 13:52 | |
| sdake | rbergeron earned us 30k or so points bybooking bunch o work travel | 13:52 |
| duonghq | bjolo_, I think your idea and the bp worth a spec? | 13:52 |
| sdake | dont bother with specs imo | 13:53 |
| sdake | inc0 was pretty clear its not the time for specs | 13:53 |
| duonghq | sdake, so we track these things on launchpad bp? | 13:53 |
| sdake | yes as work items | 13:53 |
| *** Pavo has joined #openstack-kolla | 13:55 | |
| bjolo_ | sdake, i dont mean disagree with you or the kolla core team, but i think you have to re-think the project vs product part since it is colliding with reality. From the coders perspective it is a project and perhaps it always will be, but from an operator it will be a considered a product. Whatever we find "missing" from an operator perspective, we will open up requests for and some of us will submit PS for it | 13:55 |
| sdake | bjolo_ still a project | 13:56 |
| bjolo_ | for you ok :) | 13:56 |
| sdake | bjolo_ openstack doesnt product products :) | 13:56 |
| sdake | produce that is | 13:56 |
| *** schwicht has quit IRC | 13:56 | |
| sdake | a product comes with support and escalation paths and all kinds of other rigamorale | 13:56 |
| bjolo_ | so who should use kolla-ansible in that case? | 13:57 |
| sdake | like contracts, sows, etc | 13:57 |
| sdake | bjolo_ i hope everyone does | 13:57 |
| sdake | bjolo_ but again, at this point in time, upstream isn't a "product team" | 13:57 |
| sdake | although for example jeffrey4l's co is producing a product based on kolla so he is part of a product team | 13:57 |
| bjolo_ | yes, i agree with that. perhaps we need some better definitions here | 13:57 |
| sdake | a true product would finetune the ci/cd pipeline | 13:58 |
| bjolo_ | when i say product in the context i dont mean SLAs etc | 13:58 |
| sdake | and make all that stuff work | 13:58 |
| *** f13o__ has quit IRC | 13:58 | |
| sdake | ok well to me what is what a product is :) | 13:59 |
| sdake | that is what that is :) | 13:59 |
| *** f13o__ has joined #openstack-kolla | 13:59 | |
| bjolo_ | community product that includes all features needed by operators | 13:59 |
| sdake | products are sold for money and with the exchange of money comes a contract determining what will be done by the co supporting the product | 13:59 |
| bjolo_ | kolla-ansible is to me a community product | 13:59 |
| sdake | we have no such thing upstream | 13:59 |
| sdake | kolla-ansible is meant to be a project where people base products on in their downstreams | 14:00 |
| sdake | this is how oracle behaves | 14:00 |
| sdake | and this is the model we want | 14:00 |
| sdake | upstream = project, downstream = product | 14:01 |
| bjolo_ | ok so by that rational only openstack containers should be in the project. | 14:02 |
| sdake | disagree | 14:02 |
| bjolo_ | my point is that the line is drawn somewhat arbitrarily | 14:02 |
| sdake | in fact, containers are really where we run afoul of my product definitinos | 14:03 |
| sdake | the line in my mind is drawn "has a contract been written and signed" | 14:03 |
| sdake | if no contract, no product | 14:04 |
| *** khamtamtun has joined #openstack-kolla | 14:04 | |
| *** zhubingbing_ has joined #openstack-kolla | 14:05 | |
| sdake | proj·ect | 14:07 |
| sdake | noun | 14:07 |
| sdake | ˈpräjˌekt/ | 14:07 |
| sdake | 1. | 14:08 |
| sdake | an individual or collaborative enterprise that is carefully planned and designed to achieve a particular aim. | 14:08 |
| sdake | prod·uct | 14:08 |
| sdake | ˈprädəkt/Submit | 14:08 |
| sdake | noun | 14:08 |
| sdake | 1. | 14:08 |
| sdake | an article or substance that is manufactured or refined for sale. | 14:08 |
| sdake | "marketing products and services" | 14:08 |
| *** zhurong has quit IRC | 14:08 | |
| sdake | bjolo_ where kolla falls down on the product side is it hasn't been refined ;) | 14:09 |
| *** schwicht has joined #openstack-kolla | 14:10 | |
| sdake | srwilkers i dont see your name on the list of contribs to kolla-lubernetes, are you joining in ? :) | 14:11 |
| duonghq | sdake, where is the list? | 14:13 |
| sdake | duonghq in the spec | 14:13 |
| duonghq | ah, okay | 14:14 |
| bjolo_ | sdake, i think we are actually on the same page, we just use different words for. Project to me is a play thing initially. Once it reaches some form of working level and people start using it, it has to be transformed into a well functioning and responsible project. | 14:14 |
| Jeffrey4l | sean-k-mooney, around? | 14:14 |
| sean-k-mooney | Jeffrey4l: yes kind of | 14:15 |
| sdake | bjolo_ right and we have done that transformation, but it doesn't make it a product ;) | 14:15 |
| Jeffrey4l | sean-k-mooney, could u check the logrotate change? https://review.openstack.org/397012 | 14:15 |
| Jeffrey4l | i think it is correct in the original implementation. | 14:15 |
| *** khamtamtun has quit IRC | 14:16 | |
| sean-k-mooney | Jeffrey4l: perhaps. that said the reason i said kindof is i my currently fixing my cluster angian because the log grew to 70G and i ran out of disk space | 14:17 |
| rhallisey | sdake, I put kolla-kubernetes community to include everyone | 14:17 |
| sean-k-mooney | Jeffrey4l: this has happened with both versions | 14:17 |
| Jeffrey4l | sean-k-mooney, in my env, it works fine. | 14:18 |
| Jeffrey4l | sean-k-mooney, ls -alh neutron-server.log* | 14:18 |
| Jeffrey4l | -rw-r--r-- 1 1000 1001 26M Nov 14 22:03 neutron-server.log | 14:18 |
| Jeffrey4l | -rw-r--r-- 1 1000 1001 51M Nov 6 03:25 neutron-server.log.1 | 14:18 |
| Jeffrey4l | -rw-r--r-- 1 1000 1001 4.2M Nov 1 03:25 neutron-server.log.2.gz | 14:18 |
| Jeffrey4l | -rw-r--r-- 1 1000 1001 4.3M Oct 23 03:18 neutron-server.log.3.gz | 14:18 |
| Jeffrey4l | -rw-r--r-- 1 1000 1001 4.2M Oct 12 03:18 neutron-server.log.4.gz | 14:18 |
| Jeffrey4l | -rw-r--r-- 1 1000 1001 4.0M Oct 1 03:33 neutron-server.log.5.gz | 14:18 |
| Jeffrey4l | -rw-r--r-- 1 1000 1001 4.2M Sep 20 03:47 neutron-server.log.6.gz | 14:18 |
| Jeffrey4l | sorry.. | 14:18 |
| Jeffrey4l | paste url http://paste.openstack.org/show/589130/ | 14:18 |
| sean-k-mooney | Jeffrey4l: what is your build config. mine is ubuntu source | 14:19 |
| Jeffrey4l | sean-k-mooney, mine is centos + source. | 14:19 |
| Jeffrey4l | newton branch. | 14:19 |
| Jeffrey4l | ( upgraded from mitaka ) | 14:20 |
| sean-k-mooney | could this be cause by different logrotate verions? | 14:20 |
| Jeffrey4l | centos is using 3.8.6, ubuntu is using 3.8.7, so i do not think so. | 14:21 |
| sean-k-mooney | how offten does crone run the logroate check? | 14:22 |
| *** markt_ has joined #openstack-kolla | 14:22 | |
| *** markt_ has quit IRC | 14:22 | |
| Jeffrey4l | sean-k-mooney, let's talk the configuration file only. does it make sense i made about the original config in PS? | 14:22 |
| Jeffrey4l | default value. let me check. | 14:22 |
| Jeffrey4l | daily. | 14:23 |
| sean-k-mooney | yes if maxsize is now supported it does | 14:23 |
| sean-k-mooney | Jeffrey4l: it might make sense to make this overridable | 14:23 |
| *** chas_ has quit IRC | 14:24 | |
| sean-k-mooney | Jeffrey4l: the reason my logs are growing so quickly is because the l3 agent is complaing about iptables so its rapidly loging warning messages | 14:24 |
| *** khamtamtun has joined #openstack-kolla | 14:25 | |
| *** chas_ has joined #openstack-kolla | 14:25 | |
| Jeffrey4l | check this Typically logrotate will only be run once daily, so the size limits will not be honoured exactly. logrotate's status file (possibly /var/lib/logrotate.status) only stores dates (not times), it is not intended for use more frequently, so you cannot trivially rotate files more frequently. | 14:25 |
| Jeffrey4l | from http://serverfault.com/questions/474941/how-to-rotate-log-based-on-an-interval-unless-log-exceeds-a-certain-size | 14:25 |
| Jeffrey4l | so l3 agent generate 70G in 24 hour? | 14:25 |
| sean-k-mooney | yep it was logging 192,000 lines of logs every time it check iptables. | 14:26 |
| sean-k-mooney | it was complaining about duplicate iptables rules | 14:26 |
| Jeffrey4l | but logrotate only work with daily, right? | 14:28 |
| sean-k-mooney | i know i have to fix whatever is wrong with the l3 agent but logroate should be able to prevent it form eating all the disk space. | 14:28 |
| sean-k-mooney | right because we run it daily | 14:28 |
| Jeffrey4l | at least, use `size` do not work right now. | 14:28 |
| sean-k-mooney | we dont have to run it daily | 14:28 |
| Jeffrey4l | so let's revert the original change and try other solution, like run logrotate hourly? | 14:29 |
| *** chas_ has quit IRC | 14:29 | |
| sean-k-mooney | runing it hourly would help but yes lets revert. the size vs maxsize was obviouly a red hering | 14:30 |
| Jeffrey4l | OK. | 14:30 |
| egonzalez90 | using maxsize will rotate when the specified size is reached, even before the interfal | 14:30 |
| sean-k-mooney | egonzalez90 if cron only runs logroate once a day it wont | 14:31 |
| Jeffrey4l | egonzalez90, yep. but the issue is logrotate is run daily. may not enough in some case. | 14:31 |
| Jeffrey4l | btw, egonzalez90 nice catch ;) | 14:31 |
| egonzalez90 | just googled about it ;) | 14:31 |
| egonzalez90 | sean-k-mooney: can you check if this fit with your usecase of the ovs-cleanup https://review.openstack.org/#/c/396948/ | 14:32 |
| *** mgiles has joined #openstack-kolla | 14:32 | |
| openstackgerrit | Jeffrey Zhang proposed openstack/kolla: Revert "corrects invalid logrotate option maxsize" https://review.openstack.org/397214 | 14:33 |
| sean-k-mooney | egonzalez90: just looking at it now | 14:33 |
| duonghq | egonzalez90, ping | 14:34 |
| egonzalez90 | duonghq: pong | 14:35 |
| *** tonanhngo has joined #openstack-kolla | 14:35 | |
| duonghq | egonzalez90, I just rechecked this: https://review.openstack.org/#/c/394260/ and another gate failed, so it can be merged? | 14:35 |
| sean-k-mooney | egonzalez90: im not sure we shoudl delete teh bridges when we delete the neuttron agent | 14:35 |
| sean-k-mooney | egonzalez90: i think that should only be done if we are deletate the ovs-vswitchd | 14:36 |
| *** tonanhngo has quit IRC | 14:36 | |
| *** ayoung has joined #openstack-kolla | 14:37 | |
| Jeffrey4l | egonzalez90, sean-k-mooney it is not removing ovs bridge, it is only removing ovs port. | 14:37 |
| Jeffrey4l | and sean-k-mooney this script removes all container and it is OK to remove all port before removing all containers. | 14:38 |
| openstackgerrit | caoyuan proposed openstack/kolla: Allow operators to customise pip packages in dind https://review.openstack.org/397221 | 14:38 |
| sean-k-mooney | Jeffrey4l: the script also allows you to remove only a subset | 14:38 |
| sdake | duonghq line 215 is where you want to add your name: https://review.openstack.org/#/c/392257/9/specs/kolla-kubernetes-arch.rst | 14:39 |
| sean-k-mooney | i used to use it to remove just the containers i was modifying | 14:39 |
| egonzalez90 | agree with sean-k-mooney , just use cleanup-containers horizon and only remove horizon | 14:39 |
| sean-k-mooney | Jeffrey4l: so tools/cleanup-containers nova && tools/kolla-ansible deploy --tags nova | 14:40 |
| sean-k-mooney | Jeffrey4l: its only usefull for single node but it is useful when developing | 14:41 |
| Jeffrey4l | hmm | 14:41 |
| *** khamtamtun has quit IRC | 14:41 | |
| duonghq | thank you sdake, so I guess that I should ping rhallisey and ask him add me to the list? | 14:41 |
| rhallisey | I'll add you | 14:42 |
| duonghq | thank you rhallisey | 14:42 |
| *** khamtamtun has joined #openstack-kolla | 14:42 | |
| *** khamtamtun has quit IRC | 14:43 | |
| sean-k-mooney | incidentally i was not aware that https://review.openstack.org/#/c/369023/ had merged | 14:43 |
| *** jtriley has joined #openstack-kolla | 14:44 | |
| sean-k-mooney | i guess if you runn cleanup-contiaenrs then cleanup-host it would have cause an issue as the contianer would not be running | 14:45 |
| *** chas_ has joined #openstack-kolla | 14:45 | |
| sdake | somehow i got spg gold preferred | 14:47 |
| sdake | gotta see how that happened | 14:47 |
| sdake | i guess that is rbergeron 's spg account | 14:49 |
| sdake | duonghq nah just add your name in the review | 14:49 |
| sdake | oh ok looks like rhallisey has it | 14:49 |
| sdake | sorry, read top to bottom ;) | 14:49 |
| *** chas_ has quit IRC | 14:50 | |
| *** TxGirlGeek has joined #openstack-kolla | 14:50 | |
| egonzalez90 | if i'm correct, neutron_openvswitch_controll the creation of tap devices into ovs, also is executed before starting neutron-openvswitch-agent to clean older devices. | 14:51 |
| openstackgerrit | narasimha18sv proposed openstack/kolla: update dispatcher configurations for database backend https://review.openstack.org/397089 | 14:52 |
| *** inc0 has joined #openstack-kolla | 14:52 | |
| srwilkers | sdake: yeah, sorry | 14:52 |
| sdake | inc0 need some =1s plz | 14:52 |
| srwilkers | sdake: need to add it | 14:52 |
| inc0 | gmorning | 14:52 |
| sdake | +1z | 14:52 |
| inc0 | sdake, linkz plz | 14:52 |
| egonzalez90 | nova ask neutron-openvswitch-agent to create the ports when new instances are scheduled. am i right sean-k-mooney ? | 14:52 |
| sdake | https://review.openstack.org/396903 | 14:52 |
| sdake | https://review.openstack.org/396901 | 14:53 |
| inc0 | btw I think we got solid plan with infra to get docker registry in infra | 14:54 |
| inc0 | that means we can make voting gates | 14:54 |
| sdake | how does getting docker registry in infra make voting gates | 14:54 |
| sdake | maybe voting gates for kolla-ansible | 14:54 |
| inc0 | no, both I reckon | 14:55 |
| inc0 | let me explain | 14:55 |
| sdake | i struggle to see how we can vote gate on building | 14:55 |
| inc0 | for kolla-ansible ofv | 14:55 |
| inc0 | so amount of changes done to dockerfiles now are relatively small | 14:55 |
| inc0 | majority of changes are ansible changes | 14:55 |
| inc0 | so if upstream stuff breaks, I'd be ok with holding these few patches until upstream is fixed | 14:56 |
| inc0 | again - not a lot of changes so smaller impact, we still can deploy ansible/k8s | 14:56 |
| *** matrohon has quit IRC | 14:56 | |
| sdake | ya i get how with a registry per region kolla-ansible could easily be voting | 14:56 |
| sdake | which is sweet | 14:56 |
| inc0 | and if gate can't build gates submitter can't build as well | 14:56 |
| sdake | still struggling on kolla repo itself ;) | 14:56 |
| inc0 | therefore not-tested patches | 14:57 |
| inc0 | therefore -1 on that account alone | 14:57 |
| sean-k-mooney | egonzalez90: nova is respocably for doing the L1 connectivity so is adds the port to ovs via os-vif | 14:57 |
| sdake | inc0 often the gate hesinbug fails | 14:57 |
| sdake | not because of any particular problem, but for example, it runs on rax-iad ;) | 14:57 |
| inc0 | recheck is still a thing | 14:57 |
| sdake | i guess that issue is orthognal | 14:58 |
| sdake | well anyway do as you please ;) | 14:58 |
| inc0 | will make ML discussion about that | 14:58 |
| sean-k-mooney | egonzalez90: so no the neutron openvswaci agent is not respocibly for adding tap devices to ovs | 14:58 |
| inc0 | but I see that as an option | 14:58 |
| inc0 | also we need to make gates on kolla changes that will post to kolla-ansible repo | 14:59 |
| inc0 | I mean to retain deploy gates in kolla | 14:59 |
| inc0 | somehow | 14:59 |
| sdake | huh | 14:59 |
| inc0 | not as regular gates | 15:00 |
| inc0 | but we need to make sure that change in kolla itself won't break deployments | 15:00 |
| *** tonanhngo has joined #openstack-kolla | 15:00 | |
| sdake | that willl be a bit tricky as sometimes kolla changes will depend on kolla-ansible changes which are unmerged | 15:00 |
| inc0 | kolla should never depend on kolla-ansible | 15:01 |
| sdake | that is what you just proposed | 15:01 |
| inc0 | ok, I guess that's true, but well, some feedback should be there | 15:01 |
| inc0 | maybe non-voting, but still, a feedback | 15:01 |
| inc0 | also if that's the case you'd block merging whole thing | 15:02 |
| inc0 | as merging thing to kolla will break kolla-ansible (with voting gates, bad) | 15:02 |
| inc0 | and probably kolla-k8s | 15:02 |
| *** tonanhngo has quit IRC | 15:02 | |
| inc0 | which is no-no | 15:02 |
| sdake | ya repo split is a charlie foxtrot | 15:02 |
| sdake | good luck - iwarned ya all :) | 15:02 |
| inc0 | still, has to happen | 15:03 |
| inc0 | changes +1d | 15:03 |
| sdake | thx | 15:03 |
| sdake | that was half the hard part | 15:03 |
| sdake | the other half is making the gates work again properly | 15:03 |
| inc0 | gonna check with infra about registry | 15:04 |
| inc0 | as registry would make it super simple | 15:04 |
| openstackgerrit | Wei Cao proposed openstack/kolla: Fix ironic-base Dockerfile https://review.openstack.org/397235 | 15:04 |
| sdake | inc0 btw today is release week | 15:06 |
| inc0 | ahh 3.0.1? | 15:06 |
| sdake | nah, 4.0.0.0b1 | 15:06 |
| inc0 | ok, I'll tag this one | 15:06 |
| inc0 | damn it's fast | 15:06 |
| sdake | were you going to do prior to after repo split? | 15:06 |
| sean-k-mooney | inc0: we are already on 3.0.2 i think on mitaka | 15:06 |
| sdake | ya shortened 4 month schedule | 15:06 |
| *** f13o_ has joined #openstack-kolla | 15:06 | |
| inc0 | sdake, ideally after | 15:07 |
| sdake | inc0 cool | 15:07 |
| inc0 | let's try to split before so all 4.0.0 changes will be clean | 15:07 |
| sdake | inc0 there is a clause in the gov repo that says if a repo isn't released on schedule - it isn't part of the release | 15:07 |
| sdake | i am unsure how this works with repo splits, but better safe then sorry :) | 15:07 |
| inc0 | yeah agree | 15:08 |
| inc0 | I'm not sure if we ever had repo split in openstack | 15:08 |
| sdake | there have been plenty | 15:08 |
| sdake | hence the good guidance i recieved from the infra and release teams | 15:09 |
| sdake | my original approach would have created a real mess | 15:09 |
| sdake | always beset to ask for for advice from the pros ;) | 15:09 |
| inc0 | ok thats cool, we're not the firsts for a change | 15:09 |
| *** f13o__ has quit IRC | 15:10 | |
| sdake | with depends_on and needed_by we might be able to get cross-repo gating working | 15:10 |
| sdake | I'm not sure how those flags work under the covers wrt gate jobs | 15:10 |
| sdake | its sure to frustrate the dev team tho if that is the solution :) | 15:11 |
| inc0 | what we can do is to have git submodule | 15:12 |
| inc0 | and keep kolla gates in kolla | 15:12 |
| inc0 | until we have infra registry | 15:12 |
| inc0 | then we use registry in ansible and drop build gates from it | 15:13 |
| *** jtriley has quit IRC | 15:13 | |
| sdake | i'm not sure submodules are supported by gerrit | 15:14 |
| sdake | what tests the build in your above scenario inc0? | 15:14 |
| sdake | (i.e. tests the build works properly) | 15:14 |
| inc0 | kolla | 15:14 |
| sdake | you siad remove gates from kolla repo | 15:15 |
| inc0 | deploy gates | 15:15 |
| sdake | the reason those build gates are there is to test that the build works | 15:15 |
| inc0 | we keep build ofc | 15:15 |
| *** jtriley has joined #openstack-kolla | 15:15 | |
| sdake | oh right, we dont need build gates in kolla-ansible at all | 15:15 |
| inc0 | deploy gates goes to kolla-ansible, build stays in kolla | 15:15 |
| sdake | if there is a registry in the middle | 15:15 |
| inc0 | only thing that's hard is how to put images for deploy gates before we get registry | 15:16 |
| sdake | note i didn't do any gate work in the repo split | 15:16 |
| sdake | and would like to keep it that way | 15:16 |
| sdake | atm that means rebuilding them inc0 ;) | 15:16 |
| inc0 | but will you have kolla code in kolla-ansible gates? | 15:16 |
| sdake | inc0 i think the proposal that jeffrey4l hd was to do a git pull on the kolla repo | 15:17 |
| *** coolsvap has quit IRC | 15:17 | |
| sdake | or pip install it | 15:17 |
| *** tonanhngo has joined #openstack-kolla | 15:17 | |
| sdake | or something | 15:17 |
| sdake | not real clear tbh ;) | 15:17 |
| sdake | Jeffrey4l said he would fix the gates so they work | 15:17 |
| openstackgerrit | zhubingbing proposed openstack/kolla: Ansible-ize OpenStack Designate https://review.openstack.org/353261 | 15:17 |
| sdake | i can help there if needed | 15:17 |
| inc0 | maybe we'll get registry quick enough | 15:17 |
| sdake | i've been asking for a year | 15:17 |
| inc0 | it's really fast to set it up | 15:17 |
| Jeffrey4l | after split, the kolla repo should trigger the kolla-ansible and kolla-kuberneter jobs. | 15:17 |
| sdake | not sure quick is the adjective i'd use ;) | 15:18 |
| inc0 | sdake, look at Fridays log at infra | 15:18 |
| sdake | inc0 i trust if you say they are working on it, they are | 15:18 |
| *** tonanhngo has quit IRC | 15:18 | |
| sdake | inc0 i asked for a long time, but had no concrete answer as to how to do the job | 15:18 |
| sdake | and neither did they | 15:18 |
| inc0 | we'll start with having one | 15:18 |
| inc0 | on one of mirror nodes | 15:19 |
| *** f13o_ has quit IRC | 15:31 | |
| *** f13o_ has joined #openstack-kolla | 15:32 | |
| rhallisey | sdake, https://github.com/openstack/python-k8sclient | 15:33 |
| *** tonanhngo has joined #openstack-kolla | 15:34 | |
| *** tonanhngo has quit IRC | 15:34 | |
| sdake | rhallisey ya - who do you think got that made ;) | 15:35 |
| rhallisey | dims | 15:35 |
| sdake | nah, it was actually madhuri | 15:36 |
| duonghq | anybody give kubeadm a try, I think it's quite cool | 15:36 |
| sdake | at my begging and pleading | 15:36 |
| duonghq | much easier then previous method | 15:36 |
| sdake | i spent countless hours with madhuri making that swagger shit work | 15:37 |
| sdake | what a pain in the ass that was | 15:37 |
| sdake | the problem is, the code needs to be regenned each time the api changes | 15:37 |
| rhallisey | well we need it to be updated to1.4 | 15:37 |
| sdake | and swagger produces a disaster of code | 15:37 |
| sdake | rhallisey after swagger gets done, it requires alot of manual intervention to get things rolling again | 15:38 |
| sdake | i'm pretty sure magnum gave up on using that | 15:38 |
| sdake | let me go ask | 15:38 |
| rhallisey | we need to contact kube one way or another | 15:38 |
| rhallisey | maybe that's not the best way | 15:38 |
| *** matrohon has joined #openstack-kolla | 15:38 | |
| sdake | ya popen to kubectl :) | 15:38 |
| sdake | its sort of hacky but gets the job done | 15:38 |
| rhallisey | ya figured | 15:39 |
| rhallisey | otherwise we're stuck maintaing that | 15:39 |
| sdake | stuck maintaining which - a native python library to the rest api? | 15:39 |
| *** zhubingbing_ has quit IRC | 15:39 | |
| sdake | in the past i really thought a native python librar ywas the only way to go | 15:40 |
| sdake | but given how the rest api has evolved in lubernetes, I think the best way is just to use the native client | 15:40 |
| rhallisey | kube is going to move so fast, if we have to contantly work on generating this and fixing it | 15:40 |
| rhallisey | it will take a lot of time | 15:40 |
| sdake | and since we are packaging the micro-controllers in a contianer, packaging kubectl is no big deal | 15:40 |
| sdake | in the use case of magnum, putting kubectl on the system was more of a big deal | 15:41 |
| rhallisey | plus python is first pass | 15:41 |
| sdake | i'd still recommend avoiding useing a python interface to kubernetes | 15:43 |
| rhallisey | popen it is | 15:44 |
| sdake | its actually Subprocess | 15:44 |
| sdake | but under the hood is popen | 15:44 |
| sdake | you starting to write code? | 15:44 |
| rhallisey | I'm putting the pieces together | 15:45 |
| rhallisey | trying to figure out what goes in the operator base class and all the way down | 15:45 |
| *** jheroux has joined #openstack-kolla | 15:46 | |
| * dims peeks | 15:48 | |
| duonghq | I still cannot figure out how to bring cluster up again once it is down | 15:48 |
| duonghq | (w/ kubeadm) | 15:48 |
| rhallisey | duonghq, I've had some trouble with kubeadm | 15:48 |
| rhallisey | I think you just kubeadm reset | 15:49 |
| rhallisey | then remake it | 15:49 |
| duonghq | rhallisey, last time I use reset, something go wrong, I'll give it one more try :) | 15:49 |
| *** Pavo has quit IRC | 15:50 | |
| *** Pavo has joined #openstack-kolla | 15:51 | |
| *** Pavo has quit IRC | 15:53 | |
| *** tonanhngo has joined #openstack-kolla | 15:54 | |
| *** logan- has quit IRC | 15:54 | |
| *** tonanhngo has quit IRC | 15:55 | |
| *** dgonzalez is now known as dgonzalez__ | 15:55 | |
| *** dgonzalez__ is now known as dgonzalez | 15:55 | |
| *** Pavo has joined #openstack-kolla | 15:56 | |
| Pavo | morning | 15:57 |
| duonghq | moring Pavo | 15:57 |
| Pavo | morning duonghq | 15:58 |
| *** neilus has joined #openstack-kolla | 16:00 | |
| *** logan- has joined #openstack-kolla | 16:01 | |
| *** neilus has quit IRC | 16:05 | |
| *** tonanhngo has joined #openstack-kolla | 16:07 | |
| *** DTadrzak has quit IRC | 16:09 | |
| sdake | hey dims | 16:14 |
| sdake | rhallisey put in the base class the stuff that is needed | 16:16 |
| *** lrensing has joined #openstack-kolla | 16:16 | |
| sdake | rhallisey perhaps I should write the base class ;-) | 16:16 |
| lrensing | morning everyone | 16:16 |
| rhallisey | sdake, ya I'm listing what is needed | 16:16 |
| sdake | listing where | 16:16 |
| sdake | is there a blueprint somwheres? | 16:16 |
| rhallisey | no let me make an etherpad | 16:16 |
| rhallisey | or bp | 16:17 |
| sdake | lets use etherpad for the brainstorming about the base class | 16:17 |
| sdake | and link bp to it | 16:17 |
| rhallisey | https://etherpad.openstack.org/p/operator-base-class | 16:17 |
| rhallisey | k | 16:17 |
| sdake | i think we also need to make a prototype operator | 16:17 |
| pbourke | sp_: hi just saw your message. I dont know enough about k8s operators to compare | 16:18 |
| pbourke | sp_: from what I can tell operators will orchestrate the bring up of the cluster, prechecks simply check that things are as they should be in order to do a successful deploy. I dont know how they'll fit into the k8s model | 16:19 |
| rhallisey | sp_, https://review.openstack.org/#/c/392257/ | 16:21 |
| sdake | pbourke speaking of operators | 16:23 |
| sdake | pbourke you use a custom db in kolla correct? | 16:23 |
| pbourke | sdake: yes we use mysqlcluster | 16:23 |
| duonghq | rhallisey, when I do kubeadm reset on master nodes, every resource I added also went, right? | 16:23 |
| *** khamtamtun has joined #openstack-kolla | 16:23 | |
| rhallisey | not sure if you have to reset on each node | 16:23 |
| *** unicell has quit IRC | 16:24 | |
| kfox1111 | monrning | 16:24 |
| *** absubram has joined #openstack-kolla | 16:24 | |
| *** neilus has joined #openstack-kolla | 16:24 | |
| sdake | pbourke which python client does that use? | 16:24 |
| duonghq | rhallisey, reset on minion is fine, but seem that it's delete everything, so if it's done on master nodes, resource has no change, I think I should do some more check | 16:24 |
| pbourke | sdake: same as mariadb | 16:24 |
| sdake | pbourke cool thanks! | 16:25 |
| sdake | pbourke see etherpad above line 5 for reason i asked the Q | 16:25 |
| pbourke | sdake: thanks | 16:25 |
| duonghq | rhallisey, from kubeadm man: reset Run this to revert any changes made to this host by 'kubeadm init' or 'kubeadm join'. | 16:26 |
| duonghq | so it should not be used on master nodes | 16:26 |
| duonghq | *node | 16:27 |
| *** chas_ has joined #openstack-kolla | 16:27 | |
| *** f13o__ has joined #openstack-kolla | 16:28 | |
| sdake | rhallisey question re init container | 16:28 |
| sdake | does it run only once | 16:28 |
| sdake | or every time the container is scheduled | 16:28 |
| kfox1111 | nice: https://github.com/stackanetes/kubernetes-entrypoint/issues/12 | 16:28 |
| sdake | kfox1111 or that q for you :) | 16:29 |
| kfox1111 | is an init for the pod. | 16:29 |
| kfox1111 | its | 16:29 |
| kfox1111 | so whenever a pod is created, it runs. | 16:29 |
| rhallisey | every time | 16:30 |
| rhallisey | ^ ya what kfox1111 said | 16:30 |
| rhallisey | s/container/pod/ | 16:30 |
| kfox1111 | the subtle thing is when a container in the pod restarts, it does not. | 16:30 |
| kfox1111 | so, once, on pod creation. | 16:31 |
| kfox1111 | usually whoe pods are deleted/recreated though, and so it hapens every time in that case. | 16:31 |
| *** f13o_ has quit IRC | 16:31 | |
| sdake | kfox1111 in the context of openstack | 16:31 |
| sdake | once you create a pod, its a permant thign no? | 16:31 |
| inc0 | soo next step, how do we make helm give deps to entrypoint? | 16:32 |
| kfox1111 | its great for setting things up for the pod. its ok for orchestration between pods but bad for workflow. | 16:32 |
| kfox1111 | "pods are mortal. they are born, live for a while, and die" | 16:32 |
| sdake | ok so operator still reins supreme for the use case | 16:32 |
| sdake | live for 5000 years is the line ;) | 16:32 |
| rhallisey | op is also a pod | 16:33 |
| inc0 | they live, die and resurrect | 16:33 |
| sdake | rather for use case of db and user setup via keystone | 16:33 |
| kfox1111 | "replication controllers" (and other objects) "can give the system an apearance of immortality by replacing pods as they die." | 16:33 |
| inc0 | like Jesus, just proven | 16:33 |
| inc0 | ;) | 16:33 |
| sdake | WWJD | 16:33 |
| inc0 | ok, j/k | 16:33 |
| kfox1111 | :) | 16:33 |
| *** Jeffrey4l has quit IRC | 16:33 | |
| duonghq | in other words, it should be cattle, not pets? | 16:34 |
| inc0 | pods in k8s yes | 16:34 |
| kfox1111 | best suited to cattle, yes. | 16:34 |
| sdake | the database is definately a pet | 16:34 |
| inc0 | but not everything can be | 16:34 |
| kfox1111 | daemonsets/petsets (now called statefulsets) kind of blur the lines a bit there. | 16:34 |
| duonghq | so, things which need persistence should not pets? | 16:34 |
| sdake | i think blur is the wrong word - they implement pets :) | 16:35 |
| duonghq | *cattle | 16:35 |
| kfox1111 | no, not quite. | 16:35 |
| kfox1111 | so there are a few pieces to pets. | 16:35 |
| inc0 | legs...head... | 16:35 |
| kfox1111 | 1. state. | 16:35 |
| inc0 | ok, I'm doing it again | 16:35 |
| inc0 | I'll stop writing now. | 16:35 |
| kfox1111 | 2. singleton pattern | 16:35 |
| openstackgerrit | Jeffrey Zhang proposed openstack/kolla: Add neutron vpnaas code into neutron-server container https://review.openstack.org/397015 | 16:35 |
| *** neilus has quit IRC | 16:36 | |
| kfox1111 | 1. can be handled by making sure you can give state back when requested. like with ceph rbd volumes. | 16:36 |
| duonghq | I'm running out of energy, will try to catch up with you guys via IRC log | 16:36 |
| kfox1111 | there's a 3rd. too. I guess. addressing. | 16:36 |
| sdake | duonghq sleep well my friend | 16:36 |
| duonghq | good night | 16:36 |
| rhallisey | night | 16:37 |
| *** duonghq has quit IRC | 16:37 | |
| kfox1111 | 3. is delt with with floating ip's, or dns entries that are dynamic. | 16:37 |
| sdake | time for some 300 | 16:37 |
| *** fragatina has quit IRC | 16:37 | |
| sdake | or johnnie cash | 16:37 |
| sdake | not sure which :) | 16:37 |
| kfox1111 | 2 is the hardest, and usually traditional architectures build custering into the system. | 16:37 |
| kfox1111 | such as rabbit clustering or mariadb clustering. | 16:37 |
| kfox1111 | so the thinest pet you can usucally make is one where you minimize all 3 of those things. | 16:38 |
| kfox1111 | if you can minimize #1 and #, its barely a pet. people notice if it dies, but if you can put it back quickly, like with k8s can with self heeling, | 16:38 |
| kfox1111 | it may not be a bad solution. | 16:38 |
| sdake | i was thinking operators should spawn other operators depending on config | 16:39 |
| kfox1111 | "#1 and #3" | 16:39 |
| kfox1111 | sdake: yes. the compute kit one would spawn the other operators in the kit. | 16:39 |
| sdake | kfox i was thinking all the way down | 16:39 |
| inc0 | by the way, I also see value of having OOB operators that will manage deployed openstack externallyu | 16:40 |
| sdake | oh you just said that | 16:40 |
| kfox1111 | sdake: I'm not sure we need more then 2 layers. | 16:40 |
| sdake | i thought you meant nova-operator | 16:40 |
| Pavo | is kolla-ansible certificates suppose to be ran with the inventory file or just by itself? | 16:40 |
| sdake | inc0 totally agree | 16:40 |
| inc0 | with clever dependency operators we'll be able to do upgrades and reconfigure with them as well | 16:40 |
| sdake | pavo with inventory if your setting up tls | 16:40 |
| inc0 | on the other hand, init container will get us to deploy *really* fast | 16:40 |
| Pavo | ok ty | 16:40 |
| kfox1111 | compute kit operator and (nova/glance/cinder/neutron/mariadb/rabbitmq /(optional keystone)) | 16:40 |
| Pavo | before deployment or after? | 16:40 |
| inc0 | kfox1111, so I think we can pull off generic dependency management operator | 16:41 |
| inc0 | that will take deps and wait for them to finish | 16:41 |
| sdake | pavo prior would be my guess, but I'm not certain it matters | 16:41 |
| Pavo | ok | 16:41 |
| kfox1111 | inc0: mostly agree. for deployment, all the service ones should look pretty similar. | 16:41 |
| sdake | pavo what you really want is non-self signed certs | 16:41 |
| kfox1111 | for upgrades, all bets are off. | 16:41 |
| rhallisey | inc0, idk if that's the model we're aiming for | 16:42 |
| inc0 | not necessarly | 16:42 |
| inc0 | in fact, if we have external operator constantly autohealing | 16:42 |
| sdake | ok i'd recommend focusing on deploy workflow for now | 16:42 |
| rhallisey | that would be the option 1 in the spec | 16:42 |
| Pavo | well for testing purposes self-signed is fine | 16:42 |
| sdake | and shoe-horning upgrade in later | 16:42 |
| sdake | pavo roger | 16:42 |
| kfox1111 | inc0: no. | 16:42 |
| inc0 | upgrade of nova for example will be -> remove nova config maps, wait for them to reappear -> remove nova conductor -> wait for them to be restored -> remove rest of services | 16:42 |
| kfox1111 | operators shouldn't be trying to heal things I think. k8s should do that already. | 16:43 |
| *** khamtamtun has quit IRC | 16:43 | |
| Pavo | also getting an error when generating certs using inventory file before deployment http://paste.openstack.org/show/589147/ | 16:43 |
| rhallisey | ya k8s does the healing | 16:43 |
| inc0 | well, operators will manage k8s | 16:43 |
| inc0 | pods - yeah k8s does the healing | 16:43 |
| inc0 | configmaps - not so much | 16:43 |
| sdake | kfox1111 i think operators can provide value in the healing - unless kubernetes self-healing has grown some wings since i looked at it last | 16:43 |
| kfox1111 | inc0: I guess this is one area we need to flesh out a bit. | 16:44 |
| kfox1111 | are operators workflow, or workflow+config management? | 16:44 |
| sdake | kfox1111 that is the point of ryan's base class blueprint and etherpad | 16:44 |
| inc0 | kfox1111, so it's interesting to me as I was thinking of this particular topic in heat | 16:44 |
| rhallisey | sdake, we need to be careful here though. We can't solve every problem | 16:44 |
| kfox1111 | I prefer to keep all the pieces orthoganal, but I can see people wanting to mix the two. | 16:44 |
| inc0 | now I have a chance to implement and test it out:) | 16:44 |
| rhallisey | https://etherpad.openstack.org/p/operator-base-class | 16:44 |
| rhallisey | ^ | 16:44 |
| Pavo | gonna try after deployment | 16:45 |
| rhallisey | we need to define the base operator class | 16:45 |
| sdake | dump your ideas in ryan's etherpad plz | 16:45 |
| inc0 | I'd start by doing init container entrypoint | 16:45 |
| inc0 | as (opposed to operator) we already know how to do it | 16:45 |
| inc0 | and it will work | 16:45 |
| kfox1111 | really don't want to see workflow doene in the pods. | 16:46 |
| kfox1111 | really really dont. | 16:46 |
| inc0 | if I'm right (with my not-so-fleshed-out-idea) we'll be able to easily plug my operator to working env | 16:46 |
| sdake | kfox1111 you mean the operator pod? | 16:46 |
| inc0 | well, it's not really workflow | 16:46 |
| *** lrensing has quit IRC | 16:46 | |
| inc0 | and operator is a pod | 16:46 |
| sdake | kfox1111 thatis the purpose of the operator pod, to do workflow | 16:46 |
| kfox1111 | workflow belongs in an operator. deployment logic shoudl be kept out of the pods. | 16:46 |
| inc0 | waiting for deps is not a workflow | 16:46 |
| kfox1111 | minimal dependency logic may belong in an init-container though. | 16:47 |
| rhallisey | operator is a workflow. I'm confused | 16:47 |
| inc0 | and it's true anyway, we just make it more robust with entrypoint | 16:47 |
| sdake | i disagree, dep management is a key part of workflow | 16:47 |
| inc0 | key part, but not *a workflow* | 16:47 |
| kfox1111 | so, let me discus a concrete example maybe.... | 16:47 |
| inc0 | it's like wheel is key part of a car, but not really car on it's own | 16:47 |
| inc0 | and wheels make perfect sense in stuff that's not a car | 16:47 |
| kfox1111 | say we have a nova-compute pod. | 16:48 |
| sdake | inc0 bad example dude, we are not ubilding a car;) | 16:48 |
| kfox1111 | it depends on openvswitch and one or more neutron daemonsets running on the node. | 16:48 |
| inc0 | sdake, metaphor... | 16:48 |
| kfox1111 | it also depends on nova-api, and keystone, and databases being inited in mariadb, and endpoints created in keystone, etc. | 16:49 |
| sdake | any metaphor that uses the term "wheel" has all kinds of other connotations :) | 16:49 |
| *** khamtamtun has joined #openstack-kolla | 16:49 | |
| inc0 | I don't thionk nova-cpu depends on openvswitch | 16:49 |
| kfox1111 | inc0: indirectly. | 16:49 |
| *** lrensing has joined #openstack-kolla | 16:49 | |
| inc0 | I'd say full openstack deployment depends on nova and neutron, nova depends on database, neutron depends on nova | 16:49 |
| inc0 | multiple layers in same graph | 16:49 |
| kfox1111 | neutron doesn't depend on nova. | 16:49 |
| inc0 | init container will only deal with direct deps | 16:49 |
| kfox1111 | I run nodes without nova but with neutron. :) | 16:50 |
| sdake | kfox1111 not accurate - neutron and nova have a circular dependency ;) | 16:50 |
| inc0 | ok, "deployment complete" does | 16:50 |
| Pavo | ok kolla-ansible certificates has to be ran by itself and without inventory file included, if yo have tls enabled in globals it will fail looking for the certs in /etc/kolla/certificates dir | 16:50 |
| kfox1111 | sdake: incorrect. I do run production systems with just neutron. | 16:50 |
| inc0 | nova doesn't depend on neutron, neutron doesn't depend on nova | 16:50 |
| sdake | kfox1111 we are both correct | 16:50 |
| kfox1111 | doesnt' matter though. getting off the rails. | 16:50 |
| inc0 | but to be able to say deployment is done, we need both up | 16:50 |
| kfox1111 | for nova vms to launch, the neutron bits must be up and working. | 16:51 |
| *** shardy has quit IRC | 16:51 | |
| kfox1111 | so nova-compute -> neutron stuff. | 16:51 |
| inc0 | but we don't launch vm before "Deployment complete" | 16:51 |
| kfox1111 | wait. we're confusing things. | 16:51 |
| *** bmace has quit IRC | 16:51 | |
| kfox1111 | lets back up a sec and define some terms. | 16:51 |
| inc0 | kfox1111, I get that init container will only work on local stuff | 16:51 |
| *** bmace has joined #openstack-kolla | 16:52 | |
| kfox1111 | There's instantiating pods, and deploying openstack. | 16:52 |
| inc0 | but again, we need something | 16:52 |
| kfox1111 | deploying openstack happens once at the begining. | 16:52 |
| kfox1111 | pods may come and go over the life of the cluster. | 16:52 |
| kfox1111 | so init-containers can rerun on a node multiple times over the cloud's life. | 16:52 |
| kfox1111 | while deployment happens once. | 16:52 |
| sdake | init-containers then are not a solution for workflow | 16:53 |
| kfox1111 | right. | 16:53 |
| kfox1111 | we could put some deployment logic in init-containers, but its wasteful. | 16:53 |
| kfox1111 | as deployment happens once, and init containers happen a lot more. | 16:53 |
| sdake | wasteful how? | 16:53 |
| kfox1111 | so each time the init containers would be going through a bunch of code that will never not be true after deployment's done. | 16:54 |
| sdake | i see wasteful in the nanosecond range ;) | 16:54 |
| Daviey | sdake: Do you know who is responsible for docker hub kollaglue? | 16:54 |
| sdake | Daviey i am, although we have moved to the kolla namespace | 16:54 |
| kfox1111 | so, looking to see if nova-createdb gets run in an init container imo is not a good place to do it. | 16:54 |
| Daviey | sdake: We should probably do analysis for CVE-2016-6664 / CVE-2016-5617 kollaglue images | 16:55 |
| kfox1111 | just make sure the operator does that before creating any pods that requrie it and we're good. | 16:55 |
| sdake | Daviey i dont know what that cve is | 16:55 |
| kfox1111 | then the pods never have to probe k8s for jobs. | 16:55 |
| sdake | Daviey i am not on the security team... | 16:55 |
| kfox1111 | sdake: its also wasteful in another way. | 16:55 |
| Daviey | sdake: BECAUSE IT DOESN'T HAVE A CATCHY NICKNAME AND FANCY ARTWORK | 16:55 |
| kfox1111 | say I have 300 nodes, and the power goes out. | 16:55 |
| sdake | Daviey huh? | 16:56 |
| kfox1111 | when they start back up, each would hammer k8s looking for nova-createdb job. pointlessly. | 16:56 |
| sdake | Daviey what sshould be done is the kollaglue account should be deleted entirely | 16:56 |
| sdake | or its contents thereof | 16:56 |
| kfox1111 | its a scaling issue. | 16:56 |
| Daviey | sdake: Sorry, taking the %!%$ out of the recent trend to have fancy names for vulnerabilities | 16:56 |
| sdake | Daviey if its public can you provide a link, if its private, I dont have access to the CVEs | 16:57 |
| sdake | inc0 did you ever reform a security vuln mgmt team for kolla? | 16:58 |
| Daviey | sdake: Just gone public, https://legalhackers.com/advisories/MySQL-Maria-Percona-PrivEscRace-CVE-2016-6663-5616-Exploit.html AND https://legalhackers.com/advisories/MySQL-Maria-Percona-RootPrivEsc-CVE-2016-6664-5617-Exploit.html | 16:58 |
| inc0 | no, but we did start vuln management process | 16:58 |
| inc0 | our docs are lost somewhere tho;) | 16:58 |
| Daviey | sdake: i've not done a review of it yet.. but we should probably do some analysis. | 16:59 |
| sdake | inc0 could you get a team formed | 16:59 |
| sdake | inc0 vuln mgmt is a team thing not a SPOF thing :) | 16:59 |
| inc0 | it's formed | 16:59 |
| sdake | i mean for kolla specifically | 17:00 |
| inc0 | you're part of it | 17:00 |
| inc0 | you formed it.. | 17:00 |
| sdake | right, i think some people dropped out of participation since the vuln mgmt tagging took longer then expected | 17:00 |
| inc0 | I don't think it was tag issue | 17:00 |
| inc0 | but we need process around this, I'll make sure to get it handled after we're done with 4.0.0 | 17:01 |
| sdake | Daviey looking at first one, i'm not sure which versions of mysql we distribute on dockerhub | 17:01 |
| inc0 | b1 | 17:01 |
| sdake | inc0 cool thanks ;) | 17:01 |
| Daviey | inc0: if you are doing something sec' related, can you ping me? I'd like to help. | 17:01 |
| sdake | Daviey i can tell you - but if its the wrong version, we are totally reliant on upstraem for our mariadb implementation | 17:01 |
| inc0 | will do Daviey | 17:02 |
| Daviey | sdake: well, we are dependant on a semi-static image that we created, right? | 17:02 |
| sdake | Daviey we have a coresec team in kolla | 17:02 |
| sdake | Daviey we can rebuild | 17:02 |
| Daviey | sdake: exactly | 17:02 |
| inc0 | we need a good streamline for CVE, with or without fancy names, to be fixed in Kolla | 17:02 |
| *** ayoung has quit IRC | 17:02 | |
| sdake | Daviey but distros need to do the job of making the rpms/debs available | 17:02 |
| Daviey | well yeah! :) | 17:02 |
| sdake | do you know if that has been done yet? | 17:02 |
| *** matrohon has quit IRC | 17:03 | |
| Daviey | I'm saying, we need to decide if we need to respin. :) | 17:03 |
| Daviey | sdake: not looked at it at all yet.. but i will this evening | 17:03 |
| sdake | Daviey wht help do you need from me? | 17:03 |
| Daviey | sdake: just wanted to know who was the point of contact for docker hub account | 17:03 |
| Pavo | sdake can you get to https://ddi.hopto.org? | 17:05 |
| sdake | Daviey typically coolsvap has been taking on the responsibility of managing it | 17:05 |
| inc0 | Daviey, all of core team has dockerhub access | 17:05 |
| sdake | inc0 not all core team | 17:05 |
| sdake | inc0 only those that ask for it | 17:05 |
| inc0 | ok, well, all of core team will get it if they want it | 17:05 |
| sdake | ya i'm not a mind reader on people's account names, so i have a hrad time keeping that up to date | 17:06 |
| sdake | Daviey email of your dockerhub acct and I'll add you | 17:06 |
| Daviey | oh | 17:07 |
| Pavo | can someone try and see if they can get to https://ddi.hopto.org | 17:07 |
| sdake | pavo stuck at connecting | 17:08 |
| sdake | pavo i think a firewall issue possibly | 17:08 |
| Pavo | hmmm | 17:08 |
| Pavo | ok one sec | 17:08 |
| sdake | ERR_CONNECTION_TIMED_OUT | 17:08 |
| Daviey | sdake: email@daviey.com / daviey | 17:08 |
| sdake | do you have a dockerhub account Daviey ? | 17:08 |
| Daviey | sdake: Yep, with those details | 17:09 |
| rhallisey | kfox1111, are you pink in the etherpad? | 17:09 |
| kfox1111 | yeah. | 17:09 |
| kfox1111 | we should add d names | 17:09 |
| kfox1111 | doing at the bottom. | 17:09 |
| *** sdake has quit IRC | 17:10 | |
| *** chas__ has joined #openstack-kolla | 17:10 | |
| rhallisey | kfox1111, what do you expect the openstack operator to do with regards to user specific items | 17:10 |
| rhallisey | what I mean is, do you see the openstack operator as a gateway for interacting with all the other operators? | 17:11 |
| rhallisey | or do you interact at each level? | 17:11 |
| rhallisey | or both | 17:11 |
| *** egonzalez90 has quit IRC | 17:11 | |
| *** lrensing has quit IRC | 17:12 | |
| *** fragatina has joined #openstack-kolla | 17:12 | |
| *** chas_ has quit IRC | 17:12 | |
| *** sdake has joined #openstack-kolla | 17:13 | |
| rhallisey | I think right now it's both in the etherpad | 17:13 |
| kfox1111 | rhallisey: the way I am curently thinking: | 17:13 |
| rhallisey | kfox1111, I'm going to make that a little more generic | 17:13 |
| kfox1111 | config is relayed from the user via 3rd party resource creation. | 17:13 |
| kfox1111 | so for the compute-kit operator, its the whole cluster config. | 17:13 |
| kfox1111 | the operator slices that up in to config bits for neutron/glance/cinder/etc, | 17:14 |
| kfox1111 | laucnhes the operators for those services if not there, | 17:14 |
| Pavo | sdake can you try again please | 17:14 |
| kfox1111 | and creates a 3rd party resource for each of neutron/glance/cinder with the config chunks relavent to it. | 17:14 |
| sdake | pavo this is the last place my packets make it to: 16 ga-augu-huh-cmts-1-e6 (24.214.0.34) 77.341 ms 78.242 ms 74.710 ms | 17:15 |
| kfox1111 | the <service>-operator then takes its chunk of config, slices it up further, creates/uploads configmaps based on it, | 17:15 |
| sdake | too bad there isn't a bundled configmap object | 17:15 |
| kfox1111 | ensures the db/rabbit create/bootstrap stuff is done, then helm installs the objects. | 17:15 |
| sdake | i guess that is what your talking of making | 17:16 |
| rhallisey | kfox1111, what if you wanted to skip the opemstack operator? | 17:16 |
| kfox1111 | sdake: bundled configmap? | 17:16 |
| sdake | a bundled configmap would be a whole bunch of cnofigmaps bundled together | 17:16 |
| kfox1111 | rhallisey: then you make 3rd party resources with the config for each and drive those operators that way. | 17:16 |
| kfox1111 | you do exactly what the overarching operator does. | 17:16 |
| sdake | and reigstered with a third party resource | 17:16 |
| kfox1111 | sdake: there is a thing like that. | 17:16 |
| kfox1111 | sdake: you can either do a configmap with multiple files in it, | 17:16 |
| kfox1111 | sdake: or you can create a List object. | 17:17 |
| sdake | kfox1111 tell me more pls | 17:17 |
| *** ayoung has joined #openstack-kolla | 17:17 | |
| kfox1111 | sdake: I use it with kollakube now, when multiple res objects are specified at once. | 17:18 |
| kfox1111 | you can create a list object, and it can contain 1+ other k8s objects. | 17:18 |
| *** Pavo_ has joined #openstack-kolla | 17:18 | |
| sdake | rather then trying to solve world hunger | 17:19 |
| sdake | lets tackle one problem at atime - such as a mariadb operator | 17:19 |
| Pavo_ | sdake can you try again please | 17:19 |
| kfox1111 | do a kollakube tmpl pod neutron-l3-agent-network neutron-opevnswitch-agent-network and you can see an example. | 17:19 |
| sdake | and move up the stack | 17:19 |
| *** Pavo has quit IRC | 17:19 | |
| *** Pavo_ is now known as Pavo | 17:19 | |
| sdake | mariadb + keystone are probably two prime candidates | 17:20 |
| sdake | did we make a decision we are not using mariadb in clustering mode | 17:20 |
| rhallisey | ok right now, openstack operator does 2 things | 17:20 |
| kfox1111 | yeah. I think if we poc those, we will be in pretty good shape. | 17:20 |
| rhallisey | 1) Handle user config options 2) Spawn appropriate operators | 17:20 |
| kfox1111 | sdake: no decision, but I want cluster and not cluster. :) | 17:20 |
| kfox1111 | IE, | 17:21 |
| sdake | kfox1111 have trobule parsing that last part :) | 17:21 |
| openstackgerrit | Merged openstack/kolla: Fix neutron.conf.j2 metadata_workers spelling error https://review.openstack.org/397186 | 17:21 |
| kfox1111 | I'm thinking for service rpc, I want one rabbit pod per service. non stateful. | 17:21 |
| kfox1111 | for ceilometer though, I want a cluster. | 17:21 |
| *** clsacramento has quit IRC | 17:21 | |
| kfox1111 | building blocks, remeber? :) | 17:21 |
| rhallisey | kfox1111, wants everything all the time everywhere | 17:22 |
| rhallisey | :) | 17:22 |
| sdake | in every way :) | 17:22 |
| kfox1111 | I know. I'm kind of needy, arn't I? :) | 17:22 |
| rhallisey | hehe | 17:22 |
| sdake | kfox1111 trust me you don't fit the defn of needy :) | 17:22 |
| kfox1111 | the good news, is I implement the stuff I need, not just ask for it. :) | 17:22 |
| sdake | pavo same story with traceroute | 17:22 |
| kfox1111 | this is kind of why I'm not sure one operator to rule them all would work. | 17:23 |
| kfox1111 | my particular needs, like stated above might not work for everyone. | 17:23 |
| Pavo | sdake how about now? | 17:23 |
| kfox1111 | but keeping workflow seperate from the other building blocks alows us all to work together. :) | 17:24 |
| openstackgerrit | Merged openstack/kolla: Fix placement of policy.json https://review.openstack.org/394260 | 17:24 |
| sdake | pavo its still busted | 17:24 |
| *** eaguilar has quit IRC | 17:25 | |
| Pavo | grrr | 17:25 |
| sdake | kfox1111 much in the way we kept image building separate from workflow | 17:25 |
| rhallisey | kfox1111, I agree, an operator to rule them all won't work | 17:25 |
| kfox1111 | yeah. | 17:25 |
| sdake | kfox1111 people love that about kolla | 17:25 |
| kfox1111 | its a killer feature of kolla. :) | 17:25 |
| kfox1111 | now we just gota do the same for k8s. :) | 17:25 |
| sdake | now we have 3 things | 17:26 |
| kfox1111 | why implement your own k8s objects. just use kolla's. :) | 17:26 |
| sdake | image building, kubernetes config blobs, and workflow | 17:26 |
| sdake | kfox1111 expand on last sentence | 17:26 |
| sdake | i'm not sure i mentioned implementing our own k8s objects | 17:26 |
| sean-k-mooney | has anyone ever had issues with contaienrs being deleted after a host reboot? | 17:26 |
| *** msimonin has quit IRC | 17:26 | |
| sdake | sean-k-mooney never seen that before | 17:27 |
| sdake | sean-k-mooney repeatable? | 17:27 |
| sean-k-mooney | i lost one of my ceph mons after a reboot to fix an out of disk space issue | 17:27 |
| sdake | oh out of disk space | 17:27 |
| sean-k-mooney | am i dont think so | 17:27 |
| sdake | ya docker doesn't handle out of disk space well | 17:27 |
| kfox1111 | sdake: sorry. maybe bad terminology. | 17:27 |
| sdake | all bets are off when you run out of /var/lib/docker space | 17:27 |
| kfox1111 | its the parallel to our docker files. | 17:28 |
| kfox1111 | our k8s object templates. | 17:28 |
| sean-k-mooney | sdake: ya im learning that. i have lost some contianer on 2 of my controller both of which had out of disk space issue on / | 17:28 |
| *** eaguilar has joined #openstack-kolla | 17:28 | |
| kfox1111 | not saying we create custom k8s objectt types, just k8s objects. (deployments, daemonsets) etc for launching openstack in k8s. | 17:28 |
| sdake | kfox1111 right for the most part that is what kolla-kubernetes is atm | 17:29 |
| sdake | however, it lacks workflow | 17:29 |
| *** mgiles has quit IRC | 17:29 | |
| kfox1111 | yeah. | 17:29 |
| sdake | therefore it really lacks a proper user experience | 17:29 |
| kfox1111 | agreed. | 17:29 |
| *** khamtamtun has quit IRC | 17:29 | |
| kfox1111 | we'r'e kind taking the oposite aproach to everyone else. | 17:29 |
| sdake | who said merging workflow and objects together tho? | 17:29 |
| *** khamtamtun has joined #openstack-kolla | 17:29 | |
| sdake | kfox1111 in which way | 17:30 |
| kfox1111 | sap/stackenetes has focused on the small cluster use case to get it to deploy quickly for their prototypes. | 17:30 |
| kfox1111 | I've been focusing on making kolla-kubernetes work for a medium/large system. then working backwards to do the easy to deploy small systems. | 17:31 |
| sdake | mind expanding | 17:31 |
| rhallisey | what kolla-kubernetes will hold that is useful is the operators | 17:32 |
| rhallisey | the operator code that defines how openstack will run | 17:32 |
| kfox1111 | the most useful part actually is the building blocks. | 17:32 |
| kfox1111 | some fols won't use the operators. | 17:32 |
| rhallisey | those are the operators | 17:32 |
| rhallisey | well part of | 17:32 |
| rhallisey | part of the building blocks | 17:32 |
| kfox1111 | some companies will probably form products around kolla-kubernetes that don't use operators. | 17:32 |
| kfox1111 | but all will use the buildign blocks. :) | 17:32 |
| *** nihilifer has quit IRC | 17:32 | |
| *** f13o__ has quit IRC | 17:32 | |
| rhallisey | define what you see as the building blocks | 17:33 |
| inc0 | just please, let's not do repo split yet again;) | 17:33 |
| openstackgerrit | Eduardo Gonzalez proposed openstack/kolla: Tacker Docker configuration https://review.openstack.org/396391 | 17:33 |
| inc0 | kolla-k8s and kolla-k8s-operators;) | 17:33 |
| sdake | inc0 i was just getting ready to say sounds like another repo split ;) | 17:33 |
| kfox1111 | building blocks = our jinja2 templates or our helm packages. | 17:33 |
| rhallisey | eh | 17:33 |
| *** nihilifer has joined #openstack-kolla | 17:33 | |
| inc0 | yo dawg I heard you like repo splits, so I split your splitted repo so you can split while you split | 17:33 |
| rhallisey | I have a slight disagreement | 17:33 |
| rhallisey | the kolla recipes are different than these | 17:34 |
| *** sdake_ has joined #openstack-kolla | 17:34 | |
| rhallisey | I don't disagree that people will want or use them | 17:34 |
| *** chas__ has quit IRC | 17:34 | |
| kfox1111 | the templates/packages are analagous to the kolla containers. | 17:34 |
| rhallisey | but kolla was super early on how to do it | 17:34 |
| kfox1111 | generic building blocks people can launch in whatever way best suites their system. | 17:34 |
| *** chas_ has joined #openstack-kolla | 17:35 | |
| sdake_ | inc0 repo split incoming !! | 17:35 |
| rhallisey | kfox1111, that last statement, yes I agree with that | 17:35 |
| kfox1111 | the kolla ansible stuff is more akin to the workflow bits. | 17:35 |
| rhallisey | operators are part of that | 17:35 |
| kfox1111 | right. | 17:35 |
| inc0 | brace for impact | 17:35 |
| rhallisey | ok I guess we differ there | 17:35 |
| sdake_ | differ how | 17:35 |
| rhallisey | because the operators are building blocks recipes too | 17:35 |
| kfox1111 | rhallisey: yeah. true. | 17:36 |
| sdake_ | they are implementations of workflow just as kolla-ansible is | 17:36 |
| rhallisey | so I see them as equivalent to the services | 17:36 |
| kfox1111 | and operators should be encuraged to use as many of the building blocks as they can rather then reinvent them. | 17:36 |
| kfox1111 | rhallisey: I think we're on the same. | 17:36 |
| rhallisey | ok | 17:36 |
| rhallisey | gotcha | 17:36 |
| sdake_ | inc0 i am semi-serious, i htink the operators thing will spawn a repo split in the future | 17:36 |
| kfox1111 | the operators will be packaged in kolla containers, and have helm packages provided. | 17:37 |
| rhallisey | sdake, idk | 17:37 |
| kfox1111 | so yeah, in that sence they are no different then any of the other building blocks. | 17:37 |
| *** Serlex has quit IRC | 17:37 | |
| rhallisey | sdake_, I think this is a difference scenario | 17:37 |
| inc0 | sdake_, I hope not, it's k8s native so no religion will be involved | 17:37 |
| kfox1111 | I see no reason to split. | 17:37 |
| rhallisey | there is no religion tied in here | 17:37 |
| sdake_ | that isn't the reason we did the repo split I hope ;) | 17:37 |
| kfox1111 | we're just architecting kolla-kubernetes in a more moduler way. | 17:37 |
| inc0 | well, partially it is | 17:37 |
| rhallisey | just analogous building blocks | 17:37 |
| *** sdake has quit IRC | 17:37 | |
| *** mgoddard has quit IRC | 17:37 | |
| kfox1111 | kolla-ansible had several things done by the same tool, so it was natural to conflate them a bit. | 17:38 |
| sdake_ | ok well all I have to say on repo split, is I capitulated, and I warned ya fellas ahead of time :) | 17:38 |
| *** mgoddard has joined #openstack-kolla | 17:38 | |
| inc0 | this was planned for a long time | 17:38 |
| inc0 | after that, we'll see | 17:38 |
| inc0 | but I don't think we'll need any more of it | 17:38 |
| sdake_ | ya well the trigger has been pulled | 17:38 |
| *** chas_ has quit IRC | 17:39 | |
| kfox1111 | I think long term, it will be worth it. short term, it will be painful. | 17:39 |
| *** khamtamtun has quit IRC | 17:40 | |
| sdake_ | no repo splits short term | 17:40 |
| sdake_ | atleast none that i'm voting for | 17:40 |
| sdake_ | kfox1111 unclear if you were talking about the repo split that has been done or the one that may be done in the future :) | 17:40 |
| *** Pavo has quit IRC | 17:40 | |
| sdake_ | if folks couldn't tell, i'm a super fan of one repo ;) | 17:41 |
| kfox1111 | talking about kolla-ansible. | 17:41 |
| sdake_ | ok | 17:41 |
| kfox1111 | I can't think of any other ones. | 17:41 |
| sdake_ | kfox1111 the way you position operators, they are "optional" | 17:41 |
| kfox1111 | sdake_: right. | 17:41 |
| sdake_ | the way kolla-ansible was positioned was the same... | 17:42 |
| *** athomas has quit IRC | 17:42 | |
| *** mgiles has joined #openstack-kolla | 17:42 | |
| kfox1111 | cool. then I think we're on the same page then. | 17:42 |
| kfox1111 | brb. | 17:42 |
| *** khamtamtun has joined #openstack-kolla | 17:46 | |
| sdake_ | and ify ou win you get this shiny fiddle made of gold | 17:49 |
| sdake_ | and if the devil wins he gets your soul! | 17:49 |
| *** TxGirlGeek has quit IRC | 17:51 | |
| rhallisey | sdake_, etherpad is coming together | 17:51 |
| sdake_ | inc0 https://review.openstack.org/#/c/396903/9/gerrit/projects.yaml | 17:52 |
| rhallisey | right now we have 4 things needed in the base class | 17:52 |
| *** devananda|away is now known as devananda | 17:52 | |
| sdake_ | rhallisey got a link - mine scrolled | 17:52 |
| sdake_ | and lazy :) | 17:52 |
| rhallisey | https://etherpad.openstack.org/p/operator-base-class | 17:53 |
| *** eaguilar has quit IRC | 17:55 | |
| *** ayoung has quit IRC | 17:55 | |
| *** khamtamtun has quit IRC | 17:57 | |
| *** khamtamtun has joined #openstack-kolla | 17:57 | |
| sdake_ | hate this time of year | 18:00 |
| sdake_ | hot cold hot cold | 18:00 |
| *** eaguilar has joined #openstack-kolla | 18:01 | |
| *** fragatin_ has joined #openstack-kolla | 18:01 | |
| portdirect | sdake_ come to scotland, we have cold & rain all year :) | 18:01 |
| portdirect | rhallisey: If possible could we also add rabbit user/role to the base-class? | 18:02 |
| sdake_ | portdirect sounds fantastic :) | 18:02 |
| sdake_ | portdirect the idea is to create users and roles in the operators themselves | 18:02 |
| rhallisey | yes | 18:03 |
| rhallisey | portdirect, go ahead and add it | 18:03 |
| sdake_ | and use the thirdparty object to track their state | 18:03 |
| *** fragatina has quit IRC | 18:05 | |
| portdirect | nice | 18:06 |
| pbourke | bjolo_: any progress on that multiple network issue? | 18:06 |
| pbourke | bjolo_: could you paste me your ml2_conf.ini if you get a chance | 18:06 |
| *** khamtamtun has quit IRC | 18:07 | |
| inc0 | any puppet magician here? | 18:07 |
| *** pbourke has quit IRC | 18:07 | |
| inc0 | PTL needs your help;) | 18:08 |
| *** khamtamtun has joined #openstack-kolla | 18:08 | |
| sdake_ | rhallisey line 29 question | 18:08 |
| sdake_ | You ahve <service>>-oprat-rbase class | 18:09 |
| *** ayoung has joined #openstack-kolla | 18:09 | |
| sdake_ | is your intent to create ae base class for every service? | 18:09 |
| sdake_ | because tbh, tht makes alot more work with no gain | 18:09 |
| *** pbourke has joined #openstack-kolla | 18:09 | |
| *** msimonin has joined #openstack-kolla | 18:09 | |
| sdake_ | a parent class inherits from the base class all the infrastructure to do the job, that is where <service>-operator specific logic goes | 18:10 |
| rhallisey | sdake_, no, the base class is for will do the the work | 18:10 |
| rhallisey | openstack-operator has a different class | 18:10 |
| rhallisey | of it's own | 18:10 |
| inc0 | rhallisey, you worked on tripleo, you should know puppet right?:P | 18:10 |
| sdake_ | right but look at line 29 | 18:10 |
| sdake_ | you got <>'s around it | 18:10 |
| rhallisey | ya I know some puppt | 18:10 |
| sdake_ | thanks :) | 18:10 |
| rhallisey | removed it | 18:10 |
| inc0 | wanna help make Kolla greater? | 18:11 |
| rhallisey | what is it you need in puppet | 18:11 |
| inc0 | we need puppet module that will setup registry | 18:11 |
| inc0 | in infra | 18:11 |
| inc0 | then kolla-k8s and kolla-ansible will be able to just pull images from it | 18:11 |
| sdake_ | rhallisey when we create classes for all this stuff based upno the base class | 18:12 |
| sdake_ | where will the configuration come from? | 18:12 |
| rhallisey | inc0, what does it entail | 18:13 |
| rhallisey | downloading docker? and stuff like that? | 18:13 |
| rhallisey | like is the env empty? | 18:13 |
| kfox1111 | back | 18:13 |
| sdake_ | not the shell environment | 18:13 |
| rhallisey | sdake_, uhm | 18:13 |
| inc0 | no, running registry outside of docker | 18:13 |
| inc0 | so just apt-get install docker-registry | 18:13 |
| sdake_ | the configuration for how to setup the pod | 18:13 |
| kfox1111 | inc0: yeah. up to date containers would be awesome. | 18:13 |
| inc0 | I can help you with running-registry-outside part | 18:13 |
| inc0 | kfox1111, if you know puppet you can help too;) | 18:14 |
| kfox1111 | same should happen for helm. | 18:14 |
| kfox1111 | puppets one of the few I dont now. :/ | 18:14 |
| kfox1111 | know. | 18:14 |
| sdake_ | kfox1111 where does config come from for opeartor base class on line 29 of the etherpad | 18:14 |
| kfox1111 | sdake_: looking... | 18:14 |
| rhallisey | it can come at any layer | 18:14 |
| rhallisey | I believe | 18:14 |
| kfox1111 | 29? | 18:14 |
| kfox1111 | 3rd party resource | 18:14 |
| sdake_ | line 29 of the etherpad | 18:14 |
| rhallisey | so it can come from the openstack operator | 18:15 |
| rhallisey | or each service op | 18:15 |
| sdake_ | my line 2 is "Operator-base" class | 18:15 |
| sdake_ | ok what feeds the 3rd party resource | 18:15 |
| kfox1111 | the opnestack operator, or a hman operator would upload the config as a 3rd party resource | 18:15 |
| rhallisey | user or openstack op | 18:15 |
| kfox1111 | which pokes the service operator to realize the config. | 18:15 |
| sdake_ | the config is what, a configmap? | 18:15 |
| rhallisey | user -> openstack op or user -> service-op | 18:16 |
| kfox1111 | a third party resource. | 18:16 |
| sdake_ | ok, so lets make a real world example :) | 18:16 |
| rhallisey | ah so | 18:16 |
| kfox1111 | a thrid party resource is just a custom k8s object type. yaml document. | 18:16 |
| sdake_ | keystone has some default settings | 18:16 |
| portdirect | json | 18:16 |
| sdake_ | are we to feed that into the operator? | 18:16 |
| rhallisey | I don't think third party resource will have a config map | 18:16 |
| kfox1111 | or json. :) | 18:16 |
| rhallisey | so we store it then create it | 18:16 |
| rhallisey | base class will convert it | 18:17 |
| kfox1111 | an operator is a workflow that takes a desired state, (the third party resoruce definition), looks at the current state of the system, and applies chagnes to k8s until the two match up | 18:17 |
| rhallisey | kfox1111, that makes it sound like a daemon, which I don't think it is | 18:18 |
| kfox1111 | it is a daemon I believe. | 18:18 |
| *** khamtamtun has quit IRC | 18:18 | |
| kfox1111 | most of the time it does nothing though. | 18:18 |
| sdake_ | operators are daemons | 18:18 |
| sdake_ | daemons of micro-controllers ;) | 18:19 |
| kfox1111 | waiting for thrid party resources pointing to it getting chagned/added | 18:19 |
| rhallisey | well maybe the peices will be | 18:19 |
| rhallisey | I guess it has to be for auto healing | 18:19 |
| rhallisey | but then we need to incorporate that | 18:19 |
| kfox1111 | it has to be running to watch for 3rd party resource creations/changes. | 18:19 |
| kfox1111 | though the user could stop it and nothing shoudl break. | 18:19 |
| sdake_ | if it one-shots, it will be reloaded continually bo k8s | 18:19 |
| sdake_ | which we dont want | 18:19 |
| rhallisey | ok let me rephrase | 18:20 |
| sdake_ | what data do we want in the third party resource? | 18:20 |
| kfox1111 | thats a good question. I think it comes down to usabilit. | 18:21 |
| rhallisey | daemon = constantly trying to bring to desired state. controller = waiting for either user input or kubernetes input to execute an operation | 18:21 |
| kfox1111 | it could be one of two things I think. | 18:21 |
| rhallisey | I think it's #2, a controller | 18:21 |
| kfox1111 | it could be the current kolla/globals.yml and kolla-kubernetes/kubernetes.yaml info | 18:21 |
| rhallisey | daemon might be the wrong word | 18:21 |
| kfox1111 | or it could just be kolla-kubernetes/kubernetes.yaml and the user is expected to put in the eqiv of kolla/blobals.yaml via configmaps or something. | 18:21 |
| sdake_ | ok so looking at KEYSTONE in particular | 18:22 |
| sdake_ | whatwould the input be, surely not globals.yaml? | 18:22 |
| *** Pavo has joined #openstack-kolla | 18:22 | |
| kfox1111 | the overarching openstack-operator would take globals.yaml, and slice it up into 3rd party resources relevent to each. | 18:22 |
| kfox1111 | so the keystone operator woudl take in the equiv of just the values in globals.yaml it cared about. | 18:23 |
| portdirect | deleted what i was typing, kfoxx is on it :) | 18:23 |
| sdake_ | currently isn't this in a configmap? | 18:23 |
| kfox1111 | yeah. | 18:23 |
| kfox1111 | but I think the keystone-operator woudl create the keystone cnfigmap using that data. | 18:24 |
| portdirect | would it not be the operaors job to produce the configmaps from this? | 18:24 |
| kfox1111 | if you still wanted ultimate flexability as a user, | 18:24 |
| kfox1111 | you would skip the operator and deploy the configmap/deployment yourself. | 18:24 |
| sdake_ | what would create the db/etc? :) | 18:25 |
| kfox1111 | the operator. | 18:25 |
| portdirect | sdake_: I think we would also want some version info for the db | 18:25 |
| sdake_ | you just said skip the operator? | 18:25 |
| rhallisey | <service>-operator | 18:25 |
| kfox1111 | oh. if the user was skipping the operator, then they would manually do what the operator does. | 18:25 |
| rhallisey | the openstack-operator will gather data and pass it down then start <service>-operator | 18:25 |
| sdake_ | ok, I don't expect anyone to magically figure that part out :) | 18:25 |
| kfox1111 | the operator is basically just a condified human operator. everything the operator can do a human should be abe to do. | 18:26 |
| kfox1111 | codified | 18:26 |
| sdake_ | such a terrible name | 18:26 |
| sdake_ | can we fire whoever came up with that name | 18:26 |
| kfox1111 | +1000 :) | 18:26 |
| kfox1111 | someone REALLY wasn't thinking about users... | 18:27 |
| kfox1111 | once again us ops get thrown under the bus. :) | 18:27 |
| *** Pavo has quit IRC | 18:27 | |
| sdake_ | ok rants aside | 18:28 |
| sdake_ | the overarcing operator feeds what input into the third party resource? | 18:28 |
| kfox1111 | the config bits that are relavent to that third party operator. | 18:29 |
| sdake_ | what gets fed the cnofigmap? | 18:29 |
| kfox1111 | k8s itself. | 18:29 |
| rhallisey | configmap gets the contents of /etc/kolla | 18:29 |
| rhallisey | oh what does | 18:30 |
| *** chas_ has joined #openstack-kolla | 18:30 | |
| rhallisey | k8s | 18:30 |
| kfox1111 | k8s gets the configmaps. | 18:30 |
| sdake_ | ok so using keystone as an example | 18:30 |
| sdake_ | and operators launch keystone pod | 18:30 |
| kfox1111 | no. | 18:30 |
| sdake_ | keystone-operator launches keystone pod | 18:30 |
| sdake_ | wouldn't keystone-operator need to know the config map? | 18:30 |
| portdirect | i would have thought overaching operator genertaes configmap for keystone operator whihc then generates configsmaps for keystone pods | 18:30 |
| kfox1111 | 1. keystone operator gets some config bits. | 18:30 |
| rhallisey | sdake_, yes it would need to have the config map | 18:31 |
| *** Jeffrey4l has joined #openstack-kolla | 18:31 | |
| kfox1111 | 2. runs the bootstrap jobs | 18:31 |
| kfox1111 | 3. creates configmaps with data obtained from the 3rd party resource. | 18:31 |
| rhallisey | sdake_, case #1: openstack-operator give it to keystone-operator case #2: user gives keystone-operator configmap | 18:31 |
| kfox1111 | 4. calls helm install <services> | 18:31 |
| kfox1111 | 5. profit. :) | 18:32 |
| sdake_ | ok 3 sounds alot like "make it harder" to me :) | 18:32 |
| portdirect | 5. runs post install jobs | 18:32 |
| portdirect | 6 profit | 18:32 |
| sdake_ | why not feed configmap directly into operator? | 18:32 |
| rhallisey | sdake_, because we have the openstack operator | 18:32 |
| sdake_ | rather directly into third party resource? | 18:32 |
| kfox1111 | sdake_: how? the operator sits on a 3rd party resource | 18:32 |
| rhallisey | depends on the layer you come in | 18:32 |
| sdake_ | configmap = json/yaml | 18:33 |
| kfox1111 | ah. definition issue. | 18:33 |
| kfox1111 | configmap is a specific object type in k8s. | 18:33 |
| portdirect | we need 5 for things like create cinder volume types etc | 18:33 |
| kfox1111 | your more talking about the contents there of. | 18:33 |
| sdake_ | right contents | 18:33 |
| sdake_ | i need an enumeration of the contents | 18:33 |
| kfox1111 | 3rd party resources and configmaps are just yaml files. | 18:33 |
| sdake_ | i understand that part | 18:34 |
| kfox1111 | so copying a chunk of config out of the thrrd party resource and dropping it in a new configmap is prety trivial., | 18:34 |
| *** chas__ has joined #openstack-kolla | 18:34 | |
| kfox1111 | so step 3 I don't think is very hard. | 18:34 |
| rhallisey | contents of config map is in files | 18:34 |
| *** chas_ has quit IRC | 18:34 | |
| portdirect | yup - the only diffrence is in how they are accessed, but sdake has a good point - at what stage are we coing to translate to ini files etc (no matter how stored) | 18:35 |
| rhallisey | contents of third party resource is yaml/json :) | 18:35 |
| sdake_ | what I'd like defined is the data in the third party resource | 18:35 |
| kfox1111 | true. | 18:35 |
| kfox1111 | yeah. which was what I was talking about above. is it workflow+config, or just workflow? | 18:35 |
| kfox1111 | if its workflow+config, its what I've been just talking about. | 18:35 |
| kfox1111 | if its kind of just workflow, it would be just kolla-kubernetes.yaml stuff I think. | 18:36 |
| kfox1111 | the operator woudl then expect someone else to build the configmaps/upload them. | 18:36 |
| kfox1111 | and hte operator woudl onlyu conern it self with configuring helm packages. | 18:36 |
| portdirect | i think workflow+config, would make the most sense | 18:37 |
| kfox1111 | workflow+config is easiest on users. | 18:37 |
| kfox1111 | less flexable thhough. more opinionated. | 18:37 |
| sdake_ | ya reconfigure upgrade all from one API | 18:37 |
| kfox1111 | so theres' a tradeoff there. | 18:37 |
| sdake_ | it doesn't have to be more opinionated | 18:37 |
| rhallisey | https://github.com/kubernetes/kubernetes/blob/master/docs/design/extending-api.md | 18:37 |
| kfox1111 | sdake_: only from the standpoint of I think it wil be hard to cram everything through a 3rd party resource and maintain ultimate flexability. | 18:38 |
| kfox1111 | you could cat all /etc/kolla/* into a 3rd party resource maybe. | 18:38 |
| kfox1111 | or it could just break k8s cause its too large. :/ | 18:38 |
| *** chas__ has quit IRC | 18:38 | |
| kfox1111 | whcih I think is likely. :/ | 18:38 |
| portdirect | 1mb is limit | 18:39 |
| kfox1111 | so it may end up being more opinionated. | 18:39 |
| kfox1111 | du -chs /etc/kolla | 18:39 |
| kfox1111 | 1.1M/etc/kolla | 18:39 |
| kfox1111 | already over. :/ | 18:39 |
| portdirect | ls -lah ? | 18:40 |
| *** khamtamtun has joined #openstack-kolla | 18:40 | |
| *** unicell1 has joined #openstack-kolla | 18:41 | |
| kfox1111 | http://paste.openstack.org/show/wOM3j6jSVpZbu1rHwqbF/ | 18:41 |
| portdirect | cheers | 18:41 |
| kfox1111 | :) | 18:41 |
| kfox1111 | so that may force us to either, keep the openstack config seperate, and only pass kolla-kubernetes config via 3rd party resource, | 18:42 |
| kfox1111 | or make it opinionated. | 18:42 |
| sdake_ | ok, so its clear to me we dont want operators to have all of /etc/kolla | 18:42 |
| portdirect | we can have as many as we need | 18:42 |
| sdake_ | rather third party resources | 18:42 |
| portdirect | sdake_: +1 | 18:42 |
| kfox1111 | it'll work for the service-operators. | 18:43 |
| sdake_ | what I dont understand is why not feed keystone keystone's configmap data? | 18:43 |
| kfox1111 | not sure what to do with the compute-kit-operator | 18:43 |
| kfox1111 | sdake_: to what? | 18:43 |
| sdake_ | feed it to the thirdpartyresource responsible for keystone | 18:43 |
| kfox1111 | thats what I've been saying. | 18:43 |
| sdake_ | we are making thirdparty resources for every microservice | 18:44 |
| kfox1111 | no, I don't think so. | 18:44 |
| kfox1111 | third party resource per service. | 18:44 |
| sdake_ | that works | 18:44 |
| kfox1111 | native k8s objects for microservices. | 18:44 |
| kfox1111 | configmap/deployment/dameonsets, etc | 18:44 |
| sdake_ | let me process those last 3 lines for 5 mins | 18:44 |
| sdake_ | don't say anything else pls ;) | 18:44 |
| kfox1111 | k | 18:44 |
| rhallisey | kfox1111, isn't that what's there already | 18:45 |
| sdake_ | so native k8s objects for microservices come from where in the operator model? | 18:46 |
| rhallisey | openstack-operator creates config maps from /etc/kolla | 18:46 |
| kfox1111 | rhallisey: right. we're just adding operators on top to make deplying things at the service level esier. | 18:46 |
| kfox1111 | sdake_: right. | 18:46 |
| rhallisey | instead of jamming into thirdpartyresource | 18:46 |
| kfox1111 | oh. | 18:46 |
| sdake_ | it was a question :) | 18:46 |
| kfox1111 | k8s itself is a platform for managing microservices. they have native objects for microservices. | 18:46 |
| kfox1111 | but when you ahve a ton of microservices, then it becomes a little unweildy. | 18:47 |
| kfox1111 | the idea is to use an operator to let the human think more about service, and the operator maps that to the grouping of microservices that need to exist. | 18:47 |
| sdake_ | one key aspect of an operator is to provide in-place config changes | 18:48 |
| sdake_ | how is that delivered in this model? | 18:48 |
| portdirect | i would have thought the native k8s objects come from the service level operator, while the openstack level operaor would be resonsible for splitting up kolla/global into chincks without processing them for the service level operaor to consume/ | 18:48 |
| kfox1111 | so take nova. its the following microservices. | 18:48 |
| sdake_ | portdirect ++ | 18:48 |
| kfox1111 | nova-api, nova-conductor, nova-schedular, nova-compute. | 18:48 |
| kfox1111 | the user can launch each of those microservices today with our native k8s objects. | 18:48 |
| kfox1111 | but we want to give them the option to just think of all of those as a single service "nova" | 18:49 |
| rhallisey | portdirect, idk if we can do that | 18:49 |
| kfox1111 | and that operator takes care of telling k8s to launch the microservices. | 18:49 |
| rhallisey | that woudl require saving everything from /etc/kolla | 18:49 |
| *** krtaylor has quit IRC | 18:49 | |
| kfox1111 | no, just the parts that apply to nova. | 18:49 |
| *** khamtamtun has quit IRC | 18:50 | |
| rhallisey | we need config.json from everywhere loaded into a giant json | 18:50 |
| sdake_ | ok, so here is where I'm stuck | 18:50 |
| portdirect | only the global operator would require to the whole lot - it's primary puropose would be to cut it up accordinly? | 18:50 |
| sdake_ | data defines all the nova microservices - these are called ConfigMaps - in the example of nova, the cnofig map would contain the config map for all services related to nova | 18:51 |
| kfox1111 | pron: yeah. | 18:51 |
| kfox1111 | "data defines all the nova microservices - these are called ConfigMaps - in the example of nova, the | 18:51 |
| kfox1111 | thirdparty resource would contain the config map data for all services related to nova" | 18:51 |
| *** Pavo has joined #openstack-kolla | 18:52 | |
| sdake_ | right | 18:52 |
| rhallisey | nova-operator has nova configmap with all nova services' config.json. nova-api-operator has nova-api configmap with nova api config.json | 18:52 |
| sdake_ | so json is one input, the configmap data is another? | 18:52 |
| kfox1111 | nova operator takes in a 3rdparty resource with all nova services config.json. (no nova-api-operator) | 18:53 |
| *** Pavo has quit IRC | 18:53 | |
| kfox1111 | nova operator takes in 3rdparty resource for all nova services. creates configmaps using that data, | 18:53 |
| sdake_ | here is where the lack of that model falls over kfox1111 | 18:53 |
| kfox1111 | helm install's all the microservices. | 18:53 |
| sdake_ | what about nova-spicehtml5proxy | 18:53 |
| sdake_ | maybe someone doesn't want that | 18:53 |
| kfox1111 | that would be a config option to the 3rd party resource. | 18:53 |
| rhallisey | what if openstack-operator created the for example nova-api-configmap based on user input | 18:54 |
| rhallisey | we're passing around all this data to create a configmap later | 18:54 |
| kfox1111 | openstack-operator shouldn't. it should give nova-operator the info it needs to build nova-api-configmap | 18:54 |
| inc0 | soo...can we crate some specification of what people needs? | 18:54 |
| sdake_ | lol | 18:55 |
| inc0 | like data structure prior to deployment | 18:55 |
| kfox1111 | otherwise openstack-operatoer needs to know way too much about each service. | 18:55 |
| inc0 | based on conf = either make nova depend on spice5proxy or not | 18:55 |
| rhallisey | kfox1111, well it know what services need to be spawned | 18:55 |
| sdake_ | kfox1111 right, we want to avoid any operator knowing too much about each individual service | 18:55 |
| rhallisey | so then it should know those services need configmaps | 18:55 |
| sdake_ | kfox1111 this is why current spec would end up with a spice-html5proxy operator | 18:55 |
| sdake_ | which contained only its config data | 18:55 |
| kfox1111 | rhallisey: openstack operator should know about what services to laucnh. the service-operator shoudl laucnh the microservices. | 18:55 |
| inc0 | uhh we want to create operator for every container? not even pod? | 18:56 |
| kfox1111 | that way the logic for a service is all wrapped up in the service-operator. | 18:56 |
| kfox1111 | inc0: no. | 18:56 |
| inc0 | then no spice5proxy operator | 18:56 |
| kfox1111 | serivce operator level only. | 18:56 |
| sdake_ | the current spec has operators per service | 18:56 |
| inc0 | and openstack operator which spawns service operators | 18:56 |
| kfox1111 | inc0: no spice5proxy operator. spice5proxy helm package. | 18:56 |
| sdake_ | and operators per microservice | 18:56 |
| kfox1111 | and the nova-operator would helm install spice5proxy if the user requested it in the nova thirdparty resource request. | 18:57 |
| kfox1111 | no reason to rebuild k8s/helm in an operator. k8s/helm can deal with microservices. thats what its built for. | 18:57 |
| sdake_ | ok, i think we can all agree nova is a wierd case since it has so many microservices | 18:57 |
| sdake_ | can we talk about keystone instead? | 18:57 |
| kfox1111 | an operator handles deploying/managing a pool of like microservices. | 18:58 |
| kfox1111 | keystone is an outlier. | 18:58 |
| sdake_ | horizon? | 18:58 |
| kfox1111 | neutron nova glance or cinder are more common examples. | 18:58 |
| kfox1111 | horizon is kind of an outlier too. | 18:58 |
| sdake_ | ok, lets pick glance then | 18:58 |
| kfox1111 | k. | 18:58 |
| portdirect | glance is good :) | 18:58 |
| sdake_ | cinder has a million microservices too | 18:58 |
| sdake_ | same story with neutron | 18:58 |
| kfox1111 | glance is a little more simple then the rest. | 18:59 |
| sdake_ | lets get simple right | 18:59 |
| sdake_ | complex follows after simple | 18:59 |
| sdake_ | so lets talk about glance, (or heat) since it has two microservices | 18:59 |
| kfox1111 | hmm... glance may be too simple an example. | 18:59 |
| kfox1111 | oh. two, right. | 18:59 |
| kfox1111 | ok. | 18:59 |
| kfox1111 | glance-api and glance-registry | 18:59 |
| sdake_ | right | 19:00 |
| sdake_ | ok, third party resource is fed a config map containing BOTH glance-api and glance-registry things? | 19:00 |
| kfox1111 | we make a containner for each. (already done) | 19:00 |
| kfox1111 | we make k8s object for each (done) and package it (pending) | 19:01 |
| kfox1111 | then the last bit is the orchestration. I can manually launch both with helm commands. | 19:01 |
| kfox1111 | if I'm a user that just wants to think of it as a single thing, "glance" | 19:01 |
| sdake_ | can you update configs with helm? | 19:01 |
| kfox1111 | we do that with a thirdpartyresource & operator. | 19:01 |
| kfox1111 | I think we want to keep the configs outside of helm. | 19:02 |
| sdake_ | along those lines then, how does glance-api and glance-registry retrieve its config ? | 19:02 |
| kfox1111 | but I believe yo ucan do the equiv of kubectl update -f foo-deployment.yaml with helm. | 19:02 |
| kfox1111 | from configmaps. | 19:03 |
| portdirect | via configmaps, generated by their micro-operaors | 19:03 |
| *** TxGirlGeek has joined #openstack-kolla | 19:03 | |
| kfox1111 | no micro-operators. | 19:03 |
| kfox1111 | way way overkill. | 19:03 |
| kfox1111 | here's why. | 19:03 |
| sdake_ | ok, so you want to keep the configmaps for glance-api and glance-registry where? | 19:03 |
| portdirect | sorry i ment service | 19:03 |
| kfox1111 | you have to upload the configmap as a third party resource, then make a custom operator code, all to just spit out a configmap in the end the real resource will read. | 19:03 |
| kfox1111 | glance-api/glance-registry can only read from configmaps. | 19:04 |
| kfox1111 | k8s object type. | 19:04 |
| sdake_ | so we have an overarching glance-operator | 19:04 |
| kfox1111 | right. | 19:05 |
| sdake_ | which has no config-mpa data? | 19:05 |
| kfox1111 | it recieves config data via third party resource. | 19:05 |
| sdake_ | right and that third party resource contains which data? | 19:05 |
| *** Pavo has joined #openstack-kolla | 19:05 | |
| kfox1111 | all the config data needed to make glance work. | 19:05 |
| kfox1111 | wheter that be data destined for openstack services, | 19:06 |
| sdake_ | including the configmaps fed into glance-registry adn glance-api? | 19:06 |
| kfox1111 | or data needed to configure the k8s objects. | 19:06 |
| kfox1111 | yeah. | 19:06 |
| *** khamtamtun has joined #openstack-kolla | 19:06 | |
| sdake_ | ok, so I am a little less confused now :) | 19:06 |
| kfox1111 | the idea behind 3rd party resoures is to let you think about a thing as a k8s object instead of a set of underlying k8s objects. | 19:06 |
| kfox1111 | so its "here, I want a glance that looks like X....." | 19:07 |
| kfox1111 | and the operator gives you one. :) | 19:07 |
| sdake_ | thirdpartyresources contains both config maps for glacne-api and glance-registry? | 19:07 |
| kfox1111 | yeah. | 19:07 |
| kfox1111 | but your inisiting on calling configdata configmaps. | 19:08 |
| sdake_ | and it contains globals.yaml so the operator knows what to do with the config maps? | 19:08 |
| *** Pavo has quit IRC | 19:08 | |
| kfox1111 | a configmap is a k8s object. | 19:08 |
| sdake_ | kfox1111 i understand a configmap is a k8s object | 19:08 |
| *** Pavo has joined #openstack-kolla | 19:08 | |
| sdake_ | it is also a blob of data that gets registered for use by a pod no? | 19:08 |
| *** Pavo has quit IRC | 19:08 | |
| sdake_ | in my mind its two things not one | 19:08 |
| kfox1111 | no. I'd not conflate the two. | 19:09 |
| *** Pavo has joined #openstack-kolla | 19:09 | |
| sdake_ | which is fine, i just want to understand :) | 19:09 |
| sdake_ | ok glance-api gets its config from where? | 19:09 |
| sdake_ | a configmap? | 19:09 |
| kfox1111 | glance-api and glance-registry templates get their config from respective configmaps. | 19:10 |
| portdirect | yes - we dont want pods at the end of the chain interactive with the k8s api if possible. | 19:10 |
| *** Pavo has quit IRC | 19:10 | |
| *** Pavo has joined #openstack-kolla | 19:10 | |
| sdake_ | what registers that configmap object? | 19:10 |
| kfox1111 | (http://kubernetes.io/docs/user-guide/configmap/ a configmap to me is that yaml example at the top. a yaml thing with kind:Configmap and match the schema) | 19:10 |
| kfox1111 | sdake_: the service-operator or a human. | 19:11 |
| kfox1111 | depending if they want orchestration or not. | 19:11 |
| sdake_ | cool, so lets take example of service-operator registering the config map for glance-api | 19:11 |
| sdake_ | I assume glance-operator would do that | 19:11 |
| portdirect | yup | 19:11 |
| sdake_ | kfox1111 ? | 19:12 |
| portdirect | kfox1111: at what point do you think it would be best to generate the content of that configmap? | 19:12 |
| kfox1111 | sdake_: yeah. glance-operator woudl do that. | 19:12 |
| sdake_ | cool so glance-operator gets its config map from where? | 19:12 |
| kfox1111 | portdirect: I'm a little bit iffy on that one. it depends on how easy we want the workflow to be vs how flexable. | 19:13 |
| kfox1111 | sdake_: it gets its data from a third party resource definition. | 19:13 |
| kfox1111 | it uses that data to gerneate configmaps for glacne-api and glance-registry | 19:13 |
| sdake_ | ok, so third party resource for glance-api and glance-registry is then registered with the third party resource in some form of bundle? | 19:14 |
| sdake_ | let me restate the above | 19:14 |
| kfox1111 | user -> glance thirdpartyresource -> glance-operator -> | 19:14 |
| sdake_ | what goes in the thirdpartyresource for glance-operator? | 19:14 |
| kfox1111 | glacne-api configmap, glance-registry-configmap, helm install glance-api, helm install glance-registry | 19:14 |
| *** fragatin_ has quit IRC | 19:15 | |
| kfox1111 | all the config needed by glance-operator to spawn a usable glance. | 19:15 |
| *** fragatina has joined #openstack-kolla | 19:15 | |
| sdake_ | ok, so is that a bundle of the glance-api and glance-registry configmap data blobs? | 19:15 |
| kfox1111 | (being purposfully vauge about that as I'm not sure the best arangement for that data) | 19:15 |
| sdake_ | none of us are | 19:16 |
| sdake_ | hence we are making some decisions :) | 19:16 |
| kfox1111 | it may make sense to flatten out the configmap data before the operator gets it, | 19:16 |
| kfox1111 | or it may make sense to have unduplicated data sent into the operator and it duplicates it as it goes to the configmap. | 19:16 |
| kfox1111 | for the main architecture though, I'm not sure it matters. | 19:16 |
| kfox1111 | now you have me using teh term configmap incorrectly. :/ | 19:17 |
| sdake_ | ;-) | 19:17 |
| kfox1111 | :) | 19:17 |
| sdake_ | configmap is a yaml file configmap once instantiated is an object | 19:17 |
| sdake_ | i am talking about the configmap in yaml part | 19:17 |
| kfox1111 | configmap is a k8s object. it can be at rest in a file, or instantiated in a k8s. | 19:18 |
| kfox1111 | your talking about the data wrapped up inside the configmap. | 19:18 |
| sdake_ | define data | 19:18 |
| sdake_ | the configuration of glance-api? | 19:18 |
| kfox1111 | in this case, the configuration needed by a kolla container to start it and make it operate. | 19:18 |
| kfox1111 | so, we usually make a configmap out of /etc/kolla/glance-api for example. | 19:19 |
| sdake_ | and genconfig generatees /etc/kolla/glance-api? | 19:19 |
| kfox1111 | but, for this archetecture, it is also possible to do a genconfig in the glance-operator, | 19:19 |
| *** lrensing has joined #openstack-kolla | 19:19 | |
| kfox1111 | then do the configmap generation in the operator too. | 19:19 |
| kfox1111 | then the thirdpartyresource would take in a releavent subset of kolla globals.yaml | 19:20 |
| kfox1111 | not sure thats the right thing to do, but it is an option. | 19:20 |
| portdirect | this is the fundimental issue we need to resolve before working out the best way of moving it around | 19:20 |
| sdake_ | portdirect bingo :) | 19:20 |
| kfox1111 | yeah. we have a fundimental question we need answered before deciding that. | 19:21 |
| sdake_ | kfox1111 rabbit hole goes where? | 19:21 |
| rhallisey | kfox1111, well, if we pass all the way through, it make consumption work at every level | 19:21 |
| *** krtaylor has joined #openstack-kolla | 19:21 | |
| kfox1111 | ease_of_deployment <---------------------------------------> flexibility | 19:21 |
| kfox1111 | where do we want to put the line on that number line? | 19:21 |
| sdake_ | you see operators want both :) | 19:22 |
| kfox1111 | I prefer ultimate flexability, | 19:22 |
| sdake_ | are you saying they are mutually exclusive? | 19:22 |
| rhallisey | how about we make it a circle | 19:22 |
| kfox1111 | and that means I probably will manually orchestrate. | 19:22 |
| kfox1111 | sdake_: I think so. :/ | 19:22 |
| portdirect | i dont think so | 19:22 |
| kfox1111 | ultimate flexability is what openstack config does. | 19:22 |
| sdake_ | kolla-ansible is highlly flexible and has super ease of deployment | 19:22 |
| portdirect | i think rhallisey's circle has merit | 19:22 |
| kfox1111 | give every microservice its own config file. | 19:23 |
| kfox1111 | thats great, because you can override literally everything. | 19:23 |
| *** pc_m has quit IRC | 19:23 | |
| kfox1111 | the draback is ease of use. you have to manually configure the same thing over and over a lot of the time. | 19:23 |
| rhallisey | I think config should be outside | 19:23 |
| sdake_ | manuallly configure which? | 19:23 |
| rhallisey | config is in the user's hands | 19:23 |
| kfox1111 | rhallisey: outside of what? | 19:23 |
| *** pc_m has joined #openstack-kolla | 19:24 | |
| rhallisey | if we generate configs on the operators, we need to have a way to customize it | 19:24 |
| rhallisey | if that's the case, then it should just be done outside the operators | 19:24 |
| sdake_ | right, that is what the new config maps do | 19:24 |
| sdake_ | customize | 19:24 |
| sdake_ | feed a new config map into the operator, bnago, you have a new config | 19:24 |
| kfox1111 | rhallisey: or we assume if the deployer is using an operator, they don't need extreme flaxability. | 19:24 |
| rhallisey | kfox1111, outside the operators | 19:24 |
| rhallisey | kfox1111, I'd rather we don't assume | 19:24 |
| kfox1111 | as they would probably use manual deployment if they did. | 19:24 |
| sdake_ | i dont think it needs to be a tradeoff situation personally | 19:25 |
| rhallisey | openstack flexibility lies in config | 19:25 |
| kfox1111 | ok... lets try and brainstorm how we could make it both flexabile and easy | 19:25 |
| rhallisey | well one of the pieces of it's flexibility | 19:25 |
| kfox1111 | maybe I'm missing something. | 19:25 |
| sdake_ | and ease of use lies in wrapping that up in one operation with customization on the side | 19:25 |
| *** khamtamtun has quit IRC | 19:26 | |
| rhallisey | my opinion: we have good config generation tools with a set of defaults | 19:26 |
| kfox1111 | often the way that's achieved is configurability with sane defaults. | 19:26 |
| sdake_ | hate to invoke prior art here, but kolla-ansible is super fleixble and is super easy to use | 19:26 |
| rhallisey | we get ease of use with the default and we get customization with good tooling | 19:26 |
| sdake_ | rhallisey right | 19:26 |
| rhallisey | sdake_, we should use very similar model here | 19:26 |
| sdake_ | this is why I ask, where does the data come from that feeds into the operators | 19:26 |
| kfox1111 | sdake_: its good, but still needs some work on the flexability department. | 19:26 |
| rhallisey | sdake_, data come from config files that were generated on the master node | 19:27 |
| sdake_ | kfox1111 right - its not ultimately flexible (e.g. json can't be customized in newton) | 19:27 |
| kfox1111 | it kind of assumes a bunchf things about the archetecture. | 19:27 |
| kfox1111 | we'll fix that though. :) | 19:27 |
| *** khamtamtun has joined #openstack-kolla | 19:27 | |
| kfox1111 | no worries. :) | 19:27 |
| portdirect | an optionated operaor, but have a hook that allows a human-operaor to either load a pregenerated configmap for pods to consume? | 19:27 |
| rhallisey | if our operator generate config, it changes things a lot | 19:28 |
| sdake_ | portdirect the way kolla handles this now is it merges config files into one config file | 19:28 |
| rhallisey | we become less consumable | 19:28 |
| portdirect | (should have finished or custom logic) | 19:28 |
| kfox1111 | portdirect: hmm.. that could work. | 19:28 |
| *** chas_ has joined #openstack-kolla | 19:28 | |
| kfox1111 | the other route is completely devorce configmap stuff from operates. | 19:28 |
| kfox1111 | operators do all workflow but config bits. | 19:28 |
| kfox1111 | so user has to run kolla genconfig, upload them to k8s, | 19:29 |
| rhallisey | kfox1111, I'd rather do that | 19:29 |
| rhallisey | well idk | 19:29 |
| rhallisey | but I like that | 19:29 |
| rhallisey | because then the building block piece holds | 19:29 |
| kfox1111 | and only then can start using compute-kit-operator to laucnh the cloud. | 19:29 |
| kfox1111 | but back to what I said, | 19:29 |
| kfox1111 | thats flexable. | 19:29 |
| sdake_ | that is super hard to use | 19:29 |
| sdake_ | the uploading part | 19:29 |
| sdake_ | why not automate the uploading part | 19:29 |
| kfox1111 | not nessisarily the easiest to use though. | 19:29 |
| rhallisey | operator is purely an assistant | 19:29 |
| sdake_ | my take on an operator is it should take the grunt work out of workflow | 19:30 |
| kfox1111 | heh. maybe the solution is just one more layer? :) | 19:30 |
| inc0 | sooo, an idea | 19:30 |
| rhallisey | agreed sdake_ | 19:30 |
| *** ccesario has quit IRC | 19:30 | |
| sdake_ | and part of the grunt work is registering configmaps for each level | 19:30 |
| kfox1111 | write that last bit as a script. :) | 19:30 |
| inc0 | we create completely new form of deployment - we create yaml-based dependency graph | 19:30 |
| inc0 | nova depends on mariadb and keysone, mariadb is sub-graph that depends on mariadb-bootstrap job which depends on mariadb pv and pvc created, mariadb service depends on mariadb-boostrap | 19:31 |
| sdake_ | kfox1111 ya I htink a script should do that as well | 19:31 |
| sdake_ | in thirdparty resource objects | 19:31 |
| sdake_ | and the operators themselves should trigger changes | 19:31 |
| rhallisey | inc0, that would be re writing head or something | 19:32 |
| rhallisey | heat | 19:32 |
| inc0 | pretty much | 19:32 |
| inc0 | for k8s | 19:32 |
| kfox1111 | so, simple-openstack-deployment script does: runs kolla-ansible genconfig, uploads microservices configmaps, helm install compute-kit-operator; kubectl create -f 3rd-party-resource-for-compute-kit" | 19:32 |
| *** Pavo has quit IRC | 19:32 | |
| rhallisey | we don't need the workflow to be configurable though | 19:32 |
| inc0 | just better as heat doesn't have single source of truth of existing state | 19:32 |
| kfox1111 | one step, openstack out the other side. :) | 19:32 |
| rhallisey | and this isn't a general purpose orchestrator | 19:32 |
| *** Pavo has joined #openstack-kolla | 19:33 | |
| inc0 | it will be very general purpose | 19:33 |
| inc0 | operator will understand generic graph-description language | 19:33 |
| sdake_ | kfox1111 i'd like ot break the configmaps for each service into each operator | 19:33 |
| inc0 | and graph itself will be openstack specific | 19:33 |
| kfox1111 | rhallisey: the workflow nees to be configurable in some places. like, wheter to launch spiceconsole or not. | 19:34 |
| rhallisey | I think it will be simpler than that | 19:34 |
| sdake_ | inc0 i wrote in my trip notes exactly your idea, and think it has merit, but has a long path to dev | 19:34 |
| rhallisey | kfox1111, yes it will be somewhat configurable, but nothing crazy | 19:34 |
| kfox1111 | sdake_: ok, how about: | 19:34 |
| kfox1111 | two config files, like we have now: | 19:34 |
| kfox1111 | kolla-kubernetes.yaml. basically specifies what services will be in the cloud, and some config bits like , spice or not. | 19:34 |
| rhallisey | sdake_, inc0, it does, but that project should be written in go | 19:34 |
| kfox1111 | and the one for kolla genconfig. | 19:34 |
| inc0 | sdake_, well, https://github.com/inc0/heat-convergence-prototype | 19:35 |
| kfox1111 | the simple-workflow one, takes those two files as input. | 19:35 |
| inc0 | rhallisey, I disagree | 19:35 |
| inc0 | but it can | 19:35 |
| inc0 | I'll write it in python much faster | 19:35 |
| *** Pavo has quit IRC | 19:35 | |
| inc0 | and there is no value whatsoever for it being written in go aside from religion | 19:35 |
| sdake_ | python isn't hhip in cncf ;-( | 19:35 |
| inc0 | well, I'm not betting kolla success on cncf religious beliefs | 19:36 |
| kfox1111 | it then: kolla-gencofig's. creates configmaps for all the enabled microservices, helm install's comjpute-kit-operator, then uploads the kolla-kubernetes.yaml file as a third party resource to compute-kit-operator.? | 19:36 |
| inc0 | we have full community of python devs and python are totally correct language for this use case | 19:36 |
| *** ppalacios has quit IRC | 19:37 | |
| kfox1111 | sdake_: neither is openstack in a way. if they are regigious enough to not use python on pricipal, they probably wont use opnestack either as its written in python | 19:37 |
| inc0 | sdake_, https://github.com/cncf/demo/blob/master/cncfdemo-cli/cncfdemo/cncf.py | 19:37 |
| inc0 | cncf demo of techologies is written in....python | 19:37 |
| sdake_ | just kidding around guys | 19:37 |
| inc0 | so meh, I think they'll swallow it | 19:37 |
| sdake_ | jessh time for some northern lights! | 19:37 |
| kfox1111 | kk. | 19:38 |
| kfox1111 | back on topic. :) | 19:38 |
| jascott1 | template engine is go | 19:38 |
| inc0 | do not EVER joke about Python. Ever. | 19:38 |
| inc0 | :P | 19:38 |
| kfox1111 | does the last script I described make sense? | 19:38 |
| *** Pavo has joined #openstack-kolla | 19:38 | |
| sdake_ | kfox1111 let me reread it moment | 19:38 |
| inc0 | I vote for python+jinja2 | 19:38 |
| inc0 | and just write it quickly | 19:38 |
| kfox1111 | was two lines. | 19:38 |
| sdake_ | kfox1111 i lost your porposal can you c&p it pls | 19:39 |
| kfox1111 | inc0: yeah. but helm currently only takes golang templates. :/ and they are weird. | 19:39 |
| kfox1111 | k. | 19:39 |
| kfox1111 | 14:35 < kfox1111> the simple-workflow one, takes those two files as input. | 19:39 |
| kfox1111 | 14:36 < kfox1111> it then: kolla-gencofig's. creates configmaps for all the enabled microservices, helm install's comjpute-kit-operator, then uploads the kolla-kubernetes.yaml file as a third party resource to compute-kit-operator.? | 19:39 |
| kfox1111 | -------------- | 19:39 |
| inc0 | well it would be good to use golang templates... | 19:40 |
| sdake_ | i was thinking the operator would create configmaps for the services | 19:40 |
| inc0 | in python.. | 19:40 |
| *** eaguilar has quit IRC | 19:40 | |
| inc0 | god this is bad | 19:40 |
| rhallisey | so genconfig is only in the openstack-operator? | 19:40 |
| kfox1111 | how do you just use nova-operator if you dont want to use compute-kit-operator? | 19:40 |
| rhallisey | sdake_, specify which operator | 19:40 |
| sdake_ | i was thinking glance-operator would create configmaps for the glance services | 19:40 |
| kfox1111 | genconfig eitehr needs to be built into every service, or completely outside. | 19:40 |
| *** ppalacios has joined #openstack-kolla | 19:40 | |
| inc0 | with my approach configmap would be a node in graph | 19:40 |
| rhallisey | kfox1111, openstack-operator: runs genconfig for all nova-api-operator: run genconfig nova-api ? | 19:41 |
| sdake_ | kfox1111 and above, i was thinking it would take input form a third party resource and output it via kubectl | 19:41 |
| sdake_ | ok ppls, lets not think about the overarching operator | 19:42 |
| kfox1111 | sdake_: thats what I was initially saying, but thats more opinionated, so less flexable. | 19:42 |
| sdake_ | i'd like to solve the glance case first :) | 19:42 |
| *** mliima has quit IRC | 19:42 | |
| sdake_ | ok, statement made, pls explain :) | 19:42 |
| inc0 | sdake_, we can approach it top-bottom | 19:42 |
| kfox1111 | brb. potty brake. :) | 19:42 |
| inc0 | lol | 19:42 |
| rhallisey | kfox1111, idk if it's less flexible | 19:42 |
| sdake_ | kfox1111 - the question to you is why more opinionated why less flexible? | 19:43 |
| sdake_ | rhallisey we solved this problem in kolla-ansible by making everything flexible but having opinionated out of the box settings | 19:44 |
| portdirect | kfox1111: I almost think the other way - by moving config to the service level it makes it easier to mutate to your needs? Also makes it more apprachable if you just want a single service running in cluster i would have thought? | 19:44 |
| rhallisey | sdake_, yes I agree with that model. | 19:45 |
| kfox1111 | back. sorry. my eyes were staring to turn yellow. :) | 19:45 |
| sdake_ | kfox1111 your too young for that! | 19:45 |
| *** eaguilar has joined #openstack-kolla | 19:46 | |
| sdake_ | [12:43:03] <sdake_>kfox1111 - the question to you is why more opinionated why less flexible? | 19:46 |
| *** ppalacios1 has joined #openstack-kolla | 19:46 | |
| *** ppalacios has quit IRC | 19:46 | |
| *** ppalacios1 has quit IRC | 19:46 | |
| kfox1111 | the most flexable is where every config file is passed thorugh as is, unmollested. | 19:46 |
| sdake_ | config.file being like glance.conf? | 19:46 |
| kfox1111 | any time you generate one, you risk logic in the generation code not being flexable ough. | 19:46 |
| kfox1111 | yeah. | 19:46 |
| sdake_ | we solve this by merging configs | 19:47 |
| kfox1111 | but its much easier to use when there's just one config file and it generates most of the config files. | 19:47 |
| kfox1111 | so there's a tradeoff. :/ | 19:47 |
| sdake_ | one config file being which? | 19:47 |
| kfox1111 | so, like kolla's globals.yaml | 19:48 |
| kfox1111 | its easy to use. | 19:48 |
| kfox1111 | and kind of flexable. | 19:48 |
| sdake_ | kfox1111 are you familiar with /etc/kolla/config/glance.conf? | 19:48 |
| kfox1111 | sdake_: ansible only. | 19:48 |
| *** ppalacios has joined #openstack-kolla | 19:49 | |
| kfox1111 | :/ | 19:49 |
| sdake_ | right so you know that glance.conf gets merged with the global glance.conf | 19:49 |
| kfox1111 | yeah. something like that might work. | 19:49 |
| *** ppalacios has quit IRC | 19:49 | |
| sdake_ | right we have a pattern for flexiblity without trading off anything | 19:49 |
| kfox1111 | where you pass in the globals.yaml and config/glance.conf together as a 3rd party resource | 19:49 |
| kfox1111 | and glance operator would take those, run genconfig and spit out the glance-api/glance-registry configmaps. | 19:50 |
| sdake_ | and then register them with kubectl | 19:50 |
| kfox1111 | yeah. | 19:50 |
| kfox1111 | that might work. | 19:50 |
| kfox1111 | woudl require some retooling to kolla genconfig. | 19:51 |
| kfox1111 | but we probably need to do that anyway. | 19:51 |
| rhallisey | kfox1111, nah that's the way it is now | 19:51 |
| sdake_ | kolla genconfig does this already | 19:51 |
| rhallisey | we just need genconfig to be a general tool | 19:51 |
| kfox1111 | rhallisey: last I looked, it merged during shipping to the nodes. | 19:51 |
| rhallisey | because it's wired into ansible | 19:51 |
| sdake_ | kfox1111 you may be correct | 19:51 |
| sdake_ | and i may be in error | 19:51 |
| sdake_ | i think we dont want to pull in ansible into the operator, just the genconfig concept | 19:52 |
| kfox1111 | so wont work out of the box. but still, the idea seems sound. | 19:52 |
| rhallisey | it does merge when it send it | 19:52 |
| kfox1111 | yeah. | 19:52 |
| rhallisey | true | 19:52 |
| rhallisey | see what you're saying | 19:52 |
| rhallisey | the second thing is it's wired into ansible | 19:52 |
| rhallisey | becuase this is a module | 19:52 |
| kfox1111 | ok. so we're back I think to what I was saying initially, but fleshed out to what data is actually passed. | 19:53 |
| sdake_ | we can unwire it | 19:53 |
| sdake_ | ini merging is trivial | 19:53 |
| portdirect | hey guys I'm off (8pm here) - catch you on the flipside | 19:53 |
| sdake_ | see ya portdirect | 19:53 |
| rhallisey | see ya | 19:53 |
| kfox1111 | service operator takes config for the service. (globals.yaml stuff needed by nova, and nova config overrides) | 19:53 |
| *** portdirect is now known as portdirect_away | 19:53 | |
| kfox1111 | as a third party resource. | 19:53 |
| kfox1111 | it then does a genconfig on it to generate nova configmaps. | 19:54 |
| kfox1111 | it calls the nova db create/endpoint creation jobs | 19:54 |
| kfox1111 | then calls helm install on each of the nova microservices. | 19:54 |
| kfox1111 | profit! :) | 19:54 |
| kfox1111 | for the overarching operator | 19:54 |
| sdake_ | what registers the config maps - helm? | 19:54 |
| kfox1111 | the operator itself. | 19:54 |
| sdake_ | ok you left that step out :) | 19:54 |
| kfox1111 | 14:54 < kfox1111> it then does a genconfig on it to generate nova configmaps. | 19:55 |
| kfox1111 | sorry. that coudl be taken two ways. | 19:55 |
| sdake_ | rhallisey can you work that into the spec example | 19:55 |
| kfox1111 | that should explicitly state upload too. | 19:55 |
| sdake_ | rhallisey because i think that gives us best of both worlds | 19:55 |
| kfox1111 | yeah. | 19:55 |
| *** ppalacios has joined #openstack-kolla | 19:55 | |
| kfox1111 | any users that wanted to be really really explicit too, could basically bypass the genconfig | 19:55 |
| kfox1111 | by uploading the whole config file as an override. | 19:55 |
| sdake_ | kfox1111 pavo is doing this now | 19:56 |
| kfox1111 | ah. | 19:56 |
| Pavo | huh | 19:56 |
| kfox1111 | k. so we have prior art too. :) | 19:56 |
| Pavo | I am doing what | 19:56 |
| sdake_ | Pavo didn't you put all yoru config in /etc/kolla/config? | 19:56 |
| rhallisey | sdake_, ya I'll work that into the spec | 19:56 |
| sdake_ | from your prevous deployment? | 19:56 |
| rhallisey | question | 19:56 |
| Pavo | I can | 19:57 |
| rhallisey | does this mean genconfig is run at every layer | 19:57 |
| sdake_ | rhallisey we roll genconfig concept into operator itself | 19:57 |
| Pavo | never done it before | 19:57 |
| rhallisey | yes | 19:57 |
| rhallisey | but which layers? | 19:57 |
| kfox1111 | rhallisey: yeah, but not a complete run. | 19:57 |
| sdake_ | pavo oh thought you had, nm then | 19:57 |
| kfox1111 | we probably want to add a way to alllow genconfig to only do one service. | 19:57 |
| sdake_ | the base class can handle ini merging | 19:58 |
| rhallisey | kfox1111, does openstack-operator do any gencofnig | 19:58 |
| rhallisey | or do only the micro-service-operators? | 19:58 |
| rhallisey | actually | 19:58 |
| rhallisey | so each have a set of default | 19:58 |
| kfox1111 | rhallisey: no. | 19:58 |
| rhallisey | ok this is my q | 19:58 |
| kfox1111 | compute-kit-operator would just pass around kolla-kubernetes.yaml to each sub operator. | 19:59 |
| sdake_ | rhallisey microservice operators were a nice idea, but we decided (I think) they are unnecessary | 19:59 |
| kfox1111 | yeah. microservice operators would basically be no-ops. | 19:59 |
| sdake_ | what is this mystical kolla-kubernetes.yaml thing you speak of ;) | 19:59 |
| rhallisey | ok so only nova-operator then | 19:59 |
| kfox1111 | just pushing data around and possibly causing problems. | 19:59 |
| *** ppalacios has quit IRC | 20:00 | |
| rhallisey | sdake_, it's globals.yaml | 20:00 |
| sdake_ | ok | 20:00 |
| kfox1111 | yeah. | 20:00 |
| rhallisey | ok so I need to drop off one of the layers | 20:00 |
| rhallisey | and we're going with option 2 in the spec | 20:00 |
| rhallisey | also need to capture the configure step | 20:00 |
| Pavo | sdake_can you try https://ddi.hopto.org again please | 20:00 |
| *** papacz has quit IRC | 20:00 | |
| sdake_ | pavo no worky :( | 20:01 |
| kfox1111 | rhallisey: yes, but maybe with one caviot | 20:01 |
| kfox1111 | I really like option 4 for role nova-compute | 20:01 |
| sdake_ | pavo maybe someone else can try - could be a connection problem on my end? | 20:01 |
| kfox1111 | it would allow us to easily launch host-aggregates. | 20:01 |
| kfox1111 | must make a third party resource per host aggregate. | 20:01 |
| *** ppalacios has joined #openstack-kolla | 20:02 | |
| kfox1111 | so that may make sense to not have in the nova-operator. | 20:02 |
| sdake_ | re helm, what is its purpose in the architecture | 20:02 |
| sdake_ | with operators handling the configmaps? | 20:02 |
| kfox1111 | packaging native k8s objects. | 20:02 |
| kfox1111 | and packaging the operators. | 20:03 |
| kfox1111 | so, at the begining of the workflow: | 20:03 |
| sdake_ | atm its part of the workflow | 20:03 |
| kfox1111 | helm install compute-kit-operator | 20:03 |
| kfox1111 | kubectl create -f thrid-party-resource-for-compute-kit-operatr aka globals.yaml | 20:04 |
| kfox1111 | *sit back and watch the magic happen* | 20:04 |
| pprokop | Please don't do it. | 20:04 |
| kfox1111 | pprokop: which? | 20:04 |
| sdake_ | do which pprokop ? | 20:04 |
| pprokop | One of good things of using configmaps | 20:04 |
| pprokop | is to prepare config on remote machine | 20:05 |
| pprokop | push it to k8s | 20:05 |
| pprokop | and edit it when you need | 20:05 |
| pprokop | you don't need magic to do it for you | 20:05 |
| *** oxkipo has joined #openstack-kolla | 20:05 | |
| pprokop | People like when they know what software does | 20:05 |
| kfox1111 | pprokop: it will be using configmaps under the hood. | 20:05 |
| pprokop | That's what helm does | 20:05 |
| pprokop | I don;t like under hood | 20:05 |
| sdake_ | dont do which again? :) | 20:05 |
| kfox1111 | pprokop: I agree with that. as an operator, I want to do most workflows myself. | 20:06 |
| pprokop | +1 | 20:06 |
| kfox1111 | pprokop: usually, I just want to be able to turn them off entirely. | 20:06 |
| kfox1111 | and that, for sure we will keep. | 20:06 |
| kfox1111 | just don't use the worklfow bits. aka, the operators. | 20:06 |
| *** jtriley has quit IRC | 20:06 | |
| oxkipo | Hi. Im getting this weird error while trying to launch a vm with gpu. Last exception: internal error: process exited while connecting to monitor: warning: host doesn't support requested feature: CPUID.0 | 20:06 |
| kfox1111 | we're discussing how to add workflow on top, for those that want it. | 20:06 |
| oxkipo | Does someone know how to fix it? | 20:07 |
| pprokop | Building blocks should be as simple as possible and optional | 20:07 |
| sdake_ | oxkipo no idea - have to ask on openstack-nova, know nothing about gpus and nova :( | 20:07 |
| pprokop | and you should be able to pipe them | 20:07 |
| oxkipo | ok | 20:07 |
| pprokop | unix style | 20:07 |
| kfox1111 | pprokop: we're building it that way. | 20:07 |
| kfox1111 | no worries. :) | 20:07 |
| *** jtriley has joined #openstack-kolla | 20:07 | |
| sdake_ | we are keeping build separate from kubernetes objects on disk searpate from workflow (instantiation) from my understanding | 20:08 |
| kfox1111 | trying to make it as modular as possible so if you don't want to use something, you don't have to. | 20:08 |
| kfox1111 | sdake_: yeah. | 20:08 |
| kfox1111 | and even config generation. | 20:08 |
| kfox1111 | if you want. | 20:08 |
| pprokop | So how many people use vanilla kolla configs ? | 20:09 |
| sdake_ | right config generation is a separate thing too | 20:09 |
| kfox1111 | you can generate configs totally outside of workflow with the design we just came up with too. | 20:09 |
| sdake_ | pprokop eveyrone pretty much | 20:09 |
| kfox1111 | I don't. | 20:09 |
| sdake_ | pprokop although networking sees alot of reconfiguration in our defaults | 20:09 |
| sdake_ | which means either our defaults are wrong or they lack flexibility | 20:09 |
| sdake_ | people customize that with /etc/kolla/config | 20:09 |
| kfox1111 | networks are always the most varied. | 20:09 |
| pprokop | Power of solutions like helm is that it is so simple taht everyone can customize it | 20:10 |
| kfox1111 | I don't think thats a bad reflection on kolla. its just the way the state of networking is. | 20:10 |
| pprokop | without any middle layer | 20:10 |
| sdake_ | kfox1111 roger | 20:10 |
| pprokop | just change it | 20:10 |
| kfox1111 | pprokop: users shouldn't have to customaize it. | 20:10 |
| kfox1111 | thats what values are for. | 20:10 |
| kfox1111 | they can override things as needed. | 20:10 |
| kfox1111 | then the user doesn't have to be a developer. | 20:10 |
| sdake_ | kfox1111 helm contains config bits? | 20:10 |
| *** sdake_ is now known as sdake | 20:11 | |
| kfox1111 | sdake_: yes, in a way. | 20:11 |
| pprokop | It's simple go template | 20:11 |
| kfox1111 | pprokop: simple to some, not to others. ;) | 20:11 |
| sdake | how do those get registered with our configmaps that are merged from ondisk resources? | 20:11 |
| pprokop | just give it a yaml with variables it'lll template | 20:11 |
| kfox1111 | pprokop: took me a while to figure out a simple if and. ;) | 20:11 |
| kfox1111 | as golangs conditionals are just plane weird. | 20:11 |
| kfox1111 | very forthish. | 20:11 |
| kfox1111 | sdake: https://review.openstack.org/#/c/396296/16/helm/openstack-neutron/templates/_l3_agent_daemonset.yaml see this example: | 20:12 |
| kfox1111 | defaults are here: | 20:12 |
| kfox1111 | https://review.openstack.org/#/c/396296/16/helm/openstack-neutron/values.yaml | 20:12 |
| kfox1111 | then you can do something like helm install l3-agent --set docker_registry=myregistry.com | 20:12 |
| kfox1111 | stilll a work in progress. | 20:13 |
| kfox1111 | sdake: they won't be registerd in configmaps. | 20:13 |
| pprokop | Yeah but why just don't give people a good readme on how to prepare configs | 20:13 |
| kfox1111 | they will be in globals.yaml though if needed to be overrridden. | 20:13 |
| pprokop | instead of doing it for them | 20:13 |
| kfox1111 | pprokop: we will do both. | 20:14 |
| kfox1111 | docs for those wanting to do it manually, | 20:14 |
| kfox1111 | and automated for those that don't care to be bothered. :) | 20:14 |
| kfox1111 | best of both worlds.. | 20:14 |
| sdake | most people dont care to be bothered | 20:14 |
| Pavo | yeah but the config docs are so great | 20:14 |
| kfox1111 | right. | 20:14 |
| sdake | unless something is broken out of the box (like networking for eg) | 20:15 |
| kfox1111 | both use cases are valid. | 20:15 |
| kfox1111 | I fall into pprokops camp as an op. so I totally get it. | 20:15 |
| sdake | ok so helm fits into the archtecture with operators | 20:15 |
| sdake | or its an orthonal thing? | 20:15 |
| kfox1111 | but I also understand the desire for just an automated thing. | 20:15 |
| kfox1111 | sdake: it fits and is ortoganal to operators. | 20:16 |
| kfox1111 | operators will drive helm. | 20:16 |
| pprokop | I still believe more "magic-under-hood" more bugs and complex debugging. | 20:16 |
| kfox1111 | pprokop: I agree. | 20:16 |
| sdake | i thought operators were driving pod creation itself? | 20:16 |
| kfox1111 | but unless we provide magic, a lot of operaors will just skijp using kolla. | 20:16 |
| kfox1111 | sdake: no. driving helm. | 20:17 |
| sdake | without a viable workflow, nobody will use kolla-kubernetes except hard core operators | 20:17 |
| kfox1111 | helm provides the distribution mechanism for k8s native objeccts. | 20:17 |
| kfox1111 | operators consume them. | 20:17 |
| sdake | native objects being configmaps? | 20:18 |
| kfox1111 | native being, daemonsets/deployments/petsets/etc. excluding secrets and configmaps. | 20:18 |
| pprokop | Yes, native objects are things that you can describe via k8s manifests. | 20:18 |
| sdake | in a helm system where do ocnfigmaps come from? | 20:18 |
| sdake | (and secrets) | 20:19 |
| pprokop | You prepare template | 20:19 |
| kfox1111 | sdake: helm would have you put them in the package too. I think that will be to ridgid for us though. | 20:19 |
| sdake | i have a hard time believing helm has a one size fits all model for something like openstack | 20:19 |
| kfox1111 | as it would require all config options to be variables passed through their yaml. back to hte opinionated days. :/ | 20:19 |
| kfox1111 | right. | 20:19 |
| sdake | so convince me I'm wrong :) | 20:20 |
| kfox1111 | we can use helm for what its good at. packaging/shipping generic k8s objects with a template engine. | 20:20 |
| sdake | expand on template engine? | 20:20 |
| kfox1111 | workflow/config generation is outside of that. | 20:20 |
| pprokop | Just prepare san default some basic templating and very good README | 20:21 |
| kfox1111 | sdake: this: https://review.openstack.org/#/c/396296/16/helm/openstack-neutron/templates/_l3_agent_daemonset.yaml | 20:21 |
| pprokop | and Helm/Kpm works just as intended | 20:21 |
| kfox1111 | that isn't a native k8s object until its rendered. | 20:21 |
| kfox1111 | pprokop: aabsolutely not. | 20:21 |
| awiddersheim | does kolla have a way to run openstack cli commands easily? | 20:22 |
| sdake | kfox1111 rendered by what? | 20:22 |
| kfox1111 | we don't need random operators having to dig into soruce code just to set a flag like, i'm_on_ipoib_so_I_need_x | 20:22 |
| awiddersheim | for example running them in kolla-toolbox in some way? | 20:22 |
| sdake | do you mean instantiated? | 20:22 |
| kfox1111 | sdake: helm. | 20:22 |
| sdake | awiddersheim unfortunately we have not put the clients in a container at this time | 20:23 |
| sdake | awiddersheim i'm sure that would merge pretty easily | 20:23 |
| pprokop | Not dig into source code just change a helm template by adding this option | 20:23 |
| kfox1111 | sdake: yeah, think of a helm package as a class. its instantiated by the user with a command line such as: | 20:23 |
| awiddersheim | sdake, okay thanks | 20:23 |
| awiddersheim | seemed like kolla-toolbox has some of them | 20:23 |
| kfox1111 | helm install packagename --set my_init_value=foo | 20:23 |
| sdake | awiddersheim it does but thats not its purpose | 20:23 |
| awiddersheim | gotcha | 20:23 |
| awiddersheim | thanks | 20:23 |
| sdake | roger | 20:23 |
| sdake | what is my_init_value? | 20:24 |
| sdake | an override? | 20:24 |
| kfox1111 | that command akes in the default values, along with the user specified values, and renders the templates and uploads them to k8s. | 20:24 |
| kfox1111 | defaults are here: https://review.openstack.org/#/c/396296/16/helm/openstack-neutron/values.yaml | 20:24 |
| kfox1111 | templates here: https://review.openstack.org/#/c/396296/16/helm/openstack-neutron/templates/_l3_agent_daemonset.yaml | 20:24 |
| kfox1111 | any value in the values.yaml can be overriden at instantiation time. | 20:25 |
| sdake | ok on uploading to k8s, those defaults are placed where in the system? | 20:25 |
| pprokop | I think this is more clear then set x in global.yaml then this tool will magically render it as an option y in z configmaps | 20:25 |
| kfox1111 | they are not. the template is just rendered. | 20:25 |
| sdake | i see so values.yaml are replacements for stuff in the templates? | 20:26 |
| kfox1111 | pprokop: there will be a way to just pass the whole openstack config file verbatim through. | 20:26 |
| kfox1111 | for those that don't want any of the "magic" | 20:26 |
| kfox1111 | sdake: yeah. | 20:26 |
| kfox1111 | the templates can pull values out of values.yaml and the user can override them too. | 20:26 |
| pprokop | And then you can still see and change configmaps vis k8s cli or api | 20:26 |
| kfox1111 | pprokop: yes. | 20:26 |
| kfox1111 | pprokop: its a critical feature to be able to have an operator get exactly what they specified if thats what they want. | 20:27 |
| *** khamtamtun has quit IRC | 20:27 | |
| pprokop | just look how | 20:28 |
| pprokop | cclear thos configmaps are https://github.com/sapcc/openstack-helm/blob/master/nova/templates/etc/_nova.conf.tpl | 20:28 |
| kfox1111 | pprokop: look at how much stuff is hardcoded and not overridable without rebuilding packages | 20:29 |
| sdake | pprokop looks clear to me, but completely inflexible | 20:29 |
| pprokop | It's not hardcoded | 20:29 |
| pprokop | its suited for ones deployment | 20:29 |
| kfox1111 | I think we should be able to allow any manner of config generation. | 20:29 |
| kfox1111 | if a helm golang template works for you, great. :) | 20:30 |
| kfox1111 | if I want to do it with chef, thats great too. :) | 20:30 |
| kfox1111 | the system should be flexable enough to take it. | 20:30 |
| pprokop | So building small block would be prepare a tool for oflline config generation | 20:30 |
| pprokop | and use it or not | 20:30 |
| *** ppalacios has quit IRC | 20:30 | |
| kfox1111 | yeah. | 20:30 |
| pprokop | and then feed it to k8s | 20:31 |
| kfox1111 | right. | 20:31 |
| pprokop | not do it in operators | 20:31 |
| pprokop | or helm | 20:31 |
| kfox1111 | right. | 20:31 |
| pprokop | prepare-config | helm install | 20:31 |
| kfox1111 | if you don't want to do it in helm or operators, shouldn't have to do it that way. | 20:31 |
| *** khamtamtun has joined #openstack-kolla | 20:31 | |
| kfox1111 | or if you want to build a custom helm package just for the config, that would work too. | 20:31 |
| sdake | i dont see the issue with oprators pprokop | 20:32 |
| sdake | that your touching on | 20:32 |
| sdake | would you mind expanding | 20:32 |
| sdake | (I'm dense, sorry:) | 20:32 |
| kfox1111 | +1. I'm not quite understanding the issue either. | 20:32 |
| sdake | is it that you fear they are too complex? | 20:32 |
| pprokop | Yeah I hate thing doing something "under-hood" and dynamically create or change configmaps | 20:32 |
| kfox1111 | pprokop: I agree. | 20:33 |
| kfox1111 | what if we just make an option to the operator that says, don't do config period. | 20:33 |
| kfox1111 | assume configmaps preexist? | 20:33 |
| sdake | ya thts why its not the only optoin | 20:33 |
| kfox1111 | then it can be loaded in however you want. | 20:33 |
| pprokop | Yeah configmaps should preexist | 20:33 |
| kfox1111 | and you can still use operators. | 20:33 |
| sdake | that is an opinionated stance pprokop :) | 20:33 |
| kfox1111 | I guess there's a second way to do this. | 20:34 |
| pprokop | Of course | 20:34 |
| pprokop | everyone are :p | 20:34 |
| kfox1111 | we make a base class without genconfig, | 20:34 |
| sdake | what i mean by that is it forces operators into operating kolla in a specific way | 20:34 |
| kfox1111 | and make a nova operator enherit from that, | 20:34 |
| kfox1111 | and an a nova-operator-genconfig that adds genconfig stuff. | 20:34 |
| pprokop | I should start that I am against one single openstack operator | 20:34 |
| pprokop | also :d | 20:34 |
| kfox1111 | so a user either launches nova-operator-nogenconfig or nova-operator-genconfig | 20:34 |
| kfox1111 | pprokop: we arn't talking about that. | 20:35 |
| sdake | glance, glance ;) | 20:35 |
| kfox1111 | rrr... let me rephrase that. | 20:35 |
| pprokop | ok, my bad | 20:35 |
| kfox1111 | we desided it wouldn't be like that. one operator to rule them all. | 20:35 |
| kfox1111 | please see https://review.openstack.org/#/c/392257 | 20:35 |
| rhallisey | option 2 | 20:35 |
| kfox1111 | yeah. and since that has been written, we decided on option 2, | 20:36 |
| kfox1111 | and to merge layer 4 and layer 5. into just what is layer 5 currently. | 20:36 |
| sdake | kfox1111 yup we did agree on that | 20:37 |
| pprokop | Yeah i commented about option 5. | 20:37 |
| kfox1111 | pprokop: I don't quite get where you are going with option 5. can you please elaborate? | 20:38 |
| kfox1111 | are you saying no operator at all? | 20:38 |
| sdake | that is what he is saying | 20:38 |
| kfox1111 | cause the idea is, as an human operator you can choose any layer you want, not just stay at the top layer. | 20:38 |
| kfox1111 | so option 5 is just using layer 3 | 20:39 |
| pprokop | No, i mean operators are fine but more specific | 20:39 |
| pprokop | like operator for mariadb | 20:39 |
| pprokop | operator for rabbitmq | 20:39 |
| kfox1111 | thats option 2. | 20:39 |
| sdake | operator for glance.. | 20:39 |
| pprokop | do one thing and do it correctly | 20:39 |
| pprokop | I don't think that glance need operator | 20:39 |
| kfox1111 | yeah. agreed. | 20:39 |
| kfox1111 | thats option 2 as we've defined it I think. | 20:40 |
| sdake | indeed it does, and kfox1111 outlined why in the scrollback | 20:40 |
| kfox1111 | rabbit/mariadb/keystone/neutron/nova/etc all get one operator each. | 20:40 |
| kfox1111 | to best handle each of their own things. | 20:40 |
| kfox1111 | and one overarching operator, should you want it, to deploy all the other operators. | 20:40 |
| pprokop | Okay this is a part i don't understand this overwatching operator | 20:41 |
| kfox1111 | all that one does is laucnh the other operators and let them do their jobs. not meddle. :) | 20:41 |
| pprokop | k8s ? | 20:41 |
| pprokop | controller-manager ? | 20:41 |
| sdake | yup its a controller inside an operator container | 20:41 |
| kfox1111 | no. another operator. | 20:41 |
| pprokop | no | 20:41 |
| pprokop | but why kolla needs it ? | 20:41 |
| kfox1111 | the same way an operator for nova, laucnhes the various micrsoervices under it, | 20:41 |
| pprokop | k8s will make sure other operators are alive | 20:41 |
| sdake | yes but not launch them | 20:42 |
| pprokop | what you mean by launch them ? | 20:42 |
| kfox1111 | the compute-kit-operator laucnhes the openstack-service operators to make it easy to juts launch a compute kit. | 20:42 |
| sdake | to register the pods with kubernetes | 20:42 |
| kfox1111 | pprokop: its about workflow. | 20:42 |
| pprokop | why can't you just create a pod with mariadb-operator ? | 20:42 |
| kfox1111 | pprokop: you can. | 20:43 |
| pprokop | You mean dependencies ? | 20:43 |
| pprokop | Or order of deployment ? | 20:43 |
| kfox1111 | the overarching operator is for those that don't want to deal with the overarchign workflow. | 20:43 |
| kfox1111 | so, for the overarchign workflow, you need, | 20:43 |
| kfox1111 | nova, neutron, glance, cinder, opitonally keystone, and all its deps. | 20:43 |
| sdake | so kfox1111 - I think pprokop may be right here, we may not need an overarching operator | 20:43 |
| kfox1111 | the overarchign workflow kicks off those activities. | 20:43 |
| sdake | we could just do that with helm | 20:43 |
| pprokop | +3 | 20:44 |
| sdake | or does helm not do that | 20:44 |
| kfox1111 | hmm... | 20:44 |
| kfox1111 | does helm support 3rd party resoruces? | 20:44 |
| pprokop | I think so | 20:44 |
| pprokop | it's just manifest | 20:44 |
| kfox1111 | can it ejnsure it wont create resource X before it creates resource Y? | 20:44 |
| *** eaguilar has quit IRC | 20:45 | |
| sdake | kfox1111 keen point | 20:45 |
| kfox1111 | for example, create mariadb, wait till sane, launch keystone operator worfklow, which creates entris in the db, fires up deployment | 20:45 |
| sdake | the overarching operator is responsibel for dep management | 20:45 |
| kfox1111 | then on to nova, which creates a nother db, registers keystone endpoints, etc.... | 20:46 |
| kfox1111 | the workflow needs some way to deal with deps. | 20:46 |
| kfox1111 | I don't think helm can do that. | 20:46 |
| kfox1111 | I think it is fairly simple for an operator to do it. | 20:46 |
| kfox1111 | and if helm ever gains that functionality, | 20:46 |
| pprokop | what about kubernetes-entrypoint just for operators ? | 20:46 |
| kfox1111 | I think it will b e relatively easy to switch out the operator for helm at that point. | 20:47 |
| pprokop | i saw you played with it | 20:47 |
| kfox1111 | hmm... | 20:47 |
| kfox1111 | so nova-operator would be blocked from fully spawning until keystone is done? | 20:47 |
| kfox1111 | interesting. | 20:47 |
| sdake | kubernetes-operator feels like way too much magic to me, but i guess in one operator container (the overarching one) it wouldn't be damaging | 20:47 |
| pprokop | and just prepare really good rediness-probes | 20:47 |
| kfox1111 | very interesting. | 20:48 |
| pprokop | and it is much simplier | 20:48 |
| pprokop | much clearer for operator | 20:48 |
| kfox1111 | entrypoint might work for that use case. | 20:48 |
| kfox1111 | (I think entrypoint will work for some of the pods too btw) | 20:48 |
| sdake | i think we want to take care not to throw in the kitchen sink tho :) | 20:48 |
| pprokop | I know i wrote it :p | 20:48 |
| kfox1111 | pprokop: do you have a container prebuilt for it? | 20:49 |
| kfox1111 | would make my life easier to test with. | 20:49 |
| srwilkers | disappear for a few hours and come back to a wall of text. time to play catch up | 20:49 |
| sdake | we have identified alot of tasks the operator needs to do | 20:49 |
| kfox1111 | srwilkers: heh. yeah. :) | 20:49 |
| sdake | not the overarchign one, but the UNDERCLOUD operators | 20:49 |
| kfox1111 | srwilkers: dont get scared. we're all friends. :) | 20:50 |
| sdake | srwilkers get on the train dude - its leaving soon :) | 20:50 |
| rhallisey | srwilkers, you have a lot of reading :P | 20:50 |
| srwilkers | D: | 20:50 |
| sdake | so anyway these underwear operators need to do several things | 20:50 |
| kfox1111 | pprokop: sdake the way we have our templates aranged, with a generic template, | 20:50 |
| sdake | 1. merge configs | 20:50 |
| sdake | 2. create databases | 20:50 |
| sdake | 3. create users | 20:50 |
| sdake | 4. create keystone users | 20:50 |
| *** khamtamtun has quit IRC | 20:51 | |
| sdake | 5. create keystone roles | 20:51 |
| kfox1111 | I think we could make a single function that puts kubernetes-entrypoint in an init container, and that slides it in to every kolla-kubernetes pod. | 20:51 |
| sdake | 6. start child micro-service pods | 20:51 |
| kfox1111 | so if an human operator wanted to deploy it that way, it would be easy to do. | 20:51 |
| kfox1111 | totally unrelated to the operator converation going on right now though. | 20:51 |
| sdake | kfox1111 i think we want to avoid parallel workflows | 20:51 |
| sdake | kfox1111 i've seen that happen (internally) and it doesn't end well | 20:51 |
| sdake | let me tell you how it ends | 20:51 |
| kfox1111 | sdake: its up to the operator to decide how best to do it. if that is super cheep to implement, it lets some folks do it the way they need, then great. | 20:52 |
| pprokop | I still think kolla should use as many native k8s features as possible | 20:52 |
| pprokop | like jobs for doing databases etc | 20:52 |
| sdake | it ends in two parallel implementations diverging dramatically and people parting ways | 20:52 |
| kfox1111 | pprokop: +1 to native features. been trying to do that as much as possible. | 20:52 |
| rhallisey | ya I agree with native features | 20:52 |
| kfox1111 | sdake: we already have that. I think this might be a way to get some of them back. ;) | 20:52 |
| pprokop | So i understand a need for an operator for features that k8s doesn't have | 20:52 |
| pprokop | back-ups | 20:53 |
| kfox1111 | pprokop: and an operator would only be there until k8s has native features I think. | 20:53 |
| pprokop | adding members to clusters | 20:53 |
| sdake | kfox1111 lubernetes is never going to add orchestration broadly | 20:53 |
| *** khamtamtun has joined #openstack-kolla | 20:53 | |
| kfox1111 | sdake: agreed, I think.... | 20:53 |
| pprokop | But back-ups can be done via scheduled-jobs ? | 20:53 |
| kfox1111 | sdake: but helm may | 20:53 |
| sdake | kfox1111 the committers believe that is someone elses job | 20:53 |
| sdake | kfox1111 well nobody ruled out a refactor down the road ;) | 20:53 |
| kfox1111 | and I think it will be hard to distignuish helm and k8s at some point in the neer future. | 20:54 |
| kfox1111 | but, thats just speculation. | 20:54 |
| pprokop | Okay, guys thank you for a productive discussion it's like 10 pm in Gdansk :D | 20:54 |
| *** n3v3rm0r3r has quit IRC | 20:54 | |
| sdake | i think for now, an overarching operator is more tidy then introducing a dep just for one type of container | 20:54 |
| pprokop | Have to go | 20:54 |
| sdake | pprokop enjoy | 20:55 |
| pprokop | bye | 20:55 |
| rhallisey | see ya | 20:55 |
| *** khamtamtun has quit IRC | 20:55 | |
| kfox1111 | pprokop: thanks for helping. :) | 20:55 |
| kfox1111 | we're trying to make things as inclusive as we can. | 20:55 |
| kfox1111 | we're all trying to figure this stuff out. | 20:56 |
| inc0 | I had meeting, could someone give me quick recap on where we are now | 20:56 |
| inc0 | ? | 20:56 |
| kfox1111 | k. | 20:56 |
| sdake | inc0 no more micro-oprators | 20:56 |
| sdake | only operators | 20:56 |
| kfox1111 | and option 2. | 20:56 |
| inc0 | so operator per nova for example | 20:56 |
| inc0 | cool | 20:56 |
| sdake | operators = workflow, workflow, image gen, config gen, all separate things | 20:57 |
| kfox1111 | https://review.openstack.org/#/c/392257/9/specs/kolla-kubernetes-arch.rst | 20:57 |
| sdake | overarching operator undefined as to implementation | 20:57 |
| inc0 | how do we model dependencies? | 20:57 |
| sdake | the operators launch their children | 20:57 |
| kfox1111 | operators handle direct dependencies. | 20:57 |
| inc0 | ok, sooo what we can do is opeator - pod | 20:58 |
| kfox1111 | overarching operator deploys operators (and therefore all dependencies) | 20:58 |
| inc0 | that becomes ready when service is ready | 20:58 |
| sdake | i'm still stuck on how helm fits in | 20:58 |
| inc0 | and overarching operator will model deps between services based on lower level operator stauts | 20:58 |
| sdake | even know kfox1111 has repeated it to me atleast 5 different ways | 20:58 |
| inc0 | sdake, helm will be called from sub-operator | 20:59 |
| sdake | know/though | 20:59 |
| inc0 | right kfox1111 ? | 20:59 |
| kfox1111 | helm provides packages for native k8s objects and a template engine. | 20:59 |
| inc0 | can we model dependencies in yaml? | 20:59 |
| qwang | How it deals with dependencies shared among services? | 20:59 |
| sdake | yaml can model anything | 20:59 |
| kfox1111 | inc0: do we need to? | 20:59 |
| sdake | qwang good question that is unanswered | 20:59 |
| inc0 | kfox1111, we need to have it modeled somehow | 20:59 |
| kfox1111 | modeled how? | 21:00 |
| inc0 | qwang, what do you mean? an example please:) | 21:00 |
| kfox1111 | are you asking for a way to easiy diagram it? | 21:00 |
| kfox1111 | or query it? | 21:00 |
| kfox1111 | or just use it? | 21:00 |
| inc0 | kfox1111, each serivce will depend on multiple jobs/configmaps/pods | 21:00 |
| kfox1111 | inc0: right. | 21:00 |
| qwang | inc0: like mariadb is a dependency of nova/keystone/etc. | 21:00 |
| inc0 | we need to code it down somehow | 21:00 |
| kfox1111 | inc0: but is that just a bit of python code, or something else? | 21:00 |
| kfox1111 | right. | 21:01 |
| inc0 | well, if we use well defined yaml | 21:01 |
| inc0 | we can write python to handle it | 21:01 |
| inc0 | and not write 100 different python scripts | 21:01 |
| kfox1111 | if we write well defined python, we can use python to handle it. :) | 21:01 |
| * kfox1111 shrugs. yaml would be fine. | 21:01 | |
| kfox1111 | or... | 21:02 |
| inc0 | qwang, easy, nova -> depends on -> mariadb, keystone -> depends on -> mariadb | 21:02 |
| kfox1111 | mermaid https://knsv.github.io/mermaid/ :) | 21:02 |
| * kfox1111 runs | 21:02 | |
| inc0 | kfox1111, let's write it in Prolog! | 21:02 |
| kfox1111 | graph LR | 21:02 |
| srwilkers | inc0: prolog, omg | 21:02 |
| kfox1111 | nova -> mariadb | 21:02 |
| rhallisey | o.o | 21:03 |
| kfox1111 | :) | 21:03 |
| inc0 | nova -> mariadb, keystone | 21:03 |
| inc0 | to be more exact | 21:03 |
| kfox1111 | go graphvis! :) | 21:03 |
| inc0 | easily graphvisable:) | 21:03 |
| inc0 | and each node can be include of sub-graphs | 21:03 |
| inc0 | much like heat | 21:03 |
| kfox1111 | (thats why I asked about visualization.. ;) | 21:03 |
| qwang | kfox1111: I learned prolog before | 21:03 |
| kfox1111 | qwang: I'm kind of partial to prolog. it has some cool features | 21:04 |
| sdake | kfox1111 can you teach me how helm fits in since it has custom config with what we agreed to above | 21:04 |
| sdake | my professors tortured me with Ada in university | 21:04 |
| kfox1111 | sdake: there are two types of config. | 21:04 |
| srwilkers | +1 kfox1111 | 21:04 |
| sdake | anyone ever heard of Ada? | 21:04 |
| kfox1111 | sdake: configmaps are used for passing config files to openstack services running in the pods. | 21:04 |
| wirehead_ | I keep wanting to spend some recreational hacking time learning Prolog. | 21:04 |
| qwang | sdake: i did | 21:04 |
| kfox1111 | theres config that also helps generate the actual k8s objects to be launched. | 21:05 |
| kfox1111 | for example. | 21:05 |
| *** Pavo has quit IRC | 21:05 | |
| kfox1111 | k8s uses the side car pattern to do things. | 21:05 |
| kfox1111 | if you wanted to add logging to your pod, you add, say a fluentd or heka container to your pod. | 21:05 |
| *** Pavo has joined #openstack-kolla | 21:05 | |
| sdake | the last time i heard side car it was in relationship to ruby prior to that project crashing and burning and decimating about 50 engineers | 21:05 |
| kfox1111 | helm lets us write one template for the pod, that lets you conditionally set if you want 0 logging, heka, or fluentd. | 21:05 |
| inc0 | kfox1111, so we need 2 pieces of code | 21:05 |
| inc0 | 1. generate dependency graph yamls | 21:06 |
| inc0 | 2. execute | 21:06 |
| inc0 | stretch 3. keep it running | 21:06 |
| kfox1111 | sdake: sidecars are one of the founding principals of the way k8s works. so really important. | 21:06 |
| kfox1111 | inc0: sounds good. | 21:07 |
| sdake | ok pls explain or point to docs ;) | 21:07 |
| sdake | inc0 fwiw we are merging configs as well | 21:07 |
| kfox1111 | I've got a presentation on it I'm trying to get released... but legal... anyway.... | 21:07 |
| kfox1111 | the idea is similar to lego's or the regular unix phylosophy. | 21:07 |
| inc0 | sdake, this will be more complex | 21:07 |
| kfox1111 | write a tool that does one thing well. | 21:08 |
| inc0 | but we can template it all the wya | 21:08 |
| kfox1111 | then aggregate them to do a bigger thing. | 21:08 |
| kfox1111 | with k8s, a pod is a collection of containers. | 21:08 |
| inc0 | let's start with jinja2 + python tho plz | 21:08 |
| kfox1111 | each container shoudl do one thing well. | 21:08 |
| sdake | inc0 the idea is to take genconfig model OUT of ansible and put in the base object for operators | 21:08 |
| inc0 | sdake, yeah, well, doable but later | 21:08 |
| kfox1111 | and the k8s pod assembles them into somethign greator then the sum of ther parts. | 21:08 |
| kfox1111 | for example. | 21:09 |
| sdake | inc0 shame you were in a meeting we agreed to all this stuff already | 21:09 |
| sdake | can you read the scrollback? | 21:09 |
| kfox1111 | say I create an nginx container. all I put in it is a webserver. | 21:09 |
| inc0 | sdake, I'm all for moving configs out of ansible | 21:09 |
| kfox1111 | that is kind of useful, kind of not. | 21:09 |
| inc0 | just you do know that's it's major undertaking right? | 21:09 |
| kfox1111 | now say I make a second container. all it has is git in it. | 21:09 |
| kfox1111 | again, a useful container, but not teribly. | 21:09 |
| sdake | inc0 right - I understand the challenges - I htink the idea is to short circuit that by doing some duplication | 21:10 |
| kfox1111 | now, in a k8s object/pod I combine the two. one checks out a git repo and every 10 minutes, does a git update. and an nginx webserver pointint to that shared volume. | 21:10 |
| *** oxkipo has quit IRC | 21:10 | |
| rhallisey | the config generation is going to have to be a parallel effort | 21:10 |
| kfox1111 | now I have a scalable webserver building block made up of smaller blocks. | 21:10 |
| inc0 | can we start by makind deployment robust with current config generation please? | 21:10 |
| inc0 | or have it pararell, that works too | 21:10 |
| inc0 | if we have volunteers to take on it | 21:10 |
| inc0 | but for foxtrot sake don't block rest of the work on it | 21:10 |
| inc0 | please | 21:11 |
| kfox1111 | the idea is nginx is your basic webserver, and git was added as a sidecar to greatly ehnance its base functionality | 21:11 |
| kfox1111 | does that make sense? | 21:11 |
| inc0 | deployment with ansible-gen configs >> no deployment in ocata | 21:11 |
| sdake | god it | 21:11 |
| sdake | got it | 21:11 |
| sdake | so can you explain how we get helm to work with our config maps we register with our third party resource associated with our operator? | 21:12 |
| kfox1111 | in that model a k8s object is the glue that ties it all together. | 21:12 |
| kfox1111 | helm just deploys the k8s glue. | 21:12 |
| kfox1111 | it doesnt' touch configmaps or third party resoruces. | 21:12 |
| sdake | even if the helm package has configmaps in it? | 21:12 |
| kfox1111 | the operator drives helm to create the microservices. | 21:12 |
| kfox1111 | I dont think we do configmaps in helm. | 21:12 |
| kfox1111 | (if an human operator wants to upload configmaps with their own heml packages, thats fine) | 21:13 |
| kfox1111 | (we just arn't going to do that with our stuff) | 21:13 |
| sdake | so helm packages all the stuff together, config provided to helm during launching how? | 21:14 |
| sdake | by the operator preregisteirng the configmaps? | 21:14 |
| kfox1111 | helm doens't need the config map. | 21:14 |
| kfox1111 | it creates a k8s object that does though. | 21:14 |
| sdake | no but the applications that helm launch do | 21:14 |
| kfox1111 | the operator will create it, or a human will. | 21:14 |
| kfox1111 | our helm packages wil lassume they already exist. | 21:15 |
| *** fguillot has quit IRC | 21:15 | |
| kfox1111 | and even if they don't, k8s just keeps slwoly retrying until they show up. | 21:15 |
| sdake | operator does following then: | 21:16 |
| sdake | 1. reads configmap from (???) | 21:16 |
| sdake | (the software operator) | 21:16 |
| kfox1111 | operators read 3rd party resources. | 21:16 |
| sdake | operator does following then: | 21:16 |
| sdake | 1. reads configmap from third party resource | 21:16 |
| sdake | right | 21:16 |
| sdake | 2. creates db | 21:16 |
| sdake | 3. creates db user | 21:16 |
| sdake | 4. creates keystone user | 21:16 |
| sdake | 5. creates keystone role if needed | 21:17 |
| kfox1111 | 1. configmap data, and optional helm override vars. | 21:17 |
| sdake | 6. reads the configmap data from thirdparty resource and writes it into helm packaging | 21:17 |
| sdake | 7. produces a helm package | 21:17 |
| sdake | 8. uses helm install to launch the schebang? | 21:17 |
| kfox1111 | 6. no. writes it to configmaps. | 21:17 |
| kfox1111 | skip 7. | 21:17 |
| sdake | we dont need a helm package? | 21:17 |
| kfox1111 | 8 use helm to launch helm packages. | 21:18 |
| kfox1111 | we don't need an overarching helm package for a service, or configmaps. | 21:18 |
| kfox1111 | just helm packages for the microservices. | 21:18 |
| sdake | ok so in this model helm is taking place of micro-operator | 21:18 |
| kfox1111 | helm install kolla/neutron-l3-agent | 21:18 |
| sdake | what other value does that add? | 21:19 |
| kfox1111 | yeah, kind of, yeah. | 21:19 |
| kfox1111 | sdake: the stuff defined in that doc you had me write on "why helm" :) | 21:19 |
| inc0 | https://github.com/inc0/navigator | 21:19 |
| sdake | i havne't seen that doc kfox1111 | 21:19 |
| inc0 | thoughts? | 21:19 |
| sdake | but i'd love to read it :) | 21:19 |
| kfox1111 | sdake: https://etherpad.openstack.org/p/kolla-ocata-summit-kolla-k8s-road-map please read. will make it much easer it me. :) | 21:20 |
| sdake | inc0 looks ambitious :) | 21:20 |
| kfox1111 | the "helm thoughts" section. | 21:20 |
| inc0 | not as much | 21:20 |
| inc0 | it's really only reimplementation of heat | 21:20 |
| inc0 | :P | 21:20 |
| inc0 | but in reality it won't be that hard for k8s | 21:21 |
| sdake | lines 64+? | 21:21 |
| kfox1111 | inc0: I think your are just thinking deployment and not upgrades. | 21:21 |
| kfox1111 | deployment is pretty easy. upgrades, not so much. | 21:21 |
| inc0 | kfox1111, negative, upgrades can be done in this model too | 21:21 |
| kfox1111 | sdake: 60+ | 21:21 |
| kfox1111 | inc0: sure. but I think it will be hard. thats all. :) | 21:22 |
| inc0 | so this will stretch 3. keep it running | 21:22 |
| sdake | kfox1111 ok - so in a nutshell, operators don't offer enough flexibility since they onlly operate in "one domain" | 21:22 |
| sdake | kfox1111 whereas helm can operate in many | 21:22 |
| inc0 | it will do while: true > check end state and match existing to end | 21:22 |
| kfox1111 | sdake: one of the reasons, yes. | 21:23 |
| inc0 | wanna do nova db_migration? kubectl delete job nova_bootstrap | 21:23 |
| kfox1111 | sdake: I want to be able to use layers helm down, without using operators at all. | 21:23 |
| kfox1111 | or selectively use some operators too. | 21:23 |
| kfox1111 | inc0: nova migration's never been that easy. :/ | 21:23 |
| sdake | kfox1111 you spoke about helm at the microservice level | 21:24 |
| inc0 | kfox1111, well it will rerun job in this case | 21:24 |
| sdake | wht about at the service level? | 21:24 |
| kfox1111 | sdake: operators are the service level. | 21:24 |
| sdake | and helm doesn't make sense there because? | 21:24 |
| rhallisey | sdake, service level is workflow | 21:25 |
| sdake | (in addition to operators I mean) | 21:25 |
| kfox1111 | at the service level, things need workflow. | 21:25 |
| kfox1111 | helm's is too basic I think. | 21:25 |
| inc0 | kfox1111, upgrade will go like this: delete nova_bootstrap job -> this mechanism will rebootstrap | 21:25 |
| kfox1111 | it very well may grow it at some point though. | 21:25 |
| inc0 | k8s rolling upgrade after that | 21:25 |
| kfox1111 | inc0: thats not how it traditionally has worked. | 21:26 |
| inc0 | kfox1111, how did it work traditionally? | 21:26 |
| sdake | kfox1111 then above that service level is helm? | 21:26 |
| kfox1111 | they usually have several phases where there are expand and contracts in between. | 21:26 |
| sdake | or an overarching operator? | 21:26 |
| inc0 | ah, not with nova | 21:26 |
| kfox1111 | services are restarted in between. | 21:26 |
| inc0 | so take a look at our upgrade plays | 21:26 |
| kfox1111 | compte-kit-operator -> service-operator -> helm -> k8s -> kolla-containers | 21:27 |
| inc0 | but I agree kfox1111 it needs more tinkering | 21:27 |
| kfox1111 | inc0: no downtime upgrades are becoming a thing, and they are complex. | 21:27 |
| sdake | ok my brain has become eventually consistent with our discussion | 21:27 |
| inc0 | kfox1111, not really | 21:27 |
| inc0 | well | 21:27 |
| inc0 | yeah | 21:27 |
| inc0 | sighub services after upgrade and all that | 21:28 |
| inc0 | we won't solve it in k8s anytime soon | 21:28 |
| kfox1111 | and each service wants to implement 0 downtime upgrades differently. :/ | 21:28 |
| inc0 | yeah | 21:28 |
| inc0 | we won't solve it in k8s anytime soon\ | 21:28 |
| kfox1111 | so the logic will be different in each operator. :/ | 21:28 |
| *** mgiles has quit IRC | 21:28 | |
| inc0 | so here's my approach | 21:28 |
| inc0 | 1.0 doesn't need upgrades in full scope | 21:29 |
| inc0 | 2.0 does | 21:29 |
| kfox1111 | so long as we don't make upgrades and we leave ourselves an easy path to enabling them, I'm good. :) | 21:29 |
| sdake | inc0 ya thats what i told hogepodge :) | 21:29 |
| inc0 | so for 1.0 we need to allow deploy and not burn bridges before upgrade | 21:29 |
| kfox1111 | cause upgrade will be hard enough without adding more hardness to it. :) | 21:29 |
| kfox1111 | yeah. | 21:29 |
| kfox1111 | +1 | 21:29 |
| sdake | at cncf | 21:29 |
| inc0 | but if we try to solve it now, we'll fail to deliver for ocata | 21:29 |
| rhallisey | agreed | 21:29 |
| inc0 | and we can't fail to deliver for ocata | 21:29 |
| * kfox1111 nods | 21:30 | |
| sdake | i tend to believe we can sneak reconfig in there too | 21:30 |
| inc0 | so, is this approach acceptable for PoC? https://github.com/inc0/navigator/blob/master/mariadb.yaml | 21:30 |
| kfox1111 | so.. here's the deal.... | 21:31 |
| inc0 | sdake, agree we'd love to, but again, priority 1 - deploy | 21:31 |
| kfox1111 | I wantn multi-instance mariadb. | 21:31 |
| kfox1111 | and rabbit. | 21:31 |
| kfox1111 | the logic has to work in that case. | 21:31 |
| inc0 | well, you do this with pod definition and such | 21:31 |
| inc0 | so not really operator | 21:32 |
| inc0 | init container and bootstrap jobs | 21:32 |
| inc0 | and configmaps | 21:32 |
| kfox1111 | yeah. just thorwing that out there. | 21:32 |
| sdake | what is mariadb_configmap | 21:32 |
| kfox1111 | gota be caureful not to code in assumptions like, there is only ever one mariadb named "mariadb" | 21:32 |
| inc0 | this will only run stuff in correct order | 21:32 |
| sdake | a container? | 21:32 |
| inc0 | sdake, it's configmap... | 21:32 |
| inc0 | config file in k8s | 21:32 |
| inc0 | has to exist before run mariadb | 21:32 |
| sdake | nah it goes in a third party resource | 21:32 |
| kfox1111 | inc0: this kind of replicates whatas in kolla-kubernetes/etc/kolla-kubernetes/services.yaml | 21:33 |
| inc0 | sdake, k8s != helm | 21:33 |
| sdake | i think what you want is a third party resource there instead of configmap inc0 | 21:33 |
| kfox1111 | thoug the workflow bit is a bit a bit rusty. | 21:33 |
| inc0 | kfox1111, with added notion of deps in between | 21:33 |
| kfox1111 | yeah. | 21:33 |
| inc0 | I'm pretty sure we want configmap | 21:33 |
| inc0 | configmap is k8s native mechanism | 21:33 |
| kfox1111 | yeah. we do want configmaps. | 21:33 |
| inc0 | you | 21:34 |
| sdake | i'm pretty sure config maps get loaded into third party objects ;) | 21:34 |
| kfox1111 | and a helm package too. | 21:34 |
| *** Jeffrey4l has quit IRC | 21:34 | |
| inc0 | you're mixing names sdake | 21:34 |
| kfox1111 | sdake: when driven by operators, yes. | 21:34 |
| inc0 | we need to generate our own configs | 21:34 |
| sdake | inc0 plase read the scrollback | 21:34 |
| kfox1111 | and the operator puts it in a configmap when requested. | 21:34 |
| sdake | we just had a 4 hour debate on this topic | 21:34 |
| kfox1111 | we probably need to diagram all this stuff and get it ritten down. | 21:35 |
| rhallisey | ya I'll get it in the spec | 21:35 |
| srwilkers | kfxo1111: agreed | 21:35 |
| inc0 | and agree on nomenclature | 21:35 |
| kfox1111 | so we won't have to keep talking about it for anyone new that wants to come in. | 21:35 |
| kfox1111 | ok. gota go for a while. lets iterate on the spec for a bit with what we got so far. a lot of progress I think though. :) | 21:49 |
| *** berendt has quit IRC | 21:57 | |
| *** v1k0d3n has joined #openstack-kolla | 21:59 | |
| *** nihilifer has quit IRC | 22:00 | |
| *** lrensing has quit IRC | 22:01 | |
| srwilkers | welcome to the party v1k0d3n | 22:01 |
| v1k0d3n | hey! | 22:02 |
| v1k0d3n | is there a party? | 22:02 |
| v1k0d3n | i think i'm late | 22:02 |
| srwilkers | very late | 22:03 |
| srwilkers | been an all day ordeal | 22:03 |
| srwilkers | and now all's quiet | 22:03 |
| v1k0d3n | hello kfox1111 | 22:03 |
| v1k0d3n | oh boy | 22:03 |
| kfox1111 | v1k0d3n: ping | 22:03 |
| v1k0d3n | pong | 22:04 |
| inc0 | v1k0d3n, I'm ragecoding operator to deal with deps | 22:04 |
| v1k0d3n | lol | 22:05 |
| srwilkers | inc0 in prolog? XD | 22:05 |
| v1k0d3n | you know...it's always good when someone say's they're ragecoding. | 22:05 |
| kfox1111 | v1k0d3n: pm | 22:05 |
| *** n3v3rm0r3r has joined #openstack-kolla | 22:07 | |
| sdake | i rage diagram | 22:10 |
| sdake | when i'm in a rage | 22:10 |
| inc0 | I need whiteboard in my home | 22:12 |
| srwilkers | im actually about to hit half the walls in my office at home with whiteboard paint | 22:13 |
| srwilkers | pretty excited about it | 22:13 |
| *** hyakuhei has joined #openstack-kolla | 22:13 | |
| kfox1111 | oh, whiteboard paint. nice. :) | 22:14 |
| inc0 | yeah, that'd be great | 22:14 |
| inc0 | when I have house, that's what I'm going to do in study | 22:14 |
| kfox1111 | :) | 22:14 |
| wirehead_ | Dono, I’ve got a whiteboard in my geekroom, but I’m usually finding that I end up using Paper on my iPad. | 22:16 |
| inc0 | I overuse mindmaps | 22:18 |
| *** krtaylor has quit IRC | 22:20 | |
| *** schwicht has quit IRC | 22:24 | |
| kfox1111 | inc0: btw, if you look at kolla-kubernetes/tests/bin/ceph_workflow, | 22:24 |
| kfox1111 | it has some dep stuff encoded in it. | 22:24 |
| kfox1111 | indirectly. | 22:24 |
| inc0 | yeah, I'll probably use execs with kolla-k8s cli for purpose of PoC | 22:25 |
| *** v1k0d3n has quit IRC | 22:26 | |
| *** jtriley has quit IRC | 22:27 | |
| wirehead_ | I dono, I’m an incredibly visual thinker, but I’m finding that I need to diagram problems less and less. | 22:30 |
| kfox1111 | yeah. I find them most useful when I'm trying to explain an idea to others. | 22:31 |
| kfox1111 | I can see the diagram just fine in my head most of the time. its getting someone else to see it thats hard. :) | 22:31 |
| *** srwilkers has quit IRC | 22:34 | |
| *** dave-mccowan has quit IRC | 22:38 | |
| *** jheroux has quit IRC | 22:38 | |
| *** ayoung has quit IRC | 22:39 | |
| *** hyakuhei has quit IRC | 22:42 | |
| *** hyakuhei has joined #openstack-kolla | 22:42 | |
| *** hyakuhei has quit IRC | 22:42 | |
| *** hyakuhei has joined #openstack-kolla | 22:42 | |
| *** schwicht has joined #openstack-kolla | 22:44 | |
| *** Pavo_ has joined #openstack-kolla | 22:47 | |
| *** Pavo has quit IRC | 22:51 | |
| *** Pavo_ is now known as Pavo | 22:51 | |
| *** schwicht has quit IRC | 23:02 | |
| *** v1k0d3n has joined #openstack-kolla | 23:04 | |
| *** Pavo has quit IRC | 23:05 | |
| *** lamt has quit IRC | 23:05 | |
| *** Pavo has joined #openstack-kolla | 23:05 | |
| *** v1k0d3n has quit IRC | 23:09 | |
| *** krtaylor has joined #openstack-kolla | 23:10 | |
| *** schwicht has joined #openstack-kolla | 23:12 | |
| *** chas_ has quit IRC | 23:17 | |
| *** msimonin has quit IRC | 23:18 | |
| *** chas_ has joined #openstack-kolla | 23:18 | |
| *** chas_ has quit IRC | 23:20 | |
| *** chas_ has joined #openstack-kolla | 23:20 | |
| *** absubram has quit IRC | 23:21 | |
| *** chas_ has quit IRC | 23:25 | |
| *** Pavo_ has joined #openstack-kolla | 23:28 | |
| *** schwicht has quit IRC | 23:29 | |
| *** Jeffrey4l has joined #openstack-kolla | 23:31 | |
| *** nihilifer has joined #openstack-kolla | 23:31 | |
| *** Pavo has quit IRC | 23:32 | |
| *** Pavo_ is now known as Pavo | 23:32 | |
| *** schwicht has joined #openstack-kolla | 23:32 | |
| *** srwilkers has joined #openstack-kolla | 23:34 | |
| sdake | kfox1111 no doubt re diagrms | 23:34 |
| *** schwicht has quit IRC | 23:35 | |
| *** Pavo has quit IRC | 23:36 | |
| sdake | inc0 while your rage coding | 23:37 |
| sdake | are you aware of the need for third party resources | 23:37 |
| inc0 | wassup | 23:37 |
| inc0 | still can be done | 23:37 |
| sdake | what i mean is if you are going to prototype operators might as well do it right with third party resources | 23:37 |
| inc0 | so by third party resources you mean somebody else adding a config from external? | 23:38 |
| *** Pavo has joined #openstack-kolla | 23:38 | |
| sdake | third party resources are how you control operators | 23:38 |
| sdake | rhallisey you have that exntending api link handy? | 23:38 |
| *** nihilifer has quit IRC | 23:38 | |
| rhallisey | https://github.com/kubernetes/kubernetes/blob/master/docs/design/extending-api.md | 23:39 |
| sdake | you make one of those | 23:39 |
| sdake | for each operator your controlling | 23:39 |
| sdake | in it feeds configmaps, globals.yml, and whatever other stuff we need | 23:40 |
| inc0 | completely orthogonal to what I have in mind | 23:40 |
| sdake | well then you are not ragecoding operators | 23:40 |
| sdake | enjoy | 23:40 |
| inc0 | I think you're too bound to names | 23:41 |
| sdake | no, im bound to ideas | 23:41 |
| inc0 | 3rd party resource is a type of resource you can add co k8s | 23:42 |
| sdake | right | 23:42 |
| inc0 | like pod or whatever | 23:42 |
| sdake | and its purpose is to control an operator | 23:42 |
| inc0 | I'm reusing k8s resources | 23:42 |
| sdake | how do you control them? | 23:42 |
| sdake | how do you update them? | 23:42 |
| inc0 | operator is a pod.. | 23:42 |
| sdake | right | 23:42 |
| sdake | with an associated... | 23:42 |
| sdake | wait for it... | 23:43 |
| sdake | third party rsource | 23:43 |
| inc0 | or any other mean to control it... | 23:43 |
| inc0 | like idk...configmap? | 23:43 |
| * srwilkers sits down with popcorn | 23:43 | |
| inc0 | I'm not solving API problem yet | 23:43 |
| sdake | the design is well understood | 23:43 |
| inc0 | wanna control it with resource, sure, whatever | 23:43 |
| inc0 | it's a pod with code | 23:43 |
| sdake | with api problem solved | 23:43 |
| sdake | well i'll be interested to see what you turn out :) | 23:44 |
| *** v1k0d3n has joined #openstack-kolla | 23:45 | |
| rhallisey | srwilkers, good idea. | 23:45 |
| v1k0d3n | hey all | 23:46 |
| v1k0d3n | i hear it's a busy day. | 23:46 |
| v1k0d3n | :D | 23:46 |
| sdake | inc0 since you weren't aware of the third party resource link to operators, i'm curious, why are you calling it an operator? | 23:47 |
| rhallisey | inc0, I think we should stick to the plan | 23:48 |
| inc0 | operator is a code in a pod | 23:48 |
| inc0 | that's what operator is | 23:48 |
| rhallisey | or consider arguing a new one | 23:48 |
| sdake | ok, would you be willing to read one blog post then? | 23:48 |
| inc0 | only if you give me a link | 23:49 |
| sdake | working on it | 23:49 |
| rhallisey | inc0, I mean that's part of what an op is | 23:49 |
| inc0 | guys, API of controlling this thing is still tbd | 23:49 |
| inc0 | can be a resource, whatever | 23:49 |
| inc0 | doesn't need any real API for deployment procedure | 23:50 |
| sdake | https://coreos.com/blog/introducing-operators.html | 23:50 |
| sdake | there is a step by step in there of how to create an operator | 23:50 |
| sdake | see step #2. | 23:50 |
| *** ayoung has joined #openstack-kolla | 23:51 | |
| sdake | inc0 let me know when you see step #2 plz | 23:53 |
| inc0 | ok...I can create third party resource called openstack | 23:53 |
| inc0 | I've read it | 23:54 |
| sdake | 1mb limit, which you would know if you read the scrollback ;) | 23:54 |
| sdake | so openstack isn't granular enough | 23:54 |
| inc0 | I just consider third party resource as a detail | 23:54 |
| sdake | its how input is fed into the operator | 23:54 |
| sdake | and the operator is controlled | 23:54 |
| sdake | the operator doesn't pull data from magic places | 23:54 |
| sdake | it needs to be fed to grow ;) | 23:54 |
| sdake | if you consider input and control detials, i'm not sure how you consider workflow not a detail? | 23:55 |
| inc0 | that's API which is....implementional detail | 23:56 |
| inc0 | but I'll humor you, yes my idea can be controlled with it | 23:56 |
| sdake | inc0 we have a full spec of this stuff - join in there - thats where we need you the most | 23:56 |
| sdake | inc0 have you read the spec? | 23:58 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!