15:00:24 <mattmceuen> #startmeeting openstack-helm
15:00:25 <openstack> Meeting started Tue Dec  5 15:00:24 2017 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:28 <openstack> The meeting name has been set to 'openstack_helm'
15:00:40 <mattmceuen> #topic rollcall
15:00:46 <mattmceuen> GM all!
15:00:50 <mattmceuen> Agenda: https://etherpad.openstack.org/p/openstack-helm-meeting-2017-12-05
15:01:29 <srwilkers> o/
15:02:15 <alanmeadows> o/
15:02:21 <portdirect> o/
15:03:05 <mattmceuen> Giving another min or so for agenda edits to complete
15:03:13 <MarkBaker> o/
15:03:24 <icolwell> o/
15:03:48 <srwilkers> a wild alanmeadows appears
15:03:57 <alanmeadows> straight from the bush
15:04:04 <mattmceuen> don't spook him!
15:04:11 <portdirect> I'm in transit, so may be less verbose than usual. (You can all sigh with relief now)
15:04:13 * srwilkers uses flash -- it's not very effective
15:04:19 <mattmceuen> #topic When to use a spec in OSH
15:04:39 <mattmceuen> Ok -- I thought it would be a good time to refresh our local practice of spec authoring
15:04:52 <mattmceuen> Both as FYI to new team members, as well as a refresher for the rest of us :)
15:05:27 <mattmceuen> At this point in the OSH lifetime, we don't expect specs for every code change
15:05:36 <mattmceuen> When we do expect specs are:
15:05:43 <v1k0d3n> o/
15:05:49 <mattmceuen> 1. when a change impacts multiple charts
15:06:09 <mattmceuen> 2. when a change needs design feedback from the larger team prior to implementation
15:06:24 <mattmceuen> 3. when a change does something substantially new that'll be modeled in other charts later
15:07:06 <mattmceuen> The gist being:  write specs as a means to drive common understanding (think: useful documentation) and common direction (think: everyone's aligned)
15:07:17 <mattmceuen> thoughts/questions?
15:07:37 <v1k0d3n> sounds good to me.
15:07:42 <v1k0d3n> good recap
15:07:57 <portdirect> Sounds good mattmceuen
15:08:11 <mattmceuen> cool beans.  thanks guys I'll get off the process soapbox.
15:08:17 <mattmceuen> Next:
15:08:27 <mattmceuen> #topic Carryover CICD topics from last week
15:08:49 <mattmceuen> Great focus-meeting on CICD last week -- we couldn't fit everything in :)  good problem to have.
15:09:09 <mattmceuen> portdirect:  want to speak to helm test and friends?
15:09:21 <v1k0d3n> was really sad to miss last week, but couldn't make it. was there some docs/notes (i'm assuming the same etherpad format)?
15:09:53 <mattmceuen> Yep!  notes and transcript: http://eavesdrop.openstack.org/meetings/openstack_helm/2017/
15:10:07 <v1k0d3n> awesome. thanks mattmceuen
15:10:21 <portdirect> So I'm thinking we need a spec for what we have in helm test
15:11:08 <mattmceuen> Sounds pretty cross-chart to me.  What do you want to get out of said spec?
15:11:27 <portdirect> As currently we have been pretty good with what I hope we decide as the core rationale for what we want from this functionality but as more contributors come in we should formalize a bit.
15:12:24 <portdirect> So from my perspective we should be able to run 'helm test' at any point in a charts life, without lasting impact on the environment
15:12:55 <portdirect> This means that by definition the tests should be non impacting, or destructive
15:12:55 <v1k0d3n> ++
15:13:18 <mattmceuen> agree.
15:13:33 <portdirect> Though we are limited by what helm currently provides us with
15:13:51 <v1k0d3n> are they impacting or destructive currently? we've just recently started testing with custom rally yaml.
15:14:02 <portdirect> I'd like to export developing a pattern for running a test on each node in the cluster
15:14:22 <portdirect> v1k0d3n: no, but this is not formalised at present
15:14:48 <v1k0d3n> ok. sounds good.
15:15:15 <mattmceuen> Can we document the pattern for testing openstack vs. non-openstack charts in that spec as well?
15:15:32 <portdirect> Is there also appetite for adding a 'really hammer this thing' flag? That would enable destructive testing?
15:16:20 <portdirect> mattmceuen: yes def the pattern we write up in the spec should be application agnostic
15:16:29 <srwilkers> portdirect: yep.  `helm test` is generally meant as a smoke test for verifying a chart just deploys something functional.  i've been toying around with the idea of having a chart for running helm tests against specific chart groups in openstack-helm-infra.  dont know if that makes sense the way i worded it, but without something like rally for services outside of openstack, it's been difficult verifying
15:16:29 <srwilkers> everythings working the way it should
15:17:04 <srwilkers> as using `helm test` the way i have been with those charts, it's really introducing dependencies on the other services when it really shouldnt if we're treating each chart as its own entity
15:18:15 <srwilkers> portdirect: i've got an appetite for such a flag
15:18:19 <portdirect> This needs to be encapsulated in the spec for sure, I'm assuming that you are r3fering to things like the mysql exporter?
15:18:29 <mattmceuen> that speaks more to my thought portdirect -- I agree the spec should be agnostic, but am thinking of advice like "if you're testing an OS service, you can use rally; otherwise, here are some guidelines"
15:18:41 <srwilkers> referring to fluentd/elasticsearch/prometheus and friends
15:19:40 <portdirect> srwilkers: yeah, and here I think we need to specify a 'minimum' set of infra that we have running, so we don't end up with a ceilometer type situation
15:19:46 <srwilkers> ++
15:20:02 <portdirect> Where tests were passing but nothing useful was being collected....
15:20:10 <srwilkers> yep
15:20:31 <mattmceuen> portdirect:  are you looking for a volunteer for the spec, or are you volunteering for it?
15:20:48 <srwilkers> sounds like he's volunteering, and i'd be happy to throw some input on it as well
15:20:59 <portdirect> I'm volunteering to do it, unless there is someone who really wants it.
15:21:26 <mattmceuen> Sounds good - thanks portdirect.  Excellent idea.
15:21:32 <srwilkers> i dont really want it, but willing to contribute/do it if there's nobody else
15:21:43 <mattmceuen> #action portdirect to work on a spec formalizing our `helm test` approach
15:21:54 <mattmceuen> next:  do we have lamt in the house?
15:22:29 <mattmceuen> We'll table his item till next time.
15:22:40 <mattmceuen> #topic  LMA updates
15:22:48 <mattmceuen> swilkers what's goin on!
15:23:07 <srwilkers> ONAP and coffee mostly :)
15:23:08 <srwilkers> but
15:23:47 <srwilkers> we got prometheus merged in (finally).  osh-infra currently has charts for:  prometheus, kube-state-metrics, node-exporter, and alertmanager
15:23:55 <mattmceuen> WOOO
15:24:11 <srwilkers> this gives us a solid base for monitoring the underlying infrastructure, along with rbac rules that match those in the kubernetes/charts/stable repo
15:24:35 <srwilkers> along with that (tied in to the previous topic), we now have support for executing helm tests on charts in osh-infra
15:24:47 <portdirect> Can we get these exporting logs in the gate as a priority, or did I miss that getting added?
15:24:51 <srwilkers> and prometheus currently passes some basic smoke tests, so huzzah
15:25:01 <jayahn> hi
15:25:06 <srwilkers> portdirect: that'll be fluent-loggings job
15:25:17 <srwilkers> im currently adding support for doing that as we speak
15:25:22 <srwilkers> expect a patchset in the next hour or so
15:25:43 <srwilkers> the idea is that we can use a deployed fluentbit instance to export logs from the pods running in the osh-infra gates
15:26:12 <srwilkers> and we can also use prometheus to export the metrics gathered during the gate run to give an idea of the services' performance in the gate jobs
15:26:19 <srwilkers> that will also be added today
15:27:02 <portdirect> Nice, we really need that and the supporting docs for how to use/ingest them asap
15:27:05 <srwilkers> also big shoutout to jayahn and sungil for the work they did on fluent-logging
15:27:09 <srwilkers> portdirect: yep
15:27:25 <srwilkers> just took a few tweaks to get it to the finish line, but im really happy with how its working right now
15:27:59 <jayahn> we found out that version matching between fluent-bit and fluentd is somewhat sensitive.
15:28:10 <srwilkers> jayahn: yeah, ive noticed the same
15:28:22 <jayahn> if we want more simple stuff, we can only run fluent-bit.
15:28:43 <jayahn> we have a plan to add that "selection" possible through fluent-logging chart.
15:28:54 <srwilkers> once the log and metrics exporting is done in the osh-infra gates, the next step is to get the prometheus chart running prometheus 2.0
15:29:46 <srwilkers> prometheus 2.0 makes me happy.  the rework to the underlying storage layer is really solid, and the overall resource consumption has been reduced significantly
15:29:56 <portdirect> W00t
15:30:19 <portdirect> Any loss of features that hit us, e.g. openstack exporter?
15:30:28 <portdirect> Or they all sweet?
15:30:35 <srwilkers> nope, they're all sweet
15:30:40 <portdirect> Nice
15:30:47 <mattmceuen> love backwards compatibility.
15:30:53 <jayahn> nice!
15:31:04 <srwilkers> im chatting with some of the prometheans wednesday here at kubecon, and going to ask them about the maturity of the openstack service discovery mechanisms they're adding to prometheus
15:31:21 <srwilkers> as that will actually reduce the necessity of some of the openstack-exporter's responsibility
15:32:18 <srwilkers> anyway, thats it for me
15:32:24 <mattmceuen> awesome - thanks srwilkers
15:32:44 <mattmceuen> #topic Review Needed
15:32:51 * jayahn portdirect really being less verbose?
15:33:11 <jayahn> need to rebase, i guess. but again for adding lbaas to neutron
15:33:12 * srwilkers thinks portdirect needs a built-in -vvv flag
15:33:22 <mattmceuen> add lbaas to nuetron: https://review.openstack.org/#/c/522162/
15:33:40 <jayahn> but it requires kolla neutron version 4.0.0 since 3.x does not have that
15:33:41 * portdirect fingers on fire, this phone is being worked..
15:34:02 <jayahn> will it be any problem for the current upstream?
15:34:14 <portdirect> jayahn: for current upstream yes
15:34:34 <portdirect> But we could turn it off by default, which I think would be ok?
15:34:40 <jayahn> sure
15:35:10 <portdirect> What is the status of lbaas in neutron currently?
15:35:22 <mattmceuen> Any other PS we need some extra eyes on, all?
15:35:36 <jayahn> not sure. we only used lbaas in neutron, not octavia
15:35:37 <portdirect> Is it being supported moving forward? Or is everyone all in on ocavia?
15:36:04 <jayahn> our use case is integrating with vendor appliance, such as a10, f5, etc
15:36:06 <portdirect> mattmceuen: I'd love some feedback on the dev guide I've been working on
15:36:13 <jayahn> so does not really need octativa
15:37:11 <portdirect> jayahn: roger, that kinda fits with what I'd seen, in that vendors are still using it
15:37:38 <jayahn> yeah. they have lbaas v2 support as long as I know.
15:37:53 <mattmceuen> updated dev guide: https://review.openstack.org/#/c/523173/
15:38:04 <jayahn> i only sereiously did integration work with a10 though.
15:39:17 <mattmceuen> #topic things to share
15:39:33 <mattmceuen> Hey jayahn you had an item here, go for it
15:39:55 <jayahn> https://github.com/sktelecom-oslab/taco-scripts  >> skt's version of osh aio installation
15:40:06 <portdirect> Nice
15:40:06 <mattmceuen> oh awesome
15:40:13 <jayahn> fully inspired by portdirect's scripts on sydney
15:40:50 <portdirect> It would be great to see if we could get elements of this merged into the dev docs ps above
15:40:54 <mattmceuen> will give that a spin, jayahn!
15:41:16 <jayahn> thanks. :) btw, this is ocata. :)
15:41:26 <portdirect> Having examples of deploying with kubespray and co is awesome
15:41:44 * srwilkers has a sudden urge to find tacos
15:41:50 * mattmceuen I know right
15:42:01 * jayahn luck you srwilkers. you are in austin
15:42:06 <mattmceuen> Jay, you keep the floor:
15:42:18 <mattmceuen> #topic destructive testing tool comparison
15:42:31 * portdirect is about to leave new Orleans:D
15:42:35 <jayahn> as requested, we did a quick comparison
15:42:56 * mattmceuen full disclosure:  I just got distracted and will have to catch up on these deets from the chat logs
15:43:47 <jayahn> cookiemonster has more flexibility comparng to other tools. can define more types to kill, have REST API call to start and stop
15:44:04 <jayahn> but, all of three are doing similar things.
15:44:50 <jayahn> we will add more documentations and use cases.
15:45:25 <jayahn> happy to get any questions on how we use this cookiemonster in our ci, and for some demo
15:45:52 <mattmceuen> Also - there are some good details jayahn added as comparision in the agenda (bottom): https://etherpad.openstack.org/p/openstack-helm-meeting-2017-12-05
15:46:31 <jayahn> that is all from me
15:46:34 <mattmceuen> any questions on the comparison at this point?
15:47:14 <mattmceuen> Thanks jayahn - :)  eeiden is out at the OPNFV conference digging to get their thoughts on destructive testing too
15:47:29 <portdirect> Can we drive it from so.thong other than the api?
15:47:38 <portdirect> Lol something
15:48:31 <jayahn> so.thong.. it exactly sounded like bull poo. (in korean word)
15:48:43 <v1k0d3n> lol
15:49:13 <jayahn> portdirect: could you explain a bit more?
15:49:17 <jayahn> something like?
15:49:38 <portdirect> A configmap/file
15:50:08 <jayahn> not at the current version. but open to any feature suggestion
15:50:21 <portdirect> Having an extra endpoint to manage, (auth etc) always makes me sad
15:50:24 <portdirect> But for dev this is great
15:51:00 <jayahn> i will note your question, and will talk to my developer
15:52:28 <mattmceuen> Thanks guys.
15:52:29 <jayahn> portdirect: could you tell me more about "It would be great to see if we could get elements of this merged into the dev docs ps above"
15:52:44 <jayahn> your comments on installation scripts.
15:53:24 <jayahn> we can add "how to" guide with tools we are using. but need to know what you exactly want to have.
15:54:00 <jayahn> ping me anytime. I will happy to listen and follow. :)
15:55:05 <mattmceuen> T-minus five
15:55:10 <mattmceuen> #topic roundtable
15:55:18 <mattmceuen> Any other topics for today?
15:56:14 <v1k0d3n> looking forward to seeing any folks who are doming to kubecon :)
15:56:21 <mattmceuen> same!
15:56:35 <mattmceuen> Alrighty -- thanks guys, see you in the chat room
15:56:39 <mattmceuen> #endmeeting