15:00:30 <mattmceuen> #startmeeting openstack-helm
15:00:31 <openstack> Meeting started Tue Jun  4 15:00:30 2019 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:35 <openstack> The meeting name has been set to 'openstack_helm'
15:00:39 <mattmceuen> #topic Rollcall
15:00:45 <mattmceuen> GM / GE all!
15:01:00 <mattmceuen> Let's give it a few minutes for folks to join
15:01:07 <srwilkers> o/
15:01:11 * srwilkers scurries off for caffeine
15:01:22 <jsuchome> o/
15:01:29 <gagehugo> o/
15:01:40 * mattmceuen virtual coffee for jayahn and srwilkers
15:01:48 <itxaka> \o
15:01:55 <georgk> hello
15:02:01 <itxaka> on extra over here pls mattmceuen
15:02:05 <mattmceuen> Thanks for joining all
15:02:10 <itxaka> s/on/one/
15:02:15 <howell> o/
15:02:18 * mattmceuen coffee -> itxaka posthaste
15:02:33 <evrardjp> o/
15:02:46 <mattmceuen> Our fearless leader is tied up, so I'll try to cover!
15:03:33 <mattmceuen> However, I don't have an agenda prepped, so we'll be doing this a bit ad hoc
15:03:35 <mattmceuen> https://etherpad.openstack.org/p/openstack-helm-meeting-2019-06-04
15:03:52 <mattmceuen> please add any topics you'd like to discuss into there
15:05:04 <jayahn> o/
15:05:38 * jayahn is half sleeping
15:05:54 <mattmceuen> #topic Feedback on hugepage support in HTK resource handling
15:06:03 <mattmceuen> https://review.opendev.org/#/c/662603/
15:06:07 <mattmceuen> Feedback welcome ^
15:06:23 <mattmceuen> georgk anything else to discuss here or just offline in the patchset?
15:06:50 <georgk> both is fine
15:07:12 <mattmceuen> cool - to parrot you :) in the agenda notes:      Question: adding checks for hugepage resources or removing checks, as in https://review.opendev.org/#/c/662603/1
15:07:33 <mattmceuen> can you give us a quick overview georgk
15:07:53 <georgk> I'd like to add hugepage resoruce handling to HTK
15:08:22 <georgk> and there is a debate if the corresponding resource snippet should check input or not
15:08:46 <itxaka> what are the cons of extra checking?
15:08:51 <itxaka> complexity in the snippet?
15:09:57 <georgk> the check sanitize the input. in case of a type, for instance hugepages-2M instead of hugepages-2Mi, this would be removed
15:10:04 <georgk> from the resource definition.
15:10:31 <georgk> as a result, the pod gets spawned without hugepage config, resulting in an application error
15:10:51 <georgk> if the check was not there, K8s would have not spawned the pod due to the typo
15:10:57 <georgk> catching the problem earlier
15:11:23 <georgk> funny, thing, in this case fewer checks chatch the problem earlier.
15:11:25 <evrardjp> for me this raises a bigger concern in my head
15:11:38 <evrardjp> where is the limitation of what we implement in HTK
15:12:11 <evrardjp> for me the goal of HTK is to provide convenience, and for example, in this case, I would not use htk, but pass the data verbatim to k8s
15:12:19 <evrardjp> htk can provide validation
15:12:26 <evrardjp> so where is the boundary?
15:12:57 <evrardjp> I like the fact we provide validation in htk, I find it less useful if we just retemplate yaml
15:13:08 <evrardjp> did I generalize the concern correctly georgk?
15:13:27 <mbuil> actually, when using hugepages-2M, k8s does not complain saying "I don't understand this resource". I don't remember the exact error but it was something like "I can't get hugepages-2M" which made things very confusing because there were enough free hugepages-2M
15:13:51 <srwilkers> helm-toolkits meant to give us a consistence interface with interacting with charts -- in this case specifically, it gives us a clean interface to inject the yaml instead of having to modify the chart templates directly each time we want to modify these things
15:13:54 <georgk> evrardjp: yes, thanks
15:14:25 <evrardjp> srwilkers: oh so in this case it's not about validation but DRY approach
15:14:29 <georgk> srwilkers: I do this benefit
15:14:42 <mattmceuen> For cases where we render an override chunk directly into a k8s manifest 1:1, I would lean toward not getting in the business of validating k8s schema for k8s
15:14:46 <evrardjp> did I get that correctly?
15:15:05 <evrardjp> mattmceuen: in that case the function doesn't need to exist in htk
15:15:08 <evrardjp> at all
15:16:07 <georgk> evrardjp: the function does a bit more as it also checks if resource handling is enabled or not
15:16:09 <evrardjp> because consistency is naturally implied by convention (we respect k8s data structure)
15:16:34 <evrardjp> georgk: so I guess there are multiple problems at hand here.
15:16:53 <evrardjp> let's not go into the generalization to make the problem simpler to apprehend. Sorry if I went for a different path :)
15:18:38 <georgk> so, I wanted to tap into the experience of the folks here to decide which way to go best.
15:18:50 <georgk> feel free to take some more time to look at the patchset
15:18:58 <mattmceuen> For the updated version of of _kubernetes_resources, I think I agree evrardjp -- it's mostly one like of "toYaml" and 50 lines of boilerplate.  Maybe better to put "toYaml" directly in the calling manifest in that case.  However, if we do want to enforce a schema (as opposed to toYaml) then I see the value of retaining the snippet for the sake of driving consistency across charts.
15:19:05 <mattmceuen> pros/cons both ways
15:19:28 <evrardjp> mattmceuen: agreed there
15:19:39 <mattmceuen> Sounds good georgk -- I think we all understand the problemspace well enough to mull over it now :)
15:19:44 <mattmceuen> thanks for bringing it up
15:19:50 <evrardjp> then we "just" have to decide which function deserves validation
15:20:07 <evrardjp> which input*
15:20:13 <mattmceuen> yeah
15:20:20 <cheng1__> if we enhance the htk function, which case do we handle
15:21:03 <evrardjp> if you want validation (so deep knowledge of the app) and what you are doing is across multiple charts, then htk need to be adapted for enforcing convenience
15:21:06 <cheng1__> limit user input?
15:21:11 <evrardjp> mattmceuen: did I summarize this well?
15:21:12 <mattmceuen> take a look at the final comment in that patchset as well cheng1__ -- it has a pretty good example
15:21:49 <evrardjp> enforcing conformity*
15:22:52 <mattmceuen> the good thing about a "toYaml" approach is that it's very flexible, so you can add in new inputs as the native k8s api object is enhanced over time for example.  The bad thing is that is's very flexible, so you can get your input wrong, and sometimes k8s can give you cryptic error messages back :)
15:23:02 <mattmceuen> there's a place for both
15:23:10 <georgk> so, given that there will likely be nasty cornercases which cannot be handled well, I lean towards the toYaml approach
15:23:27 <srwilkers> in this case specifically
15:24:28 <srwilkers> actually, nevermind me
15:24:58 <mattmceuen> So then the question is
15:25:13 <itxaka> damn you had me hanging there for one full minute srwilkers
15:25:23 <itxaka> now I want to know what you were gonna said :/
15:25:46 <srwilkers> itxaka: :)
15:25:50 <evrardjp> it's not the first time he does that in a meeting :p
15:25:54 <mattmceuen> If we just want toYaml, and we think "direct toyaml is better than wrapped toyaml" --  is it still a good idea to make the htk function a pass-through for the sake of consumers of the function
15:26:32 <mattmceuen> that would give some time to update osh proper, airship, anything else before yanking the function out
15:26:35 <evrardjp> I believe if the function is just reoutputting same yaml, then the function needs to be deprecated
15:26:49 <mattmceuen> deprecated:  agree.  time-delayed removal
15:26:51 <evrardjp> (same or similar, with indention)
15:27:01 <evrardjp> indentation*
15:27:13 <mattmceuen> Any objections?
15:27:13 <evrardjp> indentation shouldn't be a valid reason to keep tech debt
15:27:21 <itxaka> agreed ^^
15:27:25 <jayahn> agreed..
15:27:48 <mattmceuen> boom.  look at us, we decided something, portdirect will be so happy
15:27:55 <mattmceuen> unless he disagrees, in which case too bad :p
15:27:58 <georgk> :-)
15:28:02 <mattmceuen> Ok, moving on:
15:28:03 <georgk> awesome
15:28:05 <georgk> thanks
15:28:06 <mattmceuen> #topic Technical debt
15:28:12 <itxaka> thats me!
15:28:18 <mattmceuen> take it away!
15:28:35 <evrardjp> we just talked about one, more tech debt reduction?
15:28:36 <evrardjp> awesome!
15:28:46 <itxaka> so it was mentioned last week on the channel that some of the comments and views on some patches were ignored and there was a feeling that there is not enough done to reduce tech debt
15:29:17 <itxaka> so Im wondering, how can we tackle that? how can we start reducing tech debt for a nicer maintenance of osh?
15:29:30 <evrardjp> best code to maintain is no code :)
15:29:36 <jayahn> i am not following
15:29:43 <evrardjp> I was told rm -rf is not a solution though
15:29:50 <evrardjp> do you have an example itxaka?
15:29:50 <mattmceuen> that's a broad topic itxaka!  Can you point us to an example or an embryonic thought or something
15:29:55 <itxaka> no ideas here other than having "reduce tech debt" day once per month/15 days
15:30:02 <jsuchome> (how is rm -rf not the solution?)
15:30:22 <mattmceuen> rm -rf everything except the tests, and work your way back from there jsuchome
15:30:24 <evrardjp> itxaka: how you want to have a periodic checking of what we all achieved to reduce tech debt?
15:30:24 <itxaka> evrardjp: it was you the one to mention it, so hopefully you will have an example ;)
15:30:35 <evrardjp> damn I can't remember now
15:30:41 <itxaka> Im just a vessel of thougths and feeelings
15:30:43 <mattmceuen> lol
15:30:43 <evrardjp> oh yes!
15:30:46 <evrardjp> I remember
15:30:51 <mattmceuen> my feelings agree with your feelings
15:30:53 <evrardjp> cool ... so!
15:31:25 <evrardjp> yes we are adding new images in osh-images, with no explanation whatsoever how they gonna fit in the OSH vision (for example, how they will be used in helm charts)
15:31:50 <evrardjp> if future me wants to rm -rf all the things, he will check for the reason why image x exists in the first place
15:31:57 <jsuchome> yep, let's test drive it all, if only someone would give us few years of uninterrupted development...
15:32:26 <jsuchome> (sorry JP I did not want to interrupt your thoughts)
15:32:53 <evrardjp> haha
15:33:38 <evrardjp> my point is that we all need to be aware that the code we are adding has downsides, and we should drive to periodically reduce old remnants
15:33:52 <srwilkers> with regards to images, i can speak to a few that i've added/proposed
15:34:00 <itxaka> hence "reduce tech debt" day :P
15:34:01 <evrardjp> for example, we discussed at the PTG to remove the newton building of images. This was a good idea.
15:34:14 <evrardjp> I just want to make sure we are not forgetting things
15:34:16 <evrardjp> all together
15:34:30 <evrardjp> srwilkers: it's not targetted against a single individual
15:34:41 <evrardjp> it's we need to take ownership _together_ ;)
15:34:57 <srwilkers> well right, but i feel the context helps that collective ownership
15:35:02 <georgk> evrardjp: you have a good point here and I see this specifically be true in case of the dpdk images
15:35:13 <georgk> blaming myself here
15:35:16 <evrardjp> awesome, I am all ears srwilkers :D I love a good narrative
15:35:32 <mattmceuen> Is you guys' feeling that we're adding things we shouldn't (unneeded tech debt) or that we're not sufficiently explaining/documenting/discussing the widgets that are added
15:36:00 <evrardjp> mattmceuen: I guess without the latter we can't evaluate the former
15:36:13 <jayahn> latter
15:36:30 <evrardjp> we can only trust your insights in that case.
15:37:02 <mattmceuen> one easy thing that we've done inconsistently / ad-hoc -- maybe every time we add an X we then do a quick show-and-tell in this team meeting; where X is something we can define that is bigger than a line of code
15:37:03 <evrardjp> the former might have happened too, but let's not go into the specifics right now I would say
15:37:29 <evrardjp> mattmceuen: alternatively, provide a release note ?
15:37:36 <itxaka> release notes +1
15:37:46 <itxaka> I would forget stuff otherwise for sure
15:37:56 <evrardjp> let's have a "what's in it for the community"
15:38:09 <mattmceuen> agree 100%, only caveat is that we currently have a team meeting and we currently don't have a release notes :)
15:38:10 <evrardjp> release notes would be the target reading for all deployers
15:38:20 <evrardjp> don't we?
15:38:26 <evrardjp> I think I wrote things for that?
15:38:29 <jayahn> we have
15:38:31 <mattmceuen> oh I may have missed it
15:38:31 <itxaka> I guess we can agree that for any change that is relatively "costly" a release note should be provided so everyone is awere of how, why, when
15:38:32 <mattmceuen> my bad
15:38:40 <jayahn> not forced or recommend in the process yet
15:38:45 <evrardjp> proves I need to communicate better :D
15:38:56 * mattmceuen is the worst at communicating :D
15:39:16 <itxaka> should have provided a release note for that evrardjp ;)
15:39:18 <evrardjp> I think it's two things itxaka: commit messages for the WHY is good, renos are a plus for deployers
15:39:19 <mattmceuen> evrardjp you probably just need to add a release note letting folks know there are release notes
15:39:46 <evrardjp> I probably did, but we don't release yet, so we don't publish them yet :p
15:39:51 <evrardjp> different topic there
15:39:53 <mattmceuen> so should we gently start encouraging folks to add release notes, via patchset feedback, in preparation for it becoming part of the formal process?
15:40:32 <itxaka> +1
15:40:36 <jayahn> but, then where we can check all the release notes? we don't have releases yet.
15:40:39 <evrardjp> mattmceuen: I think that would be one good action item... If commit messages explain well the WHY things are done, and release notes are provided when a user facing feature appears, then we are good
15:40:49 <jayahn> ah.. evrardjp, mentioned
15:40:56 <mattmceuen> ++ evrardjp
15:41:00 <evrardjp> jayahn: in the meantime that would be in-tree
15:41:33 <evrardjp> but all the deployer facing features would be there, so you know you have to read them :)
15:42:46 <mattmceuen> sounds like a plan to me.  Let's all please keep an eye out for good use cases for release notes and steer the broader team toward creating them in PS, as well as explanatory commit messages
15:43:04 <mattmceuen> Good to move on itxaka & all?
15:43:10 <evrardjp> lgtm
15:43:17 <itxaka> yup yup!
15:43:18 <mattmceuen> cool
15:43:21 <jayahn> +1
15:43:23 <mattmceuen> #topic When meeting time poll will happen?
15:43:32 <mattmceuen> I'm going to go out on a limb and guess this is yours jayahn?
15:43:33 <jayahn> i wrote in etherpad
15:43:54 <mattmceuen> The easy thing for me would be to punt this one to portdirect :p
15:44:01 <mattmceuen> however I made the same commitment on the airship side
15:44:07 <jayahn> i have been talking about this since ptg. but, honestly, i feel like i am the only one who cares about this
15:44:16 <mattmceuen> #action mattmceuen to sit down with portdirect to do polls this week
15:44:35 <mattmceuen> sorry for the delay jayahn, been real busy but that's not a good excuse
15:45:15 <itxaka> didnt we brougth it up on the last meeting and ti was agreed that a mail was gonna be sent?
15:45:38 * itxaka searches for last etherpad agenda...
15:45:38 <jayahn> yeap.
15:45:38 <srwilkers> i raised it to portdirect after last meeting, but it's not happened yet
15:45:46 <evrardjp> jayahn: you are not the only one
15:45:56 <evrardjp> sorry if you feel that way
15:46:15 <mattmceuen> well the other thing is... many folks who would care probably aren't here
15:46:18 <jayahn> my additional comment on etherpad is just asking if simple poll is right way. but it is just flow of my thought
15:46:27 <itxaka> indeed, that sucks, sorry for the delay jayahn
15:46:29 <mattmceuen> It'll happen by next week
15:47:24 <mattmceuen> Ok - if there isn't anything else on this one we'll move on
15:47:26 <evrardjp> mattmceuen is rolling for initiative.... !
15:47:30 <itxaka> well, I guess the poll can also help in gauging the interest from other parties in participating and if that interest is big enough something should be discussed on how to approach that
15:47:46 <mattmceuen> #topic I have an entire hour with portdirect on Friday on our outlook calendars for this >:-)
15:47:46 <itxaka> this is in regards of your comments in the etherpad jayahn ^^
15:47:57 <mattmceuen> lol I didn't mean to make that a topic
15:48:00 <itxaka> I like this topic
15:48:07 <jayahn> itxaka: yeap. thanks
15:48:08 <mattmceuen> this will make for the best meeting notes
15:48:17 <mattmceuen> portdirect will never let me lead this meeting again
15:48:18 <itxaka> whats the outcome of this topic :P
15:48:21 * mattmceuen mission accomplished
15:48:34 <mattmceuen> #topic Review Requests
15:48:40 <mattmceuen> https://review.opendev.org/#/c/653428/ -> Add tempest job and gate to zuul as voting
15:48:40 <mattmceuen> https://review.opendev.org/#/c/662992/ -> htk: provide default domain env and secrets
15:48:40 <mattmceuen> Follow up: https://review.opendev.org/#/c/662993/ -> keystone: default domain fix
15:48:40 <mattmceuen> https://review.opendev.org/#/c/662988/ -> tempest: several fixes to tempest config
15:48:40 <mattmceuen> https://review.opendev.org/#/c/662775/ -> Update apparmor job after fluent-logging split (Fixes apparmor job!)
15:48:41 <mattmceuen> https://review.opendev.org/#/c/622573/7 -> TF plugin review
15:49:00 <qwebirc65085> Hi all
15:49:02 <evrardjp> I have an extra topic
15:49:02 <mattmceuen> Good mix of interesting patchsets being asked for review - thanks for adding them, and let's please put them on our to do lists
15:49:06 <qwebirc65085> This is prabhu
15:49:17 <mattmceuen> hey prabhu
15:49:21 <jayahn> hi prabhu
15:49:22 <qwebirc65085> Just reminder to review TF plugin changes
15:49:23 * mattmceuen evrardjp - noted
15:50:11 <qwebirc65085> I have added 2 links on story board, one for plugin changes and the other one for TF bringup with openstack
15:50:13 <evrardjp> prabhu you are at the right time :)
15:50:25 <mattmceuen> Thanks for the reminder prabhu
15:50:54 <qwebirc65085> any questions on the writeup, please let me know
15:51:24 <mattmceuen> is the patchset you linked for the plugin change, and bringing it up with openstack is still TODO?
15:51:50 <qwebirc65085> no.  latest patchset is working fine with TF
15:51:59 <mattmceuen> ok great
15:52:05 <mattmceuen> very cool
15:52:11 <qwebirc65085> i have fixed some stuff seen during my unit testing.
15:52:12 <itxaka> qwebirc65085: regarding the doc you sent, maybe you should host it somewhere and link it from the story? (Maybe its already linked, havent had time to look at the stories)
15:52:32 <srwilkers> we still need to see it exercised as a job that runs in openstack-infra to be able to properly validate it and provide valuable review
15:52:35 <qwebirc65085> i didn't find a place to upload complete doc
15:52:44 <qwebirc65085> that's why i put it as story
15:53:04 <mattmceuen> for the story, you can link back to them via the `Story:` and `Task:` tags in the commit message IIRC
15:53:12 <itxaka> ummm, no attachments in storyboard, that sucks :(
15:53:22 <qwebirc65085> @srwilkers: ok
15:54:15 <mattmceuen> Yeah, I see a lot of scripts in your PS to run TF -- hopefully it'll be a straightforward thing to just add (one or more) gates to run the scripts, similar to what we have now
15:54:32 <mattmceuen> ok -- evrardjp you had an additional topic!
15:54:45 <evrardjp> yes
15:54:49 <evrardjp> so...
15:55:01 <evrardjp> openstack-helm-images promote pipeline is broken
15:55:05 <qwebirc65085> @mattmceune: ok
15:55:19 <mattmceuen> #topic openstack-helm-images promote pipeline is broken
15:55:27 <mattmceuen> What do we need to do to fix it evrardjp?
15:55:30 <evrardjp> let me rephrase that
15:55:48 <evrardjp> that sounds like a big deal, but it's not :)
15:55:51 <evrardjp> so
15:56:01 <evrardjp> in a recent patch, I added the fact to build/publish images with -date
15:56:12 <evrardjp> that doesn't work in promote pipeline right now.
15:56:17 <evrardjp> I am working with infra to fix that
15:56:25 <evrardjp> in the meantime we can:
15:56:44 <evrardjp> remove the publication with dates, and do it again when infra is ready
15:57:03 <evrardjp> I just wanted to raise awareness of the problem
15:57:18 <mattmceuen> gotcha - what is the issue w.r.t infra support for the dates?
15:57:20 <itxaka> do we have an estimation on when would infra be ready?
15:57:36 <evrardjp> and I will submit a review to revert what I added, to make sure we can still publish images.
15:57:42 <itxaka> if its too long then +1 to revert + postpone
15:57:44 <evrardjp> so expect later a revert of the revert
15:57:57 <mattmceuen> sounds like a plan
15:58:23 <evrardjp> mattmceuen: for technicalities, ansible_date_time is not part of the facts available on the pipeline
15:58:34 <mattmceuen> ahh
15:58:37 <evrardjp> it involves zuul executors if you are interested.
15:58:46 <itxaka> oooh
15:59:14 <mattmceuen> interesting - I would like to dig more, my zuul integration knowledge is not strong
15:59:29 <evrardjp> time is of the essence
15:59:33 <evrardjp> on the channel maybe?
15:59:44 <mattmceuen> +1
15:59:50 <evrardjp> thanks mattmceuen for the meeting!
15:59:51 <mattmceuen> and with that we are out of time!
15:59:58 <itxaka> o/
16:00:00 <mattmceuen> Thanks for joining everyone
16:00:04 <evrardjp> thanks everyone!
16:00:05 <mattmceuen> see y'all in the channel
16:00:08 <itxaka> thanks y'all
16:00:08 <mattmceuen> #endmeeting