15:02:41 #startmeeting openstack-helm 15:02:42 Meeting started Tue Jan 22 15:02:41 2019 UTC and is due to finish in 60 minutes. The chair is portdirect. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:45 The meeting name has been set to 'openstack_helm' 15:02:51 lets give it a few mins for people to join 15:02:54 o/ GM 15:03:03 o/ 15:03:03 Agenda here: https://etherpad.openstack.org/p/openstack-helm-meeting-2019-01-22, add away :D 15:04:14 o/ 15:04:33 o/ 15:04:58 o/ 15:05:06 o/ 15:05:53 ok - lets kick off 15:06:06 #topic docs-repo 15:06:38 so theres been some great work tring to the the docs repo up and running - though im wondering if we are trying to run, before we walk 15:06:49 I have given this a -2 https://review.openstack.org/#/c/625853/5 15:07:03 though am prepared to be told thats not appropriate 15:07:47 i thought we would do this in a phased approach 1) bring over exisiting docs un altered, 2) restructure 15:07:57 though this attempts to do both in one pass 15:08:18 which makes it very hard (at least for me) to see whats changed etc 15:08:27 so more process than intent ;) 15:08:55 not sure if any of the people working on that are here, so i may just be shouting incoherently atm :D 15:09:04 +1 for splitting to two steps - that makes sense to me too 15:10:21 ok - lets move on unless anyone else has anything to add - seems bad to discuss to much without Jaesang Lee around - whos put a lot of effort into this 15:10:41 #topic Helm 3 15:10:56 so howell has been doing some poc work with helm 3 15:11:09 and doing cool things like deploying memcached with it 15:11:21 portdirect: mmm 15:11:28 howell: you able to give a update on where helm3 is? eg lua etc 15:11:46 Sure 15:12:08 last i checked, it's stil quite a ways down the road 15:12:16 on previous topic I believe it's easier to do the things right in the proper place first, then increase the amount of content to match the proper structure 15:12:30 but ok 15:12:51 the lua library API is still being developed, so lua hooks aren't working at all yet 15:12:58 https://github.com/helm/helm/issues/5084 15:13:46 o/ 15:13:51 further, there isn't much of a timeline on when things will start to be useable :/ 15:14:11 that's interesting howell - does that mean helm 3 is not usable at all now, or just usable in more simple use cases? 15:14:15 o/ jayahn! 15:14:39 it's usable. it is pretty limited though 15:15:21 howell: at this point is the same (or greater) sprig version supperted as helm2? 15:15:35 *supported 15:16:01 i beleive so, but i'd have to double check 15:16:38 i think that would be awesome - then once a alpha binary starts being published we could explore again 15:16:46 evrardjp: given the state of helm 3, sounds like doing this POC-style is the right way/ right place to do this, if it's not ready to introduce into OSH. Do you disagree? 15:16:55 though I think you are planning on getting much more involved upstream there? ;) 15:17:12 planning on it :) 15:18:10 mattmcemaI was talking about previous topic, I can't judge on that helm3 part. Did you really want to ping me there? :) 15:18:30 mattmceuen: * 15:18:45 i think we can circle back to that (docs) at the end of the meeting if jayahn is around? 15:18:53 portdirect: lgtm 15:19:02 i will be around 15:19:19 nice - all done on helm3 - aka the future of OSH 15:19:23 mattmceuen: helm-tng interests me though :) 15:19:34 Ah - I gotcha now evrardjp. Mis-parsed ya :) 15:20:03 so onwards to the next topic - this meeting should perhaps be renamed the howell show this week 15:20:11 :) 15:20:13 haha :) 15:20:19 #topic kubernetes-entrypoint - whats going on there? 15:20:37 so I've been making some updates to kubernetes-entrypoint 15:20:37 howell: i think you have been doing some k8s-entrypoint work recently? 15:20:56 Firstly, the tool now supports Custom Resource Dependencies. Custom Resource Depedendencies use arbitrary key and "desired" value pairs. 15:21:38 Secondly, I've added an option to print all unresolved dependendencies as machine-readable JSON. 15:21:58 ok - so lets peel that back a bit 15:22:07 CRD support, what and why? 15:22:09 howell: "the tool" is not easy to understand for people without context, but that's maybe because I am new to this project 15:22:14 right. getting ahead of myself 15:22:17 o/ 15:22:19 sorry im late 15:22:28 howell: i think evrardjp has a good point 15:22:42 we have been in osh so long - we forget the very basic concepts 15:22:51 lets start with what is k8s-entrypoint 15:22:58 and how do we use it today in osh 15:23:01 so kubernetes-entrypoint is used to wait on dependencies 15:23:39 that is, if a pod A is dependendent on pod B, kubernetes-entrypoint will prevent A from starting until B is finished 15:24:00 we use this concept to orchestrate everything in osh 15:24:16 driven by the dependences section and a helm toolkit function 15:24:31 lets take a simple service - eg keystone 15:24:52 https://github.com/openstack/openstack-helm/blob/master/keystone/values.yaml#L104-L114 15:24:53 yup I've seen it around, but I think the important part is that it's our own thing, and that we have to maintain things forward. If deployers need to be aware of changes,we need to notify those in meetings, which is what's happening here 15:25:04 correct? 15:25:10 evrardjp: its not our own thing 15:25:15 its intels 15:25:20 ok 15:25:37 it's been around awhile, we just take advantage of it and provide updates along the way 15:25:37 thanks for the clarification! 15:25:40 we, stackentes, and kolla-k8s all uses it as the foundation for openstack on k8s 15:25:50 up until recently, the tool has supported pods, services, daemonsets, and a handful of other kubernetes builtins 15:25:53 anyway back to the 101 15:26:13 in the link i put above, you see the deps for the keystone api service 15:26:45 it needs: a migrated db, and a lod of other things done - which we do via k8s jobs 15:27:12 and also some services to be up and ready - which are, suprise sprise, services in a k8s 15:27:14 world 15:27:35 the container runs as in init container in each osh pod 15:27:48 and waits for the jobs to be complete, and services to be up before exiting 15:27:56 thus orchestrating across the cluster 15:28:02 back to you howell 15:28:11 thanks for that :) 15:28:39 anyway, i've recently added support for CRDs 15:29:05 that is, "wait until some arbitrary key has some arbitrary value" 15:29:12 *of a crd 15:29:53 for those that may not know - what produces/works with crds in k8s? 15:30:00 * portdirect buzzword incomming 15:30:06 operators 15:30:34 so it will work with operators such as rook 15:30:35 :) 15:30:50 and anything else ;D 15:30:52 * mattmceuen imagines movie preview voice saying "operators" 15:30:55 one quick question in this regard: 15:31:04 howell: good job there 15:31:06 does this not overlap with Armada in some functionaly? 15:31:16 also: noob question 15:31:20 howell: that would be helpful! 15:31:28 it'll also work nicely with creatign DAGs with argo 15:31:35 thanks :) 15:31:56 and howell is planning to prototype that for openstack service management :D 15:32:01 howell: I will ask a lesson on argo in the #openstack-helm channel, I took enough time already. 15:32:15 so it will be pretty exciting to see that progess, and if it has legs 15:33:32 sorry to ask one more question there howell: What is the idea behind bringing that? I mean it's obviously a very positive change, but there is probably something you have on your mind that I cannot see on the roadmap 15:34:20 it's not on the roadmap, because we aren't sure if it's a good idea or not yet 15:34:50 ok, for the moment it's just opening possible doors 15:34:56 exactly 15:34:58 yes 15:35:12 should that change, I think it's worth mentioning in a meeting 15:35:22 oh - 100% it would be a big change 15:35:36 but also - untill we try it - have no idea if it will be any good 15:35:57 so very early days - and i think best to do these things fully in the open 15:36:20 agreed 15:36:24 so we can collectivly evaluate approaches 15:36:33 k8s is still young, and evolving fast 15:36:44 we are talking about trying argo? (just want to followup) 15:37:03 talkign about a very simple poc 15:37:13 i think 'pre-trying' at this stage 15:37:19 okay, :) 15:37:37 one thing that has come out of this though that we clearly need to do a better job on 15:37:38 #action anyone document k8s-entrypoint 15:38:28 i can work on documentation if needed 15:38:54 howell: i think you would be a great person to do that 15:39:10 alon with evrardjp, as he gets openstack requirements like very few people i know 15:39:20 *along 15:39:41 I am fine with helping on that side with you howell 15:39:54 georgk: not forgotten your question 15:40:11 portdirect: that´s fine, we can take it later 15:40:14 none of this really overlaps with armada 15:40:48 as they have two different objectives, k8s entrypoint deals with deps etc within a chart, while armada orchestrates charts themselves 15:41:35 its this loose coupling, that allows osh (and those that came before it) to both be very resilient and self contained at a service level 15:42:01 portdirect: ok, got it. Thanks 15:42:05 while armada allows the deployment and configuration of these serices to be tied together in a chohertent fasion 15:42:25 very good patterns 15:42:30 (and once you are there, the rabbit hole opens - deckhand alows the config to be managed etc...) 15:43:13 yeah. 15:43:19 howell: one last thing - you also added machine readable output to k8s entrypoint 15:43:51 yes. k8s-entrypoint currently has some human-readable logging output on stdout 15:44:00 the hope here is that tooling - eg lma will be able to tap into this and give faster/simpler insight into the state of the cluster 15:44:57 that's interesting 15:45:03 so operators can at a glance see why a service, such as say glance, is not working 15:45:48 i see what you did there 15:45:59 * portdirect is here all week 15:46:06 booo 15:46:12 ok to move on? 15:47:04 :q 15:47:16 #topic Reminder: Open Infra Summit talk submissions due 11:59 PT tomorrow! 15:47:29 ^^ 15:47:30 thanks mattmceuen for reminding us 15:47:35 yeah, thank for the reminder. 15:48:24 there should be forum sessions to organise after the call for summit presentations, right? 15:48:40 then ofc the ptg sessions 15:48:44 usually, i remember 15:48:46 yeah 15:48:53 6 days.. 15:48:54 evrardjp: yup 15:49:05 really happy to see the events back to back 15:49:12 me too 15:49:20 almost like the forum 15:49:26 though i better not say that out loud 15:49:35 hush hush 15:50:05 i'm planning on submitting a workshop with alanmeadows 15:50:33 first week of May.. really worst timing ever for Korean... 15:50:38 where we use some airship components along with osh to bring up and a small cloud 15:50:44 jayahn: how come? 15:51:03 I guess holidays? 15:51:15 first week of May involves labor day (holiday) and children's day (also holiday) 15:51:40 we have labor day too here. We can complain together there jayahn 15:51:41 usually k-12 gives short vacation for the children 15:51:49 jayahn: bring them 15:51:59 I will give you a beverage of your choice to forget it 15:52:08 lol 15:52:24 anyway - should we revisit docs for a bit? 15:52:27 i'm looking forward to the timing -- i thought about passing on flying out there and riding a motorcycle out there instead 15:52:32 and taking a few days to ride around the rockies 15:52:46 docs 15:52:52 #topic docs round 2 15:53:10 i thought restructuring was an important priority on doc-repo. 15:53:18 so - the original plan i thought was to work on struture, then bring content over from the existing repo,a nd the great stuff skt has done 15:53:30 and, somewhat agree on evrardjp 15:53:32 it looks like thigs have jumped right in 15:54:00 so this morning i proposed that if the desire is to get a large body of content in - this should be done as it 15:54:05 *as is 15:54:11 and then resutureing in a follow on ps 15:54:40 an alternative approach would be to have a ps laying out the struture, and then populating with content once we have that down 15:55:07 im just worried that as it stands today - theres too many parts moving at once to sanly review 15:55:11 *sanely 15:55:38 okay, that probably true. (theres too many parts moving at once to sanly review) 15:56:20 so - are you ok with getting a ps up to simply define the desired layout 15:56:29 so what I did when I refactored large chunks of content in the docs of a project, I pretty much did the structure with no document in it, then quickly add, topic by topic, in the right place 15:56:31 and once we have that - start filling it with content? 15:56:48 evrardjp: i think that approach makes most sense 15:56:57 okay, i do agree on that 15:57:13 having ps up to define the desired layout first 15:57:32 on top of that all your downstream content would be easily importable patch per patch... 15:57:46 jayahn: you want me to push that structure up? 15:58:23 evrardjp: yeap, that would be great :) 15:58:27 I'd rather let you do it:p 15:58:28 oh ok 15:58:35 I guess I am volunteer then 15:58:37 ah.. we can do it as well, 15:59:06 but i guess anyone available to do it can do it. 15:59:07 let's sync on the chan then 15:59:15 hey - about to run out of time 16:00:04 see you all in the channel 16:00:08 #endmeeting