15:00:40 <portdirect> #startmeeting openstack-helm
15:00:41 <openstack> Meeting started Tue Oct  9 15:00:40 2018 UTC and is due to finish in 60 minutes.  The chair is portdirect. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:44 <openstack> The meeting name has been set to 'openstack_helm'
15:00:49 <portdirect> #topic rollcall
15:00:56 <mattmceuen> o\
15:01:05 <roman_g> o/
15:01:07 <lamt> \o
15:01:07 <srwilkers> o/
15:01:12 <srwilkers> look at mattmceuen slapping himself on the head
15:01:29 <portdirect> lets give it 2 mins for anyone else to to turn up
15:01:37 <mattmceuen> that is me hanging upside down
15:01:38 <jamesgu> o/
15:03:50 <portdirect> ok - lets kick off
15:04:11 <portdirect> think it may ba quick on this week :)
15:04:15 <portdirect> #topic Image building in infra
15:04:36 <portdirect> so - for a long time we have been pretty lax in our image building
15:04:38 <evrardjp> o/
15:04:47 <portdirect> this week i really want to move that to infra
15:05:03 <portdirect> and so will get the image build jobs up
15:05:27 <portdirect> I'll probably just use the loci jobs if i can
15:05:47 <evrardjp> so you want to move ALL image building business into -infra ?
15:05:56 <evrardjp> including openstack ones?
15:05:57 <portdirect> yeah i think so
15:06:02 <portdirect> apart from them :)
15:06:02 <evrardjp> ok
15:06:15 <evrardjp> that's fine for me, it's a common place then.
15:06:28 <portdirect> i'd like to get those out of the repo if possible - but we need to start somewhere
15:06:40 <portdirect> and theres a few that are kinda osh specific - eg our libvirt image
15:06:50 <portdirect> and some of the lma stack
15:06:53 <evrardjp> well I was thinking of using a different job for image building so putting them all in the same place makes thing easier.
15:06:58 <portdirect> ++
15:07:26 <portdirect> i dont think theres too much more here atm?
15:07:33 <portdirect> ok to move on?
15:07:39 <jamesgu> cool. In the same area, we are starting the dev work add opensuse based docker files and loci.sh: https://storyboard.openstack.org/#!/story/2004014, https://storyboard.openstack.org/#!/story/2004015. Probably should holding check in after the relocation is completed?
15:08:00 <jamesgu> hold checking in*
15:08:28 <portdirect> for the 1st ones - I think the dockerfiles can come in anytime
15:08:52 <jamesgu> okay
15:08:53 <portdirect> for the openstack service themselves - maybe this would be the perfect time to move those jobs out of openstack helm completely?
15:09:13 * roman_g would start with stock images and work on migration Ubuntu->SUSE in other parts of projects
15:10:10 <jamesgu> do you mean move to openstack-helm-infra or?
15:10:28 <evrardjp> portdirect: OSH needs images right now, and we cannot move them out to LOCI quite yet (I cannot do it without discussion+help at least)
15:10:57 <portdirect> I understand that evrardjp  - though we should get the ball rolling there
15:11:09 <portdirect> can we get this as a topic in the next loci meeting?
15:11:16 <evrardjp> so it makes sense for me to do it in two phases... 1) to get it moved in osh-infra 2) move images building everywhere upstream where possible
15:11:23 <evrardjp> portdirect: that sounds nice to me
15:11:44 <portdirect> we need to find the stone SamYaples been hiding under
15:12:00 <evrardjp> portdirect: must be a big one
15:12:07 <evrardjp> due to the fact I didn't see him recently
15:12:18 <portdirect> yeah - i think hes been snowed under with work :(
15:13:11 <portdirect> ok - lets move on
15:13:24 <portdirect> #topic Gate status
15:13:33 <portdirect> steve - I think this was yours?
15:13:45 <srwilkers> yeah, it was
15:13:52 <evrardjp> I think it's good to sync, as there are many efforts started
15:14:06 <srwilkers> so it's clear there's a lot of work going on with the gates at the moment, and i think it's trying to tackle multiple things at once
15:14:09 <portdirect> oh wait: I'm not sure i put the etherpad link anywhere: https://etherpad.openstack.org/p/openstack-helm-meeting-2018-10-09
15:14:23 * portdirect sorry for inter-ruption
15:14:33 <srwilkers> i really think we should approach this as a multiple step process instead of trying to solve everything all at once
15:14:48 <evrardjp> srwilkers: I agree
15:14:48 <srwilkers> in my mind, the issues we need to solve are:
15:15:09 <evrardjp> srwilkers: we have written these in an etherpad, right?
15:15:26 <evrardjp> I sadly have lost said etherpad link
15:15:28 <srwilkers> 1. get all of our failing jobs passing, with the goal of getting our nonvoting jobs back to voting
15:16:49 <evrardjp> step 1 can be done without gate changes in itself
15:17:13 <portdirect> mattmceuen: is steve still here?
15:17:27 <evrardjp> but that's still a gate state :)
15:17:58 <evrardjp> srwilkers: step 2 is?
15:18:03 <portdirect> evrardjp: mostly i agree, i think this is very much tied to steves 2nd point in the etherpad
15:18:18 <portdirect> 2. Reduce overlap between jobs where possible (ie: don't deploy services we don't need for a particular job, especially if it's deployed in a job already
15:18:41 <portdirect> i know hes been doing some work here for infra already
15:19:21 <srwilkers> sorry, got pulled away for a second
15:19:54 <evrardjp> I am working on 3 and 4 of the etherpad myself. It will allow an easier way to step in to gating for newcomers, IMO. It would also be re-usable.
15:19:58 <srwilkers> yeah.  the second point is mostly an extension of the first point.  the majority of our single node gate failures are a result of pushing single nodepool vm deployments too hard
15:20:25 <srwilkers> evrardjp: yeah, that would be great.  thats why i thought it'd be great to approach this with multiple sequential steps
15:20:39 <portdirect> i think this sounds like a sound approach
15:20:48 <evrardjp> I think 1 is orthogonal to 3 and 4 so it can be done in parallel
15:20:58 <srwilkers> once we get the gate jobs happy again, we can plug them into the consolidation/cleanup work you've been focused on
15:21:06 <portdirect> the one thing i'd like to see though is this https://review.openstack.org/#/c/608045/ coming in to make 1/2 easier
15:21:06 <evrardjp> agreed
15:21:26 <portdirect> as it does not change the logic of what is run today, jut makes it easier to tweak
15:21:47 <portdirect> and if you could build off this evrardjp it may flow easier?
15:22:08 <evrardjp> portdirect: I have built another runner, a little bit more complete
15:22:27 <evrardjp> but it is fine if we go that way, my runner could re-use the work done there.
15:22:29 <evrardjp> see https://review.openstack.org/#/c/608750/4/zuul.d/playbooks/run-scripts.yml
15:22:39 <portdirect> i had a look this morning - it looks nice
15:23:35 <evrardjp> anyway I will continue my work in the background, and will not disturb you in step 1 and 2
15:23:37 <portdirect> id need to check though - I split mine out into a role - as it offered better feedback in zuul ara
15:24:43 <srwilkers> evrardjp: 'disturb' is a bit harsh :)
15:24:49 <evrardjp> we can discuss those in the reviews -- my point was that I will focus on element 3 and 4 from the etherpad, as this will at some point be helpful for my employer to add opensuse support.
15:25:14 <mattmceuen> ima here
15:25:38 <portdirect> ok - so i think we only have one item left atm:
15:25:39 <mattmceuen> sorry, I was pretending to be a scrum master - catching up :)
15:25:54 <portdirect> #topic User UID's
15:25:57 <evrardjp> for step 3 and 4, I will give you a hint of how I will do this: I will migrate job per job, instead of working with the current state.
15:26:12 <portdirect> sorry - i'll wait untill your done - me jumping the gun again
15:26:30 <evrardjp> If nobody is against that method we can continue
15:27:07 <evrardjp> portdirect: I am done now
15:27:32 <evrardjp> we can discuss in the channel if further conversations need to happen too.
15:27:40 <portdirect> evrardjp: i think what your saying sounds good, though code always helps :D
15:28:15 <portdirect> so - on user uids - I've come across a few instances where we colide with 'host' users
15:28:18 <evrardjp> I will dump other patches soon for reimplementing the base job's pre-run plays with less code, and will continue to iterate.
15:28:24 <portdirect> which makes audit hard
15:28:44 <portdirect> the lma stack is pretty spread here i think
15:29:08 <portdirect> (I was accusing a colleague of running fluentbit recently...)
15:29:33 <portdirect> for the openstack images we use 42424 atm
15:29:55 <portdirect> do we have the abillity of either doucmenting, or controlling the uids that containers run as simply?
15:30:15 <portdirect> would allow us to define ranges for pam etc on the host to use that dont overlap
15:30:42 <portdirect> srwilkers / lamt : you have any insight here?
15:31:36 <srwilkers> admittedly, havent looked at it much.  but should be able to document those i would imagine
15:33:06 <lamt> I think we can document that, not sure we can effectively control the uid so they don't overlap though
15:33:27 <portdirect> i was wondering, if we declare these users in the chart, could we at a min have a script that gets them out of our values.yaml?
15:34:10 <lamt> yes via yq
15:35:13 <lamt> do we want to add a script into the tools folder for this?
15:35:30 <portdirect> it would be worth making a ps i think
15:35:43 <portdirect> i know of deployments that certainly need this
15:36:07 <portdirect> you ok to take this on?
15:36:53 <portdirect> lamt: has volunteered :D
15:36:59 <portdirect> nice - thanks dude
15:37:00 <lamt> sure
15:37:20 <portdirect> ok - so that kinda wraps it up i think
15:37:21 * lamt was busy grabbing more caffeine.
15:37:27 <portdirect> #topic roundtable
15:39:03 <srwilkers> well, i don't have anything, i dont think
15:39:26 <lamt> I am good.
15:39:46 <portdirect> ok - lets give everyone some time back
15:39:52 <portdirect> #endmeeting