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