15:00:21 <mattmceuen> #startmeeting openstack-helm 15:00:22 <openstack> Meeting started Tue Aug 7 15:00:21 2018 UTC and is due to finish in 60 minutes. The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:25 <mattmceuen> GM all! 15:00:26 <openstack> The meeting name has been set to 'openstack_helm' 15:00:30 <mattmceuen> #topic Rollcall 15:00:33 <srwilkers> Good morning 15:00:40 <srwilkers> o/ 15:00:40 <mattmceuen> o/ srwilkers 15:00:47 <tdoc> hi 15:00:51 <mattmceuen> here's our agenda today https://etherpad.openstack.org/p/openstack-helm-meeting-2018-08-07 15:01:03 <mattmceuen> please go ahead and add anything you'd like to discuss 15:02:37 <mattmceuen> we have a light agenda today folks 15:03:49 <mattmceuen> #topic Dashboard / Horizon charts are not included in default OSH scripts / Armada manifests 15:04:13 <mattmceuen> From tdoc: Question, is there a specific reason that the dashboard/horizon charts are not included in default OSH and/or Armada scripts/manifests? 15:04:23 <tdoc> asking on behalf of a collegue who's been playing with that... 15:04:37 <tdoc> we were just wondering why 15:04:57 <srwilkers> I thought we had scripts for horizon in th deployment scripts? Or am I imagining that? 15:05:05 <mattmceuen> You know, we have a script for horizon 15:05:16 <mattmceuen> But I don't see it linked into any of our deployment folders :) 15:05:38 <mattmceuen> never mind - I am incorrect and bad at grep 15:05:59 <mattmceuen> it's in the DEV deployment scripts, but not in the multinode scripts 15:06:01 <tdoc> yeah, so I guess that's why he was wondering, I haven't actually had a chance to look myself 15:06:03 <lamt> I don't think it is run in all the jobs at the moment 15:07:12 <lamt> a change I recently was fiddling with that should break horizon seems to only break 2-3 jobs. 15:07:49 <mattmceuen> lamt you're saying that only those 2-3 jobs are running horizon, right? 15:08:14 <lamt> mattmceuen: yes 15:08:57 <alanmeadows> o/ 15:08:58 <mattmceuen> tdoc to your question - I'm not aware of any reason horizon isn't deployed, except that it's an "optional" component 15:09:02 <mattmceuen> o/ alanmeadows 15:09:10 <mattmceuen> but it's certainly something that needs to be present in our gates 15:09:21 <mattmceuen> (not necessarily all of them perhaps) 15:09:30 <tdoc> ok so, would it be fair to say horizon didn't receive too much testing so far? 15:09:40 <mattmceuen> #action lamt & mattmceuen to look into horizon gate situation 15:10:27 <srwilkers> I wouldn’t say that much, as the only way to test it is to verify the chart deploys correctly. That should be accomplished in the few jobs that deploy it 15:10:32 <portdirect> tdoc: we could certainly be ifit from getting selinium or similar in the gate 15:11:06 <mattmceuen> ++ 15:11:11 <srwilkers> Yeah. Without something like selenium, there’s not much testing we could do for horizon 15:11:19 <tdoc> ok, I think that's enough of an answer to that question... thanks 15:11:22 <mattmceuen> Does horizon have selenium testing defined already? 15:11:56 <mattmceuen> Said differently, what's horizon's native testing method? 15:12:07 <tdoc> not sure tbh 15:12:20 <mattmceuen> no worries 15:12:33 <srwilkers> Surely there must be something somewhere 15:12:41 <mattmceuen> moral of the story is, let's leverage the tests that are out there 15:13:10 <mattmceuen> lamt let's include that in our action item to figure out horizon testing prior art 15:13:12 <srwilkers> This would be a great springboard for a new contributor 15:13:43 <alanmeadows> Would be great if they were part of `helm test horizon` natively 15:13:54 <alanmeadows> for value to both the gate and operators evaluating installs 15:13:55 <mattmceuen> Agree 15:14:07 <mattmceuen> to both of the above ^ 15:14:28 <mattmceuen> #action lamt and mattmceuen to write a storyboard story based on horizon testing findings 15:14:49 <srwilkers> But 15:15:23 * mattmceuen breathless anticipation 15:15:24 <srwilkers> we've got other dashboards that could benefit from some sort of selenium testing as well 15:15:32 <mattmceuen> good point 15:15:34 <srwilkers> kibana / grafana come to mind 15:15:48 <mattmceuen> and tdoc were you wondering about them as well? You'd mentioned "dashboards" 15:16:38 <tdoc> no, sometimes people refer to Horizon as dashboard, that's all 15:16:47 <mattmceuen> ok cool 15:17:19 <mattmceuen> kibana / grafana testing would be a great next step srwilkers. We should look into their native testing as well. 15:17:56 <mattmceuen> I learned a new trick from b-str -- moving on in 30s unless there's anything else on this topic 15:18:41 <mattmceuen> #topic Airskiff 15:19:21 <mattmceuen> This is just an FYI / interest item -- for anyone who has wanted to get their feet wet with airship, I put together a project that integrates several airship components in a lightweight way 15:19:23 <mattmceuen> https://github.com/mattmceuen/airskiff 15:19:45 <mattmceuen> I thought I'd mention it here since I purloined the OSH gate scripts wholecloth to make it :) 15:20:12 <mattmceuen> If anyone plays with it and has any feedback, I'd appreciate it 15:20:15 <mattmceuen> that is all 15:20:33 <mattmceuen> #topic PTG agenda etherpad 15:20:42 <mattmceuen> srwilkers: ITS ALIVE 15:20:48 <mattmceuen> https://etherpad.openstack.org/p/openstack-helm-ptg-stein 15:20:54 <mattmceuen> ... but it is bare 15:21:13 <mattmceuen> Let's please add all topics we'd like to discuss in the PTG to this etherpad 15:21:42 <srwilkers> mattmceuen: awesome. yeah, it'd be nice to get some initial topics rolling so we've got something to guide us along when we're all hungover (or just me) 15:22:01 <mattmceuen> For anyone unable to attend the PTG in person, but who would like to join remotely -- if you add a note to any topics along the lines of "please open a phone bridge" I'll do that 15:22:25 <mattmceuen> +1 srwilkers 15:22:33 <srwilkers> mattmceuen portdirect: maybe we can follow other projects' leads and send out the link via the mailing list as well, so we can capture input from those not present here 15:22:42 <mattmceuen> I will do this 15:22:48 <srwilkers> mattmceuen: awesome :) 15:23:00 <mattmceuen> The etherpad is 15 mins old ;-) 15:23:23 <mattmceuen> It will grow wings and fly out on the ML straightaway 15:23:51 <srwilkers> :D 15:24:02 <mattmceuen> #topic PS Needing Review 15:24:21 <mattmceuen> Is there anything out there starving for reviews? 15:24:33 <srwilkers> yeah actually, one second 15:24:37 <srwilkers> ive got a large list 15:24:54 <mattmceuen> excellent 15:25:16 <srwilkers> https://review.openstack.org/#/c/543553/26 -- add basic auth to Prometheus, along with restricted paths (-1 wf pending discussion, if any) 15:25:39 <srwilkers> https://review.openstack.org/#/c/543958/ -- verification said auth functions in the armada manifest in osh 15:26:06 <srwilkers> these next four are all related 15:26:27 <srwilkers> https://review.openstack.org/#/c/588066/ - HTK snippets, manifests, scripts for creating s3 users and buckets with rgw's s3 api 15:27:02 <srwilkers> https://review.openstack.org/#/c/588352/ - ceph client creating s3 admin user with admin secret and access keys 15:27:26 <srwilkers> https://review.openstack.org/#/c/559417/ - Elasticsearch s3 snapshot repository using the above 15:28:01 <srwilkers> https://review.openstack.org/#/c/572201/ - Elasticsearch s3 repository being deployed via armada manifest in osh using the above 3 changes 15:28:39 <srwilkers> and finally 15:28:44 <srwilkers> https://review.openstack.org/#/c/587621/2 - some general rally chart cleanup 15:28:48 <mattmceuen> Awesome - I added to the agenda for folks not present 15:28:49 <srwilkers> that's it for me 15:29:32 <srwilkers> i know the Elasticsearch one is a big change. if there's appetite for it, i'll throw together a quick spec so we can lay out the design and expectations for leveraging the rgw s3 api 15:29:39 <srwilkers> im sure portdirect would be happy with that 15:29:45 <mattmceuen> This one could use some more review too: 15:29:45 <mattmceuen> https://review.openstack.org/#/c/582620/ -- spec for readiness and liveness probes 15:30:30 <srwilkers> that ones coming along 15:30:47 <srwilkers> it'd be nice to get some sort of consensus on what we want to do with that though 15:31:18 <mattmceuen> We have time now, would you like to discuss now? Or offline as reviews? 15:31:20 <srwilkers> in my mind, it makes sense to handle it like we do the resources (purely via yaml), but i'm one person 15:31:36 <srwilkers> we can start now if alanmeadows, portdirect and lamt are able to weigh in as well 15:31:41 <srwilkers> else we should do it offline 15:31:46 <mattmceuen> Let's do it now 15:32:20 <mattmceuen> #topic Elasticsearch s3 snapshot approach 15:32:40 <srwilkers> oh, i was talking about the readiness/liveness probes :D 15:32:44 <mattmceuen> sigh 15:32:57 <lamt> lol 15:33:09 <mattmceuen> I was wondering what the s3 api stuff had to do with the resources yaml 15:33:18 <mattmceuen> #topic Liveness and Readiness Probes 15:33:19 <lamt> I am okay with it being inline with how we handle resources 15:34:10 <mattmceuen> I'll be honest, I haven't gone over the spec in detail yet 15:34:15 <lamt> Is Jaesuk around? I believe he mentioned he wants to be part of this discussion as well. 15:34:37 <lamt> based on a comment he placed in one of my patchset on the topic of probes 15:34:41 <mattmceuen> He couldn't make it today - I'll make sure he knows we discussed so he can catch up on the log 15:34:43 <alanmeadows> my pretty simple comments on the readiness probe spec were do we want to get in the business of maintaining yet-more interfaces 15:35:33 <alanmeadows> I'm starting to be more and more inclined to allow them to just jam in raw k8s yaml as it means we stay lean and simple - that way k8s is the standard, not us 15:36:16 <srwilkers> alanmeadows: yeah, that's my line of thinking too 15:36:47 <alanmeadows> don't get me wrong its a great spec 15:37:27 <srwilkers> BYOP -- bring your own probes 15:37:49 <mattmceuen> Are liveness probes not things that are inherently linked to each chart? 15:37:53 <alanmeadows> I'm not against defining the probes, because that makes sense as the OSH value add 15:37:57 <mattmceuen> I.e., do you see them being that operator-specific? 15:38:04 <alanmeadows> its the mechanism to deliver them 15:38:17 <alanmeadows> this proposes as tlam says, something akin to how to allow you to limit resources 15:38:22 <srwilkers> yep 15:38:32 <alanmeadows> an interface we construct and maintain and provide defaults for 15:38:48 <mattmceuen> Gotcha 15:39:48 <mattmceuen> Alright - moving on from the probe topic in 30s unless any additional thoughts 15:39:49 <rwellum> o/ 15:39:54 <mattmceuen> o/ rwellum! 15:40:18 <alanmeadows> so the question is do we do this or do we we focus the energy on a way to deliver arbitrary yaml to any part of any deploy/ds/ss manifest and swing things like resource limitations, probes, and everything else over to that where we provide defaults that bring the OSH value add 15:41:58 <alanmeadows> just my thoughts when I reviewed that spec :) 15:42:20 <mattmceuen> I don't think your thoughts made it into the spec, alanmeadows - did you hit save? :) 15:42:30 <alanmeadows> well you said no vs offline :) 15:42:33 <alanmeadows> now 15:42:41 <alanmeadows> I will make sure they do 15:43:02 <mattmceuen> lol, was not intentionally trolling - only unintentionally trolling. thanks. 15:43:06 <srwilkers> im more keen to just throw the yaml snippets in, and providing defaults. the reason i like just doing yaml (akin to resources), is that it means someone can shift between probe types easily. want tcp socket probes? define the yaml. want a command probe? define the command in the yaml, without needing to mount it in via the configmap 15:43:25 <srwilkers> done and done 15:43:35 <alanmeadows> the big benefit i'm shooting for is we don't define an interface that is 95% like k8s 15:43:45 <alanmeadows> its 100% k8s, and if k8s changes, the charts go along for the ride for free 15:43:50 <srwilkers> yep 15:44:04 <alanmeadows> new probe types? cool, no osh changes. 15:44:58 <mattmceuen> would there be any part to this that would be probe-specific, or pure "jam in whatever you want"? 15:45:26 <alanmeadows> it is currently spec-less 15:45:44 <alanmeadows> it needs more thought 15:45:48 <alanmeadows> but it would not be probe specific 15:46:12 <alanmeadows> it would be a way to do this for all things 15:47:48 <mattmceuen> Sounds like a PTG topic :) 15:48:18 <alanmeadows> in fact, and I now may be stealing @portdirect's thunder but he's not chiming in--it was potentially going to be paired with the idea of simplifying HTK 15:48:43 <alanmeadows> a simpler way to ask for basic building blocks for OSH - instead of 900 micro macros to consturct a daemonset 15:49:03 <alanmeadows> give me a daemonset, merge this yaml here for this, this yaml here for that, render, beer 15:49:16 <alanmeadows> give me a deployment set, this yaml here, there, so on 15:49:17 <srwilkers> beer being key 15:49:27 <mattmceuen> I've looked over portdirect's shoulder and have seen some nifty yaml overridabilities 15:49:35 <mattmceuen> still waiting for the beer 15:49:42 <alanmeadows> the beer is the last step 15:49:49 <alanmeadows> but yes, a PTG topic 15:50:05 <alanmeadows> I expect @portdirect will surely have a working prototype that will delight all 15:50:18 <mattmceuen> I'll plan to be sitting down 15:50:32 <mattmceuen> #topic Roundtable 15:50:44 <mattmceuen> we have 10min left folks - anything else you'd like to chat about? 15:52:30 <mattmceuen> Alright - thanks everyone! Have a great week and see you in #openstack-helm 15:52:32 <mattmceuen> #endmeeting