15:01:26 <portdirect> #startmeeting openstack-helm
15:01:27 <openstack> Meeting started Tue Apr 23 15:01:26 2019 UTC and is due to finish in 60 minutes.  The chair is portdirect. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:31 <openstack> The meeting name has been set to 'openstack_helm'
15:01:34 <portdirect> o/
15:01:58 <portdirect> the agenda for this week is here: please feel free to add to it: https://etherpad.openstack.org/p/openstack-helm-meeting-2019-04-23
15:01:59 <mattmceuen> o/
15:02:03 <howell> o/
15:02:09 <jsuchome> o/
15:02:12 <portdirect> lets give it 5 mins for people to arrive
15:02:28 <alanmeadows> o/
15:02:35 <srwilkers> o/
15:03:05 <itxaka> o/
15:05:00 <portdirect> ok - lets go :D
15:05:06 <portdirect> #topic OpenSUSE Leap15 testing
15:05:19 <portdirect> jsuchome: this is yours i think?
15:05:26 <jsuchome> my color, but basically evrardjp's patch
15:05:27 <evrardjp> o/
15:05:32 <jsuchome> so I'd let him speak :-)
15:05:43 <evrardjp> no go ahead :)
15:06:06 <jsuchome> well, all is summarized in the commit message - we're adding directories with value overrides
15:06:35 <evrardjp> and it works
15:06:35 <jsuchome> different kind, like "specific openstack release", or "opensuse , all releases" or "opensuse, specific openstack release"
15:06:48 <jsuchome> obviously other distributions should benefit from this schema
15:07:29 <evrardjp> I think with portdirect +2 we can say it's an accepted approach, and we can continue on that note?
15:07:46 <jsuchome> e.g. this patch https://review.opendev.org/#/c/651250/ is going the same way, but does not use opensuse specific changes, only overrides for rocky release, but relevant for all distros
15:07:55 <portdirect> it looks great to me as a foundation to build on
15:08:03 <evrardjp> portdirect: that was the idea
15:08:10 <portdirect> and relates to the work that srwilkers and I commited to last week
15:08:41 <portdirect> to condense the gate scripts to a singular path, loading approprate over-rides as desired
15:08:42 <alanmeadows> almost sounds like kustomize is needed
15:08:53 <alanmeadows> to form layers of values ;-)
15:09:00 <portdirect> ^ this may be the correct path
15:09:02 <evrardjp> portdirect: oh great, do you have a patch to show?
15:09:11 <evrardjp> alanmeadows: oh interesting, I don't know this
15:09:19 <portdirect> evrardjp: not yet - we've been snowed under with summit prep
15:09:28 <portdirect> but are hoping to have somthing by ptg
15:09:29 <evrardjp> so using that instead of just passing this to helm charts in bash scripts ?
15:09:38 <evrardjp> portdirect: that sounds like a good ptg discussion
15:10:12 <evrardjp> in the meantime, do any of you object to the fact to continue with current approach, and add non voting jobs for all those helm charts?
15:10:41 <portdirect> no! (as in go for it!) :D
15:10:46 <alanmeadows> either that or some sort of pattern of --values-file x, --values-file y sort of approach because
15:11:02 <portdirect> thats what we do today alanmeadows
15:11:04 <evrardjp> alanmeadows: my idea was to have job names with contain file part patterns
15:11:18 <portdirect> though using a mix of tee'd files and over-rides - so a bit of a rats nest
15:11:18 <evrardjp> so if you have rocky in the job name, pass the rocky files
15:11:24 <alanmeadows> sure, but im only bringing it up in *this* context because
15:11:40 <evrardjp> because?
15:11:42 <alanmeadows> I see something like https://review.opendev.org/#/c/651250/4/neutron/values_overrides/rocky.yaml
15:12:02 <alanmeadows> and then the suse specific stuff - for which no neutron ones exist yet but
15:12:07 <alanmeadows> clearly you want *both*
15:12:26 <alanmeadows> if you want rocky + suse - and the layout isn't shouting that fact out?
15:12:48 <portdirect> alanmeadows: this is one of the things i want to address in the re-work for sure
15:12:56 <itxaka> ptg discussion seems the way to go as this seems like a really nice topic to discuss
15:13:00 <alanmeadows> i only mention kustomize because maybe the overlay stuff can just do magics on the tree
15:13:01 <portdirect> and why i think getting the initial suse over-rides really helps there
15:13:08 <alanmeadows> so you dont need to --values-file * 10
15:13:11 <itxaka> shame that I wont be there, it would be really interesting!
15:13:14 <portdirect> as we have close to the final mix of params:
15:13:19 <evrardjp> alanmeadows: correct
15:13:30 <portdirect> distro version, deployment options, container-distro
15:13:31 <evrardjp> alanmeadows: I guess the idea was to see what we need, then iterate
15:13:33 <jsuchome> there is https://review.opendev.org/#/c/651491/9/neutron/values_overrides/rocky-opensuse_15.yaml
15:13:44 <alanmeadows> don't mean to block anything in flight, just saying
15:13:46 <alanmeadows> it struck me ;-)
15:13:55 <jsuchome> that is suse specific as it is only for images, the one for neutron/values_overrides/rocky.yaml means "rocky for neutron, all distros"
15:13:57 <evrardjp> alanmeadows: what's important to notice is that they are separated by goals
15:14:08 <evrardjp> so overlaying has no conflicts
15:14:29 <evrardjp> I guess it's better to discuss this at PTG :)
15:14:43 <evrardjp> itxaka: I guess we'll write things in etherpads for you :)
15:14:50 <itxaka> please dooo
15:15:41 <evrardjp> so let's continue and rephrase all the possible issues with the current implementation during the PTG to improve the "how" in the future
15:16:22 <portdirect> sounds good to me
15:16:37 <portdirect> - on that note - how many people will be at the ptg next week?
15:17:13 <srwilkers> i'll be there
15:17:31 <itxaka> not me ¬_¬
15:17:46 <alanmeadows> i'll be wearing a cape
15:17:51 <portdirect> itxaka: that sucks - it would have been great to meet you :(
15:17:54 <srwilkers> itxaka: that's unfortunate :(
15:18:12 <itxaka> I think evrardjp and jHesketh both will be there from our team
15:18:25 <itxaka> not sure if jsuchome is going?
15:18:31 <jsuchome> nope, I'm not
15:19:21 <portdirect> ok - i think its vital to have jsuchome and itxaka involved in this convo
15:20:03 <portdirect> so we can discuss at ptg - but will make sure to get your input and fb
15:20:17 <portdirect> ok to move on?
15:20:22 <jsuchome> +1
15:20:28 <portdirect> #topic K8s-entrypoint
15:20:37 <portdirect> howell: you're up
15:20:41 <howell> yup
15:20:58 <howell> so things have been picking up a bit in the argo/workflow/crd space
15:21:23 <howell> and the current POC requires a tool called kubernetes-entrypoint
15:21:37 <howell> https://github.com/stackanetes/kubernetes-entrypoint
15:22:05 <howell> i did some work a while back to add functionality for waiting on arbitrary CRDs
15:22:36 <howell> but unfortunately, stackanetes seems to have basically abandoned the project
15:22:54 <howell> so it's been pretty hard to get stuff merged and to get images built
15:23:04 <portdirect> all the maintainers have moved onto other things :( though run a pretty nice crypto exchange :)
15:23:30 <evrardjp> that is very unfortunate, is there no maintainers at all?
15:24:02 <portdirect> it was run by coreos
15:24:18 <evrardjp> do we need to carry this ourselves?
15:24:29 <howell> ^ this is what i'd like to propose
15:24:32 <portdirect> i think it needs to be carried by someone
15:24:43 <alanmeadows> We should get this moved into airship/ potentially
15:24:53 <alanmeadows> so we can carry the torch forward
15:25:03 <evrardjp> alanmeadows: that looks fine to me, if that's used everywhere
15:25:03 <alanmeadows> if they have no wish to continue the project
15:25:13 <portdirect> i agree
15:25:14 <evrardjp> and if we can't continue there ofc
15:25:17 <alanmeadows> yeah the same dependency approach is used everywhere
15:25:22 <portdirect> as though its used primarily by htk
15:25:31 <portdirect> osh is very focused on deployment tooling
15:26:04 <evrardjp> howell: pardon my stupid question -- how do others big deployment projects do if they don't have the same kind of things?
15:26:58 <evrardjp> or let me rephrase, is there any alternative?
15:27:02 <howell> evrardjp: to be honest, i haven't looked into it much. obviously stackanetes was using it, but beyond that, i'm not sure
15:27:21 <portdirect> evrardjp: this is one of the great questions of k8s ;)
15:27:31 <howell> the way the argo poc uses it is as minimally as possible
15:27:40 <portdirect> in essence - the crashloop is king :-O
15:27:47 <evrardjp> portdirect: which is why we don't need to come up with a solution on our own
15:27:47 <portdirect> and operators are the other approach
15:27:53 <howell> the workflow is driven with argo, and k8s-entrypoint just waits on the workflow
15:28:10 <evrardjp> that was my understanding
15:28:16 <portdirect> correct
15:28:20 <howell> as opposed to using k8s-entrypoint to create a hacked together dependency graph with k8s jobs
15:28:59 <evrardjp> that is nicer at the end, but I guess the workflow needs now to be aware of the multiple helm charts, vs 1
15:29:08 <portdirect> not really
15:29:19 <portdirect> but this digresses from the issue at hand
15:29:24 <evrardjp> portdirect: well it needs to have a full dependency graph I guess in that case
15:29:26 <evrardjp> sorry
15:29:29 <portdirect> we need to find a home for k8s entrypoint
15:29:41 <alanmeadows> I can reach out to them today
15:29:48 <evrardjp> alanmeadows: that would be great
15:30:02 <alanmeadows> to see how they feel or if they want to reinvest in where its at
15:30:12 <portdirect> alanmeadows/mattmceuen: between the three of us - can we find a place for this?
15:30:25 <portdirect> if you could lead that effort alanmeadows it would be great
15:30:29 <alanmeadows> I'll take it
15:30:33 <srwilkers> cool
15:30:54 <howell> aweseome, thanks
15:31:27 <portdirect> as it came up here, I think this is a good segway into the workflow work that we've been doing
15:31:41 <portdirect> as howell has been leading some really cool poc work
15:31:59 <portdirect> that we will present at the summit
15:32:10 <portdirect> and then i think would be great to disect at the ptg
15:32:21 <portdirect> as obviously we can make this proposal
15:32:38 <portdirect> but should not do so in a vacuum
15:33:38 <portdirect> #topic Gate-script re-work
15:34:06 <portdirect> we touched on this earlier
15:34:26 <portdirect> but with the suse initial over-rides merged we can start to think about this a bit more
15:34:31 <portdirect> and should have something for the ptg
15:34:45 <portdirect> not sure if theres too much to add, unless you have somthing srwilkers ?
15:35:00 <srwilkers> nothing to add at the moment
15:35:24 <portdirect> #topic apparmor
15:35:40 <portdirect> its come to my attention that our apparmor implementation has some issues
15:36:01 <portdirect> not least that though we expose the option to specify what flavour of MAC you want
15:36:18 <portdirect> theres not way to actually utilise any other one (eg selinux)
15:36:45 <portdirect> does anyone have interest in adding selinux support?
15:37:34 <itxaka> doesnt look like :p
15:38:34 <portdirect> ok - I'll update the htk function to open the door to other implementations if desired, but leave them stubbed out
15:38:50 <portdirect> #topic TF changes review
15:39:01 <prabhusesha_> Hi all
15:39:08 <prabhusesha_> this is Prabhusesha
15:39:32 <prabhusesha_> regarding TF charts, it's a public https://github.com/Juniper/contrail-helm-deployer
15:39:46 <prabhusesha_> I gave incorrect info in the last meeting
15:39:49 <portdirect> and the openstack-images?
15:40:13 <prabhusesha_> it wil be good, if somebody give us comments
15:40:28 <portdirect> are the requried openstack images to work with tf public?
15:40:34 <prabhusesha_> yes.
15:41:09 <portdirect> then can you add them to the ps
15:41:23 <portdirect> eg line97 here refers a file that does not exist in the ps: https://review.opendev.org/#/c/622573/2/tools/deployment/multinode/141-compute-kit-tungstenfabric.sh
15:41:35 <portdirect> also can this be validated in nodepool?
15:41:42 <prabhusesha_> ok
15:41:49 <itxaka> is contrail TF? or TF and contrail are different things? getting a bit confused on the naming here....
15:42:02 <prabhusesha_> It's TF
15:42:06 <itxaka> ah, ok :D
15:42:13 <prabhusesha_> image names still has opencontrail
15:42:23 <portdirect> itxaka: opencontrail became tf about a year ago
15:42:25 <prabhusesha_> I can do the cleanup as part of the review comments
15:42:47 <portdirect> prabhusesha_: i think you'll get more traction if the basic deployment works
15:43:04 <portdirect> and we have a method of checking this via zuul
15:43:16 <prabhusesha_> ok
15:43:51 <prabhusesha_> Can we still somebody provide preliminary comments regarding the new files ?
15:43:54 <portdirect> will tf run in a vm with 8gb ram?
15:44:02 <prabhusesha_> for deployment scripts
15:44:25 <prabhusesha_> yes. it will run in a VM
15:44:25 <srwilkers> We can provide some comments, but they’ll be very much restricted without seeing this execute and run
15:44:50 <portdirect> prabhusesha_: have you reviewed Andrey Pavlov's comments?
15:44:59 <prabhusesha_> I will work on running on nodepool
15:45:27 <prabhusesha_> I will work with Andrey and update the patchset
15:45:40 <portdirect> that would be great - he raises the same concerns
15:45:52 <portdirect> that as-is nova and neutron are undeployable in that ps
15:46:10 <portdirect> as they refernece files that do not exists
15:46:21 <portdirect> and images that do not have tf plugins installed
15:46:49 <prabhusesha_> will take care of it and update the new patchset
15:46:56 <portdirect> awesome - thanks dude
15:47:11 <prabhusesha_> thanks
15:47:34 <portdirect> #topic Tempest chart status report
15:47:58 <portdirect> itxaka: the floor is yours
15:48:29 <itxaka> ah thats me, just a quick heads up that with all the patches sent and the changes from srwilkers to see the old dead containers, tempest chart is now deployable and it passes 100% of the tests :)
15:48:45 <itxaka> that is with nova and neutron disabled by default
15:48:51 <itxaka> take about 59 minutes to run
15:49:06 <portdirect> itxaka: this is fantastic news
15:49:13 <itxaka> so if you are interested in supporting and using tempest to validate your helm deployments be sure to review those tempest patches asap :P
15:49:18 <itxaka> that's all from my side
15:49:24 <portdirect> can we get this added as a gate?
15:50:01 <itxaka> well, I was waiting to check how much would it take for tempest to run when nova and neutron are enabled
15:50:13 <itxaka> to make it a good check of all core services
15:50:20 <itxaka> but sure, I can do that already
15:50:51 <portdirect> awesome, that would be a real step forward for osh
15:51:39 <portdirect> #topic reviews
15:52:09 <portdirect> as always we have some reviews that could do with some help getting to the finish line:
15:52:16 <portdirect> https://review.opendev.org/#/c/653948/: fix metrics gathering from deployed prometheus exporters in post run job
15:52:16 <portdirect> tempest:
15:52:16 <portdirect> https://review.opendev.org/650933 -> Add tempest suse image and zuul job
15:52:16 <portdirect> https://review.opendev.org/652700 -> Fix tempest test script
15:52:16 <portdirect> https://review.opendev.org/653425 -> Fix some tempest values
15:52:17 <portdirect> https://review.opendev.org/653428 -> Add tempest job to zuul as non-voting
15:52:17 <portdirect> https://review.opendev.org/#/c/648307/ Nova console/ip address search optionality
15:52:18 <portdirect> https://review.opendev.org/#/c/651433/ Start nova sshd container only if enabled
15:52:18 <portdirect> https://review.opendev.org/#/c/654453/: fix divingbell check after opendev migration
15:52:19 <portdirect> https://review.opendev.org/#/c/652743/ Define test specific timeouts for LMA in Armada manifest
15:53:28 <portdirect> #topic parking-lot
15:54:03 <portdirect> just a reminder that tomorrow we'll have office hours in the #openstack-helm channel
15:54:26 <portdirect> anything else we should be thinking about this week?
15:56:30 <portdirect> ok - lets wrap up
15:56:36 <portdirect> thanks everybody!
15:56:40 <portdirect> #endmeeting