15:02:21 <portdirect> #startmeeting openstack-helm
15:02:22 <openstack> Meeting started Tue Oct 16 15:02:21 2018 UTC and is due to finish in 60 minutes.  The chair is portdirect. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:26 <openstack> The meeting name has been set to 'openstack_helm'
15:02:30 <portdirect> sorry I'm late o/
15:02:34 <portdirect> #topic rollcall
15:02:39 <lamt> \o
15:03:01 <srwilkers> o/
15:03:10 <jaesang> o/
15:03:18 <portdirect> also - heres the agenda https://etherpad.openstack.org/p/openstack-helm-meeting-2018-10-16
15:03:33 <mattmceuen> no worries portdirect o/ \o (<- high five?)
15:04:19 <portdirect> shall we begin?
15:04:23 <portdirect> #topic Armada job in openstack-helm
15:04:31 <portdirect> srwilkers: the floor is yours :D
15:04:41 <srwilkers> morning!
15:05:06 <srwilkers> so the past few weeks have been a mix of triaging jobs that have failed for one reason or another, and also trying to find ways to improve them a bit
15:05:19 <srwilkers> i had a few points of discussion wrt the armada job
15:05:45 <srwilkers> now that we've moved to deploy ocata by default instead of newton, it makes sense to go ahead and get the armada job updated to reflect this change
15:05:57 <srwilkers> the change to do so is here: https://review.openstack.org/#/c/591808/
15:06:42 <srwilkers> semi related to this
15:07:31 <srwilkers> the armada manifest has the overrides required to enable the fluentd handlers and formatters for logging for each openstack service, as this was put together when we still supported newton as the default
15:07:57 <srwilkers> but now that's changed, do we want to consider enabling these handlers and formatters by default, which removes the need to override them in the armada manifest/
15:08:00 <roman_g> o/
15:09:45 <mattmceuen> sounds good to me naively - there's no real risk of breaking any dependencies on the old behavior, right?
15:09:57 <portdirect> yeah this is my concern
15:10:48 <portdirect> would this not mean, always trying to push logs to fluent, even it does not exist?
15:10:57 <srwilkers> i'd prefer to keep things as is honestly, but wanted to bring it up now that we deploy a version that supports fluentd by default
15:11:10 <portdirect> roger
15:11:32 <portdirect> also with the work lamt did - are we not now deploying ocata in the armada check anyway?
15:12:04 <portdirect> oh - sorry i saw your updated ps, ignore me
15:12:11 <lamt> it should - (with a minor exception of ceilometer if that's being used)
15:12:16 <srwilkers> :)
15:12:46 <srwilkers> yeah, should probably update the commit message to reflect what's really happening now
15:12:52 <portdirect> ++ ;)
15:14:37 <srwilkers> and i think ive talked myself out of my last point wrt armada, so i think im done here
15:14:54 <portdirect> does that also cover Logging configuration ?
15:15:07 <srwilkers> yeah
15:15:13 <portdirect> #topic New repos
15:15:42 <portdirect> 1st i must applogise for not having got the docs repo up - I dropped the ball here
15:15:56 <portdirect> and will pick it back up today, and get the repo done
15:15:59 <jayahn> sorry to miss the previous meetings (two), pls let us know what you need.
15:16:14 <portdirect> jayahn: at this point the action items are mine :(
15:16:28 <portdirect> soon as its up - we'll need ps's and reviews
15:16:31 <portdirect> :)
15:16:41 <portdirect> another thing came up
15:16:51 <portdirect> we have sveral images that are being built for osh
15:16:55 <jayahn> okay. jaesang is also here today, the one who will do ps's reviews.. :)
15:17:01 <portdirect> and i was going to start working on building these in the gate
15:17:15 <portdirect> but evrardjp suggested a new repo to house these images
15:17:29 <portdirect> I think that would be great - as it would clearly seperate concerns
15:17:43 <portdirect> and let us reuse much of the logic from loci here
15:18:03 <portdirect> i think as we have a qorum of cores here
15:18:18 <portdirect> can we decide today if this is a sane path or not?
15:18:49 <srwilkers> im all for it
15:18:51 <lamt> portdirect: can we use that image repo to deal with things like that healthcheck issue with the loci repo?
15:19:20 <lamt> I think I still have an outstanding patch set there
15:19:39 <mattmceuen> I'm good with a separate repo too
15:21:42 <jayahn> portdirect: separate repo would be good. just want to know so what images will be hosted there vs. what images we will consume from external repo (registry)? any guideline?
15:22:07 <lamt> portdirect: if so I will abandon that ps and put the change in the new repo
15:22:13 <portdirect> jayahn: ideally the images repo would be empty ;)
15:22:52 <portdirect> and i think thats the best guidance we can follow for it unfortunately - as we know it wont be (eg libvirt etc)
15:23:18 <portdirect> ok - so seems we have agreement
15:23:28 <portdirect> #action portdirect to get images repo up.
15:23:58 <portdirect> i think this brings us onto the last item today
15:24:02 <portdirect> #topic Reviews
15:24:18 <portdirect> Remove fluentbit sidecars from ceph-mon and ceph-osd: https://review.openstack.org/#/c/608356/
15:24:18 <portdirect> Feedback for Apparmor init container: https://review.openstack.org/#/c/608826/
15:25:05 <portdirect> lamt: your one is interesting - I'd need to mull on it more
15:25:28 <portdirect> but in simple terms is this not asking the workload to define its own security policy?
15:25:53 <portdirect> which though it may work - seems a bit like asking a poacher to keep an eye on the livestock?
15:26:10 <lamt> portdirect: thanks for the review. I thought about that.
15:26:29 <srwilkers> good analogy
15:27:04 <lamt> alternative might be we have an apparmor profiles utility to manage exceptional profiles
15:27:10 <lamt> utility chart*
15:27:20 <lamt> for things that fall out of the "default"
15:27:52 <portdirect> yeah - is see issues any way we do it - thats certainly nicer from a seperation of concerns pov
15:28:00 <portdirect> but could be a nightmare for management
15:28:09 <portdirect> i suppose the tradeoff here is:
15:28:33 <portdirect> do we make it easy (the init approach) that may have some issues, but people can use with little overhead
15:28:49 <portdirect> or 'pure', were people may end up using it less?
15:29:17 <mattmceuen> I haven't given the PS a review yet so I don't know the ins and outs but - are we really worried about protecting against the chart (e.g. init container), or are we trying to protect against a hijacked chart?
15:30:12 <mattmceuen> Said differently, if we can trust that only trusted charts get deployed, and the init container approach fits into that well and protects against post-deployment shenanigans, then that seems reasonable?
15:30:14 <portdirect> the latter really, though a chart could be hijacked by a lazy dev too ;)
15:30:40 <lamt> :)
15:30:54 <mattmceuen> lazy devs are the worst
15:31:01 * srwilkers whistles
15:31:11 * mattmceuen and everyone else leaves the roome
15:32:18 * jayahn left the room
15:32:31 * lamt follows
15:32:34 * portdirect now knows how to get some peace round here
15:32:42 <portdirect> :)
15:32:51 <srwilkers> we can change that
15:33:14 <portdirect> i think the point mattmceuen raises is valid
15:33:21 <portdirect> and where im on the fence
15:33:30 <portdirect> i just feel i need to highlight it
15:33:41 <portdirect> frankly - I'm for security people use
15:33:57 <portdirect> which puts me in the camp of saying lets use the init container
15:34:15 <portdirect> but i need to strawman the alternative veiwpoint ;)
15:34:26 <mattmceuen> yup
15:35:12 <portdirect> we ok to hash it out in review from here on?
15:35:13 <lamt> I lean that way - but that's why it was coded that way.  but one can strongarm me to change that
15:35:18 <lamt> portdirect: sounds good
15:35:40 <mattmceuen> +1
15:35:46 <portdirect> ok - any other ps's that need review attention?
15:35:56 <portdirect> (other than all of them...)
15:36:16 <portdirect> ok - moving on
15:36:22 <portdirect> #topic roundtable
15:36:40 <portdirect> 1st I'd really like to thank evrardjp - hes doing great work on the gates
15:36:50 <portdirect> having a new set of eyes there has been fantasic
15:37:03 <portdirect> as, as well as both improving our ansible
15:37:10 <portdirect> hes been asking the hard questions
15:37:21 <portdirect> eg: why? and 'but why?'
15:37:59 <lamt> ++, the ansible looks more sane
15:38:16 <mattmceuen> agree - great work evrardjp & thanks!!
15:38:22 <lamt> at least when I need to add new jobs - I can just list the scripts vs. what was done before
15:44:42 <portdirect> ok - we ok to wrap up for today i think
15:44:48 <portdirect> #endmeeting