15:00:11 #startmeeting openstack-helm 15:00:12 Meeting started Tue Feb 20 15:00:11 2018 UTC and is due to finish in 60 minutes. The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:15 The meeting name has been set to 'openstack_helm' 15:00:26 #topic Rollcall 15:00:29 hihi! 15:00:38 Agenda: https://etherpad.openstack.org/p/openstack-helm-meeting-2018-02-20 15:00:42 GM d|k ! 15:01:03 Please add anything you'd like to discuss today to the agenda 15:01:37 o/ 15:02:20 hey jayahn! 15:02:38 hey 15:02:59 We are missing some of the usual suspects, let me run around and throw things at some of them 15:03:40 * srwilkers is a missing usual suspect 15:03:41 o/ 15:03:51 can confirm, mattmceuen throws things 15:04:36 ok here we go 15:04:41 if you're missing 'em, try leading the target with your throw. 15:04:53 tell them I even left in the middle of "drinking party" because of this meeting. 15:05:10 o/ 15:05:10 oh man - jayahn why even leave 15:05:22 for irc meeting!! 15:05:27 (officially) 15:05:28 multitasking : D 15:05:41 #topic Ratify Mascot-Elect Ratel 15:06:02 o/ 15:06:10 topic says it all - the Ratel has dominated the polls. Ratified? 15:06:51 rather, any challenges? 15:07:08 o/ 15:07:09 going once 15:07:15 going twice 15:07:15 done. 15:07:19 badgerified. 15:07:19 more done. 15:07:26 badgerified. 15:07:41 Thanks guys - I can't wait to see the stickers :) 15:08:03 Let me get this next topic out of the way quick 15:08:10 #topic PTG 15:08:19 o/ 15:08:32 Here's the etherpad agenda for out PTG sessions -- https://etherpad.openstack.org/p/openstack-helm-ptg-rocky 15:08:43 Reminder to get anything we want to discuss in person on the etherpad 15:08:59 Also, team photo will be at 11:40 on Thursday 15:09:08 so we can get lunch right after! 15:09:13 :( 15:09:20 portdirect: :( 15:09:41 i will be sure to take a rather large copy of the unicorn picture to hold up with us 15:09:47 so you'll still be part of the picture 15:10:00 "i believe" 15:10:17 I vote we put portdirect's face on the unicorn 15:10:24 I'm leaning toward skipping team meeting next week due to PTG, any objections? 15:10:45 then let's make it happen. just need large copy of the unicorn picture? 15:11:14 no objection 15:11:52 Cool beans. portdirect will be representing us at the Helm Summit this week, so he'll have to get a team picture of just him and a bunch of unicorns. 15:12:12 #topic Full values YAML ordering example 15:12:19 Thanks for putting this together srwilkers 15:12:25 https://review.openstack.org/#/c/543991/ prometheus as example 15:12:40 Let us take a moment to observe the YAML in the wild 15:12:56 no problem -- there are a few instances where i see full ordering potentially being an issue 15:13:28 particularly in cases where we define configuration files in the values.yaml when the configuration entries are expected to be in specific order 15:13:49 services like prometheus, fluentd, and fluentbit being the obvious examples 15:13:51 grafana too 15:13:51 urg 15:14:03 bad applications. 15:14:48 I think the best 1st step would be to neaten up the yaml 15:14:58 line 686 makes me so sad 15:15:09 I won't lie it's a little ugly 15:15:51 yeah, it's not pretty 15:16:03 but it's much better than when rules were defined in gotpl instead of yaml 15:16:16 Right off the bat, dependencies and conditional_dependencies are far apart 15:16:20 ive been working to make the prometheus rules more granular and neaten them up a little bit separately 15:16:29 but that's a separate issue than addressing this 15:16:30 I'll have a look at the deps 15:16:48 one (probably totally minor) issue i have with this is that it seems nice to me to have images: at the very start of the values file. i dunno if i can make an argument beyond aesthetics for that. 15:16:51 as id like to expand that - as we support more nova/cinder/neutron backends 15:17:16 another approach would be to write a spec 15:17:20 for the layout 15:17:29 as i though this would be the simplest way 15:17:40 i think a spec might be the right approach here, and to agree to something we then enforce 15:17:42 but i wonder if the spec apprach may have merrit? 15:17:49 im leaning yes 15:17:55 i like that. if not a spec, at least a style guide. 15:18:02 im also leaning yes 15:18:09 Yeah, or a spec moving to a style guide even 15:18:10 as i started to be unhappy with the result halfway through working on prometheus's values 15:18:12 jayahn: would one of your team be able to take this on? 15:18:45 good question (meaning I need some time to think) 15:19:02 if it can happen after ptg, yes 15:19:24 Let's discuss approaches at the PTG, at this point I think spec will be a mechanism to discuss different approaches to standard style. 15:19:37 If we can keep talking about it, maybe we can get more direction for the spec first, agree? 15:20:37 works for me 15:20:46 cool 15:21:49 #topic PS needing eyes and reviews 15:21:53 What we got! 15:22:18 just rebased it to resolve merge conflict 15:22:30 srwilkers gave +2 before :) 15:22:43 thanks srwilkers! 15:22:43 https://review.openstack.org/#/c/538419/ >> Add template for Fluent logging index 15:22:52 np 15:23:57 srwilkers: thanks for quickly review another one on updating fluent-bit version 15:24:52 not a problem 15:25:36 Any other PS y'all have been waiting on revies for, or recent ones we should get ahead of? 15:26:01 I'll have one in today i hope for porting the image registry to osh 15:26:18 https://review.openstack.org/#/c/546005/ this one should be quick 15:26:19 and the one to abstract ingress rules finished 15:27:09 also over the next few days... 15:27:13 ...ocata gates 15:27:21 yeah!!! 15:27:23 Boom. 15:27:25 ocata gate 15:27:26 we will enter the victorian era 15:27:28 Looking forward to those :) 15:27:48 let's start working on pike right away. :) 15:27:57 haha 15:28:10 we will get there sooner than later 15:28:10 jayahn: we will be :) 15:28:16 once this is finished: https://review.openstack.org/#/c/545599/ 15:28:23 I's like to do that 15:28:32 then add gates that migrate from n-1 to 1 15:29:06 Any other PS before we move on? 15:29:08 hyunsun is eager to have ocata to remove WIP from her two PS 15:29:29 Her changes are compatible with newton, right? 15:30:06 we'll still want our version 1.0 to be compatible with Newton & Ocata per what we've discussed in the past (which is something to discuss further on PTG agenda) 15:30:15 as long as i know, nope 15:30:55 i was going to tell that last time. there are things in ocata that not in newton. 15:31:41 Sure - it's ok not to take advantage of Ocata features in Newton 15:32:06 But we want the same OSH code base to support Ocata and Newton, even if it involves overriding certain manifests to not get rendered 15:32:34 When we add Ocata gates, we'll still have the Newton gates ensuring Newton functionality 15:33:51 Can you check w/ hyunsun and double check on whether the PS as is would support that? 15:34:14 if not - I can draft a spec for how to handle these cases 15:34:56 I think a spec would be good so we can ratify a single approach for handling these things 15:35:02 https://review.openstack.org/#/c/522162/ 15:35:14 https://review.openstack.org/#/c/545743/ 15:36:12 +1 on a spec 15:36:36 ties into defining and communicating our versioning strategy -- i.e. how developers contribute into it right 15:38:04 Ok last thing -- jayahn added some good and detailed thoughts on improving team collab across time zones 15:38:05 we don't have versioning strategy yet. so, do you propose making spec doc on defining versioning strategy? 15:38:08 #topic Future Topics 15:38:27 jayahn, do we want to discuss that now, or shall we all look @ it, chew on it, and discuss next time? 15:38:36 https://etherpad.openstack.org/p/openstack-helm-meeting-2018-02-20 15:38:45 chew it and discuss on ptg. 15:38:52 Sounds like a plan :) 15:39:01 I can make a draft spec for us to chew in dublin 15:39:04 but, basically, i start to have concern on this stuff 15:39:33 and imo, it needs to be discussed, agreed, and resolved 15:39:42 to make osh better community. 15:39:44 ++ 15:40:43 yes, agree 100% 15:40:52 thanks for bringing it up jayahn 15:41:10 #topic Roundtable discussion 15:41:26 Anything else we'd like to discuss this time team? 15:42:08 going once :) 15:42:12 going twice 15:42:16 in skt, we are getting a commit per an hour, and deploy the entire openstack, and test it against our value overrides. After this test passed, we merge that commit into our repo. that gives us to chance each single change from upstream 15:42:18 ah.. 15:42:20 twice 15:42:39 we didn't make it to three, you're good 15:42:49 if it fails test, we have a chnace to see what exact commit is breaking us. even jira ticket is automattically generated. :) 15:43:03 that's awesome 15:43:06 nice 15:43:18 that give us good chance to read changes, and we often get ideas from that on what is happening on upstream 15:43:49 but, this "getting know what is happening" should be done in upstream community very well. 15:44:26 that probably requires both att and skt, and other participants of this community look back how we work, and examine it, and improve it. 15:44:33 (am i making sence?) 15:45:16 that is all :) 15:45:18 Yes, it does 15:45:28 that is a good topic to dig into 15:45:38 The CI is cool on its own though :) 15:45:41 Thanks jay 15:46:02 alright guys, with that - we get 15 minutes back! Jayahn, go back to your party 15:46:04 no problem 15:46:09 its helpful, but it's hard to really diagnose these sorts of issues if what we're running in the gate differs significantly from the stuff you're running i think 15:46:14 especially if the versions are different 15:46:17 nope. my party is 40 min away from here. 15:46:29 but definitely think we should discuss this more in dublin 15:46:34 Agree 15:46:55 I think the most prudent way to resolve any delta would be to add a third party gate 15:47:04 unless the run time is too long 15:47:26 and it would be great to get some more reviews/contributions from parties using osh :) 15:47:47 i think a third party gate would help immensely 15:48:35 Thanks everyone -- see some of you at the PTG! 15:48:38 #endmeeting