15:00:52 <mattmceuen> #startmeeting openstack-helm
15:00:53 <openstack> Meeting started Tue Apr 24 15:00:52 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:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:55 <mattmceuen> #topic rollcall
15:00:57 <openstack> The meeting name has been set to 'openstack_helm'
15:01:11 <cristicalin> o/
15:01:28 <gagehugo> o/
15:01:35 <jawonchoo> o/
15:01:39 <mattmceuen> agenda: https://etherpad.openstack.org/p/openstack-helm-meeting-2018-04-24
15:01:46 <mattmceuen> PLease add anything you'd like to discuss
15:02:01 <lamt> o/
15:02:12 <srwilkers> o/
15:03:04 <rwellum> o/
15:03:39 <d|k> o/
15:04:44 <srwilkers> matt has lost internet connection
15:04:51 <srwilkers> he's coming back
15:04:59 <mattmceuen> great timing sorry guys :)
15:05:07 <mattmceuen> #topic Vancouver Summit
15:05:34 <mattmceuen> do we have @jayahn in the house?
15:06:14 <mattmceuen> Let's go out of order, this one was something he wanted to discuss
15:06:26 <mattmceuen> #topic 1.0 timeline
15:06:51 <mattmceuen> It would be really great if we could reach 1.0 readiness by the Vancouver summit :)
15:07:17 <mattmceuen> https://review.openstack.org/#/c/556325/ -- definition-in-progress of 1.0
15:07:40 <mattmceuen> It's not something we want to rush into tagging if we're not ready, but I think we should shoot for being ready
15:08:46 <mattmceuen> we'd discussed using storyboard as a way to coordinate this work
15:09:28 <mattmceuen> rwellum, do you have a feel yet for risk / work involved with migrating?
15:10:28 <mattmceuen> storyboard is another thing we don't want to rush, but if it's low hanging fruit and ready, then we could start creating work items stat
15:10:31 * srwilkers scurries off for coffee
15:11:18 <mattmceuen> All it takes is one mention of scope management tooling to make srwilkers run for the door
15:11:27 <rwellum> mattmceuen: spent a little time, but nothing conclusive yet. I have been watching Ironic  - which is the biggest project to use it so far.
15:11:54 <rwellum> I'm off traveling this week but I'll get something out by early next if that's ok?
15:12:06 <mattmceuen> Yup, that would be perfect
15:12:47 <mattmceuen> If we can get the spec merged by next week, and then start entering / assigning out work items (in launchpad or storyboard as appropriate) next week, that will set us up well I think
15:13:40 <mattmceuen> anything else on this topic
15:13:53 <rwellum> I thought the spec was really good btw
15:13:56 * srwilkers grumbles about people leaving empty coffee pots
15:14:05 <mattmceuen> Awesome, thanks rwellum
15:14:16 <mattmceuen> #topic Adding ldap integration to Elasticsearch, Kibana, Grafana, Prometheus
15:14:27 <mattmceuen> Channel your grumpiness into some LMA for us srwilkers
15:14:44 <srwilkers> so currently, elasticsearch, kibana and grafana are all just relying on basic auth
15:15:04 <srwilkers> which is fine for kicking the tires somewhat, but doesnt necessarily provide a meaningful solution beyond that
15:15:33 <srwilkers> i've been working on using the ldap chart in openstack-helm as a reference for providing authentication via ldap for those services
15:16:29 <srwilkers> it required a change in the elasticsearch and kibana charts since they're using an apache reverse proxy to front those containers.  the changed involved moving the host configuration into values to verify it works
15:16:48 <srwilkers> i plan on including docs on how to use it and the necessary configuration parameters to take into account when looking to use it
15:17:35 <srwilkers> i think doing it in this manner makes sense at the moment, as the values-driven model allows an operator to provide overrides to further restrict the access certain groups and users have to specific paths for those services
15:17:41 <srwilkers> but i'd also appreciate feedback on those
15:18:04 <mattmceuen> https://review.openstack.org/#/c/563270/ (grafana)
15:18:04 <mattmceuen> https://review.openstack.org/#/c/563260/ (kibana/apache)
15:18:04 <mattmceuen> https://review.openstack.org/#/c/543553/ (prometheus, basic auth first)
15:18:09 <srwilkers> grafana's got built in support for ldap, so its being handled differently.  it's just a matter of finding the appropriate binds and group mappings to use at this point i think
15:18:14 <srwilkers> its not quite there yet but close
15:18:57 <srwilkers> prometheus currently has no sort of auth mechanism, but ive got a patchset to add the same functionality the elasticsearch and kibana charts have
15:19:51 <mattmceuen> I know the ldap integration has been an interesting journey - any outstanding questions to pose while we have everyone's eyeballs here?
15:20:26 <srwilkers> that's all i really had on it for the moment.  ive been chewing on whether ldap integration for prometheus is required
15:21:07 <srwilkers> almost thinking it just needs to be locked up, as grafana can be used to display all the pretty dashboards to anyone authorized to view them
15:21:50 <srwilkers> that does restrict access to prometheus, but ive always been skeptical of giving free reign to the prometheus endpoint to an authenticated user
15:22:06 <mattmceuen> Agree
15:22:23 <srwilkers> but thats it for me
15:22:44 <mattmceuen> Locking up prometheus may be a good Plan A in any case, we can always expose it with some kind of auth tie-in later if use cases come up and someone does the work :)
15:22:59 <srwilkers> yeah, thats what im thinking
15:23:06 <mattmceuen> cool
15:23:16 <mattmceuen> Thanks srwilkers.
15:23:30 <mattmceuen> Next one is your topic as well
15:23:34 <mattmceuen> #topic Ceph radosgw s3 api for Elastic Curator
15:23:53 <srwilkers> this is one of those situations where you come to hate something you introduced in the past
15:24:23 <srwilkers> currently the elasticsearch chart supports creating a RWM backed PVC to use as a filesystem snapshot repository for ealstucsearch
15:24:51 <srwilkers> i thought it'd be great to have a default mechanism for using elastic curator to take snapshots of the indices and place them in a PVC
15:25:11 <srwilkers> problem is that requires some method for provisioning RWM volumes, which may not always be an option
15:25:42 <srwilkers> so to get around that, I've been working on using the s3 ceph radosgw api to provide the ability to use the s3 repository type for elasticsearch
15:26:10 <srwilkers> this brings us back in line to being able to use ceph to back our snapshot repositories, which i think is a good thing
15:26:32 <srwilkers> it's been a bit touchy along the way, but im very close to having this functional in the elasticsearch chart
15:26:45 <jayahn> o/
15:26:56 <mattmceuen> That's awesome and thanks for sharing this in progress
15:26:58 <mattmceuen> o/ jay!
15:27:18 <srwilkers> im also using this as a shameless plug for a blogpost, as there's not a single clear walkthrough i could find with my googlefu
15:27:46 <srwilkers> so i plan on sharing what i did for anyone else looking to use the s3 rgw api in the future
15:28:18 <srwilkers> thats all i had really
15:28:23 <mattmceuen> So the reason s3 radosgw > cephfs-PVC approach is because older kernels don't support cephfs, right?  Will radosgw also be better performance?
15:28:58 <srwilkers> well, thats part of it.  the alternative would be to use something like NFS, but not everyone wants to use NFS either
15:29:21 <portdirect> Object storage > filesystem here
15:30:03 <srwilkers> yep.  performance-wise, should be roughly the same as the bulk of the work is Elasticsearch performing the snapshots of the indices i think
15:30:32 <mattmceuen> cool beans
15:30:33 <srwilkers> at the end, it just  dumps the compressed snapshot wherever youve pointed it at
15:30:39 <mattmceuen> gotcha
15:31:02 <mattmceuen> jayahn you are up!
15:31:07 <jayahn> i am
15:31:08 <mattmceuen> #topic Vancouver Summit Talks
15:31:10 * srwilkers coffee scurry 2.0
15:31:23 <jayahn> sorry, i fall asleep....
15:31:32 <mattmceuen> no problemo at all
15:31:38 <mattmceuen> https://etherpad.openstack.org/p/openstack-helm-meeting-2018-04-24
15:31:48 <mattmceuen> I can start :)
15:32:17 <mattmceuen> For the talk I have w/ you and Seungkyu - I have a draft ppt to share with you, will get it in your inbox for tomorrow morning
15:32:21 <jayahn> vancouver summit
15:32:30 <jayahn> great!
15:32:54 <mattmceuen> It's a lightning talk, I probably already have too many slides :D  let's drink lots of coffee first
15:33:10 <jayahn> :)
15:33:11 <mattmceuen> Ok -- workshop talk, want to share your thoughts?
15:33:18 <jayahn> yeah 10 min talk
15:33:31 <jayahn> hands-on workshop
15:34:28 <jayahn> certainly we need more people assisting workshop, and I would like to have one of "native" english speaker to lead "presentation" part of workshop.
15:34:58 * jayahn try to decide if pete is native or its own kind. :)
15:35:49 <jayahn> for actual hands-on demo,
15:36:18 <jayahn> openstack-helm deployment + lma deployment would be basic step to do.
15:36:48 <jayahn> I would like to ask if we need to do version update as a part of hands-on.
15:37:15 <mattmceuen> I think version update would be pretty powerful
15:37:31 <jayahn> then, we need to decide from which to which
15:37:48 <mattmceuen> Thinking back to what we did last time vs what we could do this time - would be great to get some snazzy new things in there so we're not repeating ourselves
15:37:55 <mattmceuen> LMA is a great add in that regard
15:38:08 <mattmceuen> How about newton->ocata?
15:38:25 <jayahn> but, newton is pretty old one.
15:38:28 <mattmceuen> (LMA: let's actually have them log into grafana)
15:39:49 <mattmceuen> There are two arguments to made for versions -- 1) newton->ocata is really good because that's what we'll be gating for 1.0.  2) ocata->(newer) would be a good preview of the fact that OSH works well with newer versions, even thought the gates haven't caught up yet
15:40:20 <jayahn> yeap.
15:40:23 <jayahn> exactly
15:40:35 <mattmceuen> The version that we upgrade to should be something we're pretty comfortable with I think
15:40:42 <jayahn> 1) vs 2) what you guys think?
15:40:45 <mattmceuen> Because folks will take the scripts home and use them for standing things up
15:41:37 <srwilkers> I’m comfortable with 1. That’s my take though
15:42:25 <rwellum> I agree stick to the 1.0 deliverable.
15:42:54 <jayahn> okay.
15:43:26 <mattmceuen> I think #1 is good, along with a spoken note that we are targeting Newton & Ocata for 1.0, and that our next order of business post-1.0 will be to gate newer versions of OpenStack (which largely already work with OSH)
15:43:42 <mattmceuen> One more reason to have 1.0 ready by Vancouver if possible :)
15:44:30 <mattmceuen> Pete is multitasking right now, but Im sure he'll be good with speaking based on conversations I've had with him
15:44:44 <jayahn> then, we probably need to describe very well about openstack-helm chart being independent from openstack versions. we can surely support newer versions of openstack.
15:45:09 <mattmceuen> Good idea.  a brief sugar cube diagram :)
15:45:41 <jayahn> i really don't want to give a negative feeling about openstack-helm being only capable of deploying old openstack.
15:45:55 <jayahn> sugar cube diagram!
15:45:57 <jayahn> love it.
15:46:01 <rwellum> +1
15:46:33 <mattmceuen> Would it be possible to get overrides created for newer versions, and ideally experimental gates for them too, by then?
15:47:30 <jayahn> i think it is matter of minute to add experimental gates for ocata, probably for much newer ones.
15:48:21 <jayahn> personally, i think ocata to pike is very doable. :)
15:48:52 <mattmceuen> That's excellent, and agree 100% on Pike doability.  With gates in place I'd feel much more comfortable promoting Ocata->Pike.
15:48:56 <jayahn> but, also agrees on reason to pick #1
15:49:11 <mattmceuen> well #1 can be fallback in any case
15:49:19 <jayahn> sure thing. :)
15:49:21 <mattmceuen> Should just be a matter of switching the overrides file
15:49:54 <mattmceuen> Do we have a solution planned for the VMs for the workshop?
15:49:59 <jayahn> yeap
15:50:05 <rwellum> I almost feel you guys should consider skipping a release - jump straight to Queens. I mean you're not 1.0 yet - so can assume that customers coming onboard post 1.0 will want the latest?
15:50:14 <mattmceuen> woooot jayahn
15:50:24 <jayahn> that is very good and serious question
15:50:36 <mattmceuen> post-1.0 will definitely want the latest
15:50:39 <jayahn> nope. my "yeap" is a bit late typing answer
15:50:44 <jayahn> not to your VM question
15:51:24 <portdirect> we need to get them sorted asap
15:51:38 <portdirect> as without this the workshop is dead in the water.
15:51:59 <jayahn> i know.
15:52:35 <jayahn> I will try to find "VM donors" more, but
15:52:46 <jayahn> do you guys have any potential sponsor?
15:52:51 <rwellum> Sometime OS infra provides resources?
15:53:13 <srwilkers> rwellum: i'd like to see something like the version used in the user survey.  i wouldnt necessarily assume everyones wanting to use latest
15:54:08 <mattmceuen> We don't have any approval for funding the VMs or other sponsors identified, do you have any ideas for sponsors?
15:54:38 <mattmceuen> srwilkers developers want to be running the latest on their laptops, that much is true :)
15:55:02 <mattmceuen> But good point - from a prod perspective definitely not, and that's why the 1.0 / post-1.0 distinction is important
15:55:14 <rwellum> srwilkers: agreed. But other projects are caught up (kolla-ansible) etc - and my company are on queens right now - so to pitch them osh I personally need the latest. But I know that's just one voice.
15:55:19 <srwilkers> mattmceuen: nothing wrong with that, we'll get there.  just cant see those wanting to use this in a prod like environment wanting to use latest
15:55:19 <jayahn> skt currently does not have a good public cloud service. most of things are internal usage only. getting VMs with public internal access is damn hard.
15:56:08 <portdirect> we also need a decent level of iops
15:56:27 <jayahn> is it possible to show "some company's logo" on our hands-on demo slide?
15:56:47 <jayahn> If that company provides VMs?
15:56:51 <rwellum> Quick change to Horizon is easy
15:56:58 <portdirect> last we need a min spec of: 30gb Ram, 4vCPU, 80Gb GP2 SSD
15:57:00 <rwellum> jayahn: ^^^
15:57:14 <portdirect> before we discuss branding - and of course we can
15:57:23 <portdirect> lets get the hw issue resolved
15:57:35 <jayahn> i am trying to get my weapon to get VM sponsors :)
15:58:03 <portdirect> it was approx $600 for AWS last time
15:58:09 <mattmceuen> at the last summit, we used a public cloud provider behind the scenes, and the only branding was AT&T & SKT as far as I remember :)
15:58:23 * mattmceuen super secret public cloud provider there
15:58:25 <rwellum> Sorry - just want to repeat - in previous workshops I think OpenStack Infra has provided some resources? Maybe just imagining this.
15:59:01 <mattmceuen> I didn't realize that rwellum
15:59:08 <portdirect> OVH has typically in the past
15:59:18 <mattmceuen> yikes, lost track of time
15:59:21 <jayahn> 1 min left for the meeing
15:59:23 <mattmceuen> t-minus one minute
15:59:29 <portdirect> though i think we may have missed the window there? though worth checkinh
15:59:37 <mattmceuen> Going to have to table - feel free to continue discussin in the chat room!
15:59:46 <rwellum> Any chance on getting a +W for: https://review.openstack.org/#/c/562097/ ? :)
15:59:50 <mattmceuen> #endmeeting