15:01:05 <mattmceuen> #startmeeting openstack-helm
15:01:06 <openstack> Meeting started Tue Jul 10 15:01:05 2018 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:09 <openstack> The meeting name has been set to 'openstack_helm'
15:01:28 <mattmceuen> #topic Rollcall
15:01:37 <tdoc> o/
15:01:43 <jayahn> o/
15:02:12 <mattmceuen> GM / GE all!
15:02:13 <mattmceuen> https://etherpad.openstack.org/p/openstack-helm-meeting-2018-07-10
15:02:18 <srwilkers> o/
15:02:19 <srwilkers> hello
15:02:25 <vadym> hi
15:02:34 <mattmceuen> Please go ahead and add anything you'd like to discuss into the agenda
15:02:38 <jayahn> sorry, i have been missing meetings.
15:02:59 <mattmceuen> No problem jayahn :)  I know you guys were really busy with the conference - how did it go?
15:03:05 <jayahn> we had a big openstack (openinfra) event in Korea, and there has been some vacation, urgent works... etc.
15:03:06 <jayahn> sigh
15:03:35 <jayahn> it was great. we had 900 people show up on the first day, and 600 on the second day
15:03:47 <mattmceuen> that's awesome!
15:03:51 <mattmceuen> I saw a picture of you on stage :)
15:03:53 <jayahn> also had hands-on workshop on openstack-helm,
15:04:02 <jayahn> also introduction for airship
15:04:24 <srwilkers> can alexa deploy airship yet?
15:04:32 <mattmceuen> congrats on all that
15:04:35 <jayahn> not yet..
15:04:50 <mattmceuen> Alright let's get started
15:04:52 <mattmceuen> #topic     Approriate behavior of KS endpoints when using fqdn_overrides
15:05:10 <mattmceuen> I will be totally honest, I forget the context of this one, even though I added it a week ago :)  anyone remember?
15:05:13 <jayahn> we might have "kakao - one of the biggest social service and internet company in korea" on board with openstack-helm
15:05:20 <jayahn> I am trying.. :)
15:05:41 <mattmceuen> that's outstanding!  If any kakao folks are here or catching up on the logs - welcome :)
15:06:26 <tdoc> I had some questions last week on those endpoints, it appeared specifying fqdn overrides didn't change public endpoints.
15:06:58 <tdoc> But this week I did more testing, and it does actually put that fqdn in public endpoint...
15:07:15 <tdoc> (Not entirely sure what happened the first attempt.)
15:07:22 <mattmceuen> Oh awesome
15:07:40 <mattmceuen> I love it when problems sort themselves out :)  glad to hear that
15:08:27 <tdoc> what may have caused it is that a helm delete --purge keystone, and then re-install that chart, does not wipe the db by default....
15:08:41 <portdirect> ah  - this is a known bug
15:08:46 <mattmceuen> ah yes
15:08:51 <portdirect> keystone endpoints are a one time deal atm
15:08:58 <portdirect> (for the keystone chart)
15:09:01 <portdirect> all others update
15:09:02 <tdoc> and then keystone bootstrap does not replace the endpoints
15:09:08 <portdirect> I'm working n a fix
15:09:18 <portdirect> which should be in within the next week
15:09:34 <portdirect> as you point out - the keystone-boostrap util does not udpate endpoints
15:09:43 <piotrrrr> does this have a bug entry somewhere we can track the resolution of?
15:09:45 <portdirect> it just creates them in the db if they dont exist
15:09:45 <mattmceuen> yay portdirect
15:09:53 <portdirect> piotrrrr: honestly not sure
15:10:14 <piotrrrr> ok
15:10:17 <tdoc> another thing I ran into today actually is that the default values.yaml doesn't make it very clear how to change the port for the public endpoint
15:10:33 <mattmceuen> piotrrr or tdoc if you're interested in watching the status feel free to put one on storyboard and assign it to portdirect
15:11:11 <tdoc> ok
15:11:50 <tdoc> so, other than that, I don't have anything else on endpoints
15:12:04 <srwilkers> tdoc: i think portdirect has recently updated the docs for the endpoint foo.  it's pretty helpful
15:12:05 <mattmceuen> portdirect is also in the process of adding a lot of great documentation inline in the helm toolkit functions - that will help with understanding how to change that sort of setting
15:12:09 <srwilkers> it cleared some things up even for me
15:12:09 <mattmceuen> ++
15:12:30 <mattmceuen> Spells out the values.yaml structure and the invocation signature for the different HTK functions
15:12:42 <mattmceuen> This will be a great resource (thx portdirect)
15:12:50 <portdirect> though alwayscan do with more hands :)
15:12:58 <portdirect> I'm just going through it all as quick as possible
15:12:59 <tdoc> yup noticed some of that already, thanks!
15:13:05 <mattmceuen> Alright next topic:
15:13:06 <portdirect> but lets enchance them
15:13:20 <mattmceuen> #topic Values yaml schema and validation
15:14:00 <mattmceuen> jayahn do you know whether powerds will have some time to get this one going?   Or should we look for a new owner?
15:14:37 <mattmceuen> There was some good discussion last week around automating schema validation, so this got brought up
15:15:06 <mattmceuen> Or do we have powerds0111 here?
15:15:07 <jayahn> he is here, i think. he said he is terribly sorry for not able to take this.
15:15:14 <mattmceuen> Oh it's no worries
15:15:15 <portdirect> np
15:15:23 <mattmceuen> All good
15:15:37 <mattmceuen> Just need to know if we need to reassign it or not -- everyone's been busy
15:15:47 <powerds0111> o/
15:15:50 <portdirect> as its one of the biggest items for 1.0.x - can we get someone to take this on?
15:17:16 <powerds0111> in the etherpad, srwilkers said can go on the ps
15:18:32 <mattmceuen> yeah srwilkers said he can pitch in on this, but he's also pretty slammed with other LMA work so I know it might be some time before he can get to it
15:19:18 <mattmceuen> So if anyone else gets time - this spec would be a great way to get into spec writing for OSH, and it'll help crystallize the OSH public interface so it can be stable post-1.0
15:19:31 <portdirect> ++
15:19:45 <srwilkers> agreed
15:19:57 <portdirect> without this locked in, we cant really move to supporting multiple os versions in a clean, stable, manner
15:20:02 <mattmceuen> And there's fun opportunity to implement automated values validation afterwards, which will be great for all developers
15:20:07 <portdirect> so really ties into things like rally testing etc
15:21:02 <mattmceuen> I think we can move on, anything else on this topic?
15:21:19 <mattmceuen> #topic All qemu processes for instances are killed when restart libvirt pod (kubectl delete pod libvirt)
15:21:26 <mattmceuen> Dan had a Q on this PS:
15:21:33 <mattmceuen> https://review.openstack.org/#/c/578099/
15:22:52 <powerds0111> yes. I wanna to know what the solution about the issue
15:23:26 <portdirect> ok - if you are using kvm
15:23:37 <portdirect> you can restart the container, without impacting vms
15:24:09 <portdirect> if using qemu then, yeah you cannot restart the pod without killing the vm
15:24:20 <portdirect> *kvm via qemu
15:25:19 <mattmceuen> Make sense powerds0111?  Or any concerns with that approach?
15:25:27 <powerds0111> ah ok
15:25:58 <powerds0111> you mean the issue is on qemu not KVM
15:26:58 <powerds0111> then do we have plan to support qemu without killing the vm?
15:27:37 <portdirect> thats not possible
15:27:41 <portdirect> :(
15:28:28 <portdirect> the change to enabling mount propogation, is to enable pod restart while using kvm, and say nfs to mount a cinder volume
15:28:44 <portdirect> as without mount propogation, the nfs mount would be ripped out...
15:29:09 <powerds0111> ah. for nfs mount case
15:29:20 <portdirect> or many other cinder backends
15:30:42 <mattmceuen> Cool - I think we're good to move on to the next topic unless there's more
15:30:52 <mattmceuen> #topic Touchpoint on Rally multi-version support
15:31:12 <mattmceuen> jayahn I haven't read the full notes yet :)  there is some discussion in the agenda if anyone wants to check that out now
15:31:49 <jayahn> I did  my best to summarize team's feedback from a "shadow" etherpad note. :)
15:32:23 <jayahn> a shadow etherpad  = https://etherpad.openstack.org/p/openstack-helm-meeting-2018-07-10-KR
15:32:25 <jayahn> lol
15:32:27 <jayahn> anyway,
15:33:18 <jayahn> summing up, as pete pointed out, rally is version independent. if we keep using latest rally version, it should support some of previous openstack releases as well.
15:33:28 <jayahn> well, test cases can be different though
15:33:46 <jayahn> one small problem is on kolla rally image.
15:34:06 <jayahn> one question here: can loci provide a clean and updated rally image?
15:35:01 <portdirect> I'd need to check
15:35:08 <portdirect> but last time i did, it could not
15:35:16 <portdirect> as rally did not follow openstack standards
15:35:27 <portdirect> and did not use openstack/requirements
15:35:40 <portdirect> i had a ps to build a lightweight rally/tempest image
15:35:47 <portdirect> that i should get out of limbo though
15:36:24 <jayahn> okay. let's check that later then.
15:36:36 <portdirect> did you read the notes from the last meeting?
15:36:46 <portdirect> as i think that covered most of the points raised
15:36:54 <jayahn> yeap.
15:36:56 <portdirect> im afraid my korean is not good :(
15:37:33 <portdirect> can you help with updating rally version?
15:37:44 <jayahn> i did "Ref_1" "Ref_2"...  on etherpad note, that will track back to your original comments.
15:39:46 <jayahn> we can certainly discuss what we need to do. to-do #1: have updated rally image, to-do #2: agree on a way to provide "rally test cases that might different per version"
15:40:09 <jayahn> I did upload a sample armada manifest that has rally test case in it.
15:40:28 <jayahn> https://github.com/sktelecom-oslab/armada-manifests/blob/master/osh-single-sample.yaml
15:40:43 <jayahn> we want to discuss what would be the best way to provide rally test.
15:41:23 <portdirect> would any of that be applicable upstream?
15:41:40 <portdirect> it would be nice to benefit from any advances you have made internally?
15:43:12 <jayahn> I think it is possible. we just need to discuss what would be best way. "to provide a single rally test scenario can be applied to most of openstack release a.k.a common set" vs. "to provide a rally test per openstack release".
15:43:33 <portdirect> a common set would be perferable
15:43:40 <jayahn> if it is later case, then we need to have a way to provide switchable switchable based on the Openstack release
15:44:05 <portdirect> as remember these tests are not ment to be more than a deployment validation tool
15:44:14 <portdirect> and we have a rally chart for full testing
15:45:22 <mattmceuen> I need to step away for 2min - I'll kick this off and be back in a sec
15:45:26 <mattmceuen> #topic Galera doesn't survive cluster restart. A known issue?
15:45:35 <portdirect> yeah a known issue
15:45:44 <portdirect> again i expect to have this fixed within the next week
15:45:47 <mattmceuen> Jay already weighed in in the etherpad too to that effect
15:45:51 <mattmceuen> Thanks portdirect
15:46:05 <mattmceuen> #topic     Queens support status update? ETA? https://review.openstack.org/#/c/567468/
15:46:24 <portdirect> which will use this: https://review.openstack.org/#/c/562080/
15:46:31 <portdirect> queens again is close
15:46:39 <portdirect> we just need to push some testing images
15:46:42 <portdirect> but other than that
15:46:46 <portdirect> I think we are gtg
15:47:40 <jayahn> portdirect: I will followup soon with applying rally test with armada deployment on upstream gating. (this is MUST followup item, right?)  :)
15:47:50 <portdirect> whoops for the mariadb work i should have posted this link: https://review.openstack.org/#/c/567008/
15:48:04 <portdirect> jayahn: i dont follow?
15:49:04 <portdirect> there is work in progess to use helm-test in the upstream gates if thats what your refering to: https://review.openstack.org/#/c/579652/
15:49:11 <jayahn> i feel like discussion on rally test, especially applying what we have on upstream gating, is stopped in the middle of discussion.
15:49:13 <portdirect> that srwilkers is leading the charge on
15:49:24 <jayahn> so i think it is hightly doable.
15:49:40 <jayahn> want to followup with actual work we need to do..
15:51:17 * mattmceuen is back
15:52:50 * jayahn is confused a little bit. need to have a time to sort out today's meeting.
15:53:22 <mattmceuen> Want to continue the discussion on the ML jayahn?
15:53:53 <mattmceuen> May help just to reframe the conversation instead of having a few weeks of meeting logs back and forth
15:53:55 <jayahn> anyway, your ps https://review.openstack.org/#/c/579652/ looks like test is ready. will it be like "putting testing scenario, do helm test leveraging rally"?
15:55:19 <portdirect> could you rephrase that?
15:55:29 <portdirect> i think something is lost in translation :)
15:55:39 <jayahn> I just want to follow up with pete's request
15:55:39 <jayahn> "can you help with updating rally version?" & "would any of that be applicable upstream?
15:55:39 <jayahn> it would be nice to benefit from any advances you have made internally?"
15:55:41 <jayahn> yeap. :)
15:56:00 <jayahn> something is lost.. :( .
15:56:03 <portdirect> so - it wouldbe great if you guys could audit the tests
15:56:12 <portdirect> and select a set that work with mast rally
15:56:15 <portdirect> and 0.8.0
15:56:19 <portdirect> *master
15:56:28 <srwilkers> ^ that patchset simply tells armada to do what we do in the gates for the standard multinode deployment -- exercise the default helm tests defined in a chart
15:56:39 <portdirect> based on what your teaam is saying, heve they already done this within SKT?
15:59:47 <jayahn> okay, i think this is highly doable for us. I will take it to the team tomorrow (in my time), and get back to you with more detail tomorrow (in your time)
16:00:01 <mattmceuen> Awesome thanks jayahn!
16:00:26 <mattmceuen> Looks like we're out of time unfortunately
16:00:36 <mattmceuen> I'll paste the PS requested for review in the team chat
16:00:41 <mattmceuen> Have a great week everyone
16:00:43 <jayahn> yeap. thansk.
16:00:47 <mattmceuen> #endmeeting