15:00:10 #startmeeting openstack-helm 15:00:11 Meeting started Tue Jun 25 15:00:10 2019 UTC and is due to finish in 60 minutes. The chair is portdirect. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:14 The meeting name has been set to 'openstack_helm' 15:00:23 lets give it a few mins for people to arrive 15:00:28 agenda is here: https://etherpad.openstack.org/p/openstack-helm-meeting-2019-06-25 15:00:32 #topic rollcall 15:00:33 o/ 15:00:47 o/ 15:00:50 o/ 15:00:55 hi 15:02:06 o/ 15:03:44 o/ 15:03:52 o/ 15:04:36 ok lets begin :D 15:05:18 1st its great to be back, the last couple of weeks have been hectic - so I'd really like to thank srwilkers and mattmceuen for holding the fort while i was away 15:05:25 #topic Release docs progress 15:05:38 I really owe you all an update on this 15:05:54 o/ 15:06:05 I've been working through it at a technical level, based on the conversations and notes we have taken at the various ptgs 15:06:39 of which one of the primary points i have been looking for is where osh 'breaks' 15:07:10 in that we need to make a change beyond overrides to support a particular version of openstack 15:07:34 i suspect this may be it: https://review.opendev.org/#/c/666150/ 15:08:20 though once we have a definative, it will be much easier to articulate the points around our proposed high level semver like versioning 15:08:47 and how a site would flow through both versions of osh, and versions of openstack releases 15:09:23 not really sure to understand this 15:10:25 which aspect evrardjp ? 15:10:59 I understand all the words separately, not together :) 15:11:24 Do you mean you will not come up with a release versionning plan until 66150 is resolved? 15:11:41 ah - no 15:11:48 Or do you mean that the helm charts not branched per release is problematic? 15:12:02 Because this patch doesn't introduce extra conditionals 15:12:04 i think it provides a great example of the sort of thing our release versioning needs to solve for 15:12:09 o/ 15:13:28 portdirect: I would say "yes, I agree, that's our project' scope to deal with upgrades of helm charts to deal with new openstack changes" 15:13:32 eg - to avoid a rats nest of confditionals - we may want to say, when openstack uses this version of oslo middleware (as an example) - we want to increment the Y version of osh, deprecating support for old versions of openstack etc 15:14:03 evrardjp: i think the spec will make it clearer when articulated 15:14:10 ok 15:14:31 don't forget it's not only about versions of dependencies :) 15:14:33 the point you raise is exactly what we need to cover with the stament `how a site would flow through both versions of osh, and versions of openstack releases` 15:15:03 yes, documentations and/or specs are missing in that regard 15:15:10 +1 for spec 15:15:53 will be up soo for sure 15:15:56 soon 15:16:05 k 15:16:25 the earlier it is up, the more time we have to discuss about ironing the details all together 15:16:39 another thing thats also been done to support this effort, is validation of openstack releases between ocata and rocky 15:16:43 and I am told that devil is in the details 15:16:44 :p 15:16:58 pike came in here: https://review.opendev.org/#/c/666936/ 15:17:29 and queens just needs a few things to tidy it up: https://review.opendev.org/#/c/667205/ 15:18:33 i hope to add rocky, and stein today 15:18:43 to clarify state, will the current jobs be renamed to ocata? 15:18:52 yes 15:18:58 good 15:19:27 portdirect: we don't build stein images yet 15:19:32 afaik 15:19:38 but we could very easily 15:19:45 ++ 15:19:47 if we ok to move on, i think this brings us neatly into the reworked values overrides for the gates/local dev? 15:20:01 k 15:20:10 sounds a logical next convo 15:20:17 #topic Simpler overrides 15:20:19 very cool, great to see it moving fast now portdirect! 15:20:28 I still have some questions on the etherpad, might be worth explaining there 15:20:49 so the gate over-rides functionality we had was a great leap forward for us 15:21:13 in that it opened the door to testing multiple variations of config over-rides in the gates 15:21:25 though suffered from a few issues 15:21:47 overlaps? 15:22:26 mainly that 1) it applied the over-rides ubiquitously to all charts (eg neurton over-rides applied to mariadb, or more worryingly nova), 2) was very hard to use locally for development 15:22:59 agreed. That was done in a rush because you had something to rework the gates 15:23:04 :p 15:23:24 so we worked on a bash script to allow the values args to be generated inline for chart deployment/upgrade 15:23:34 https://review.opendev.org/#/c/666958/ 15:24:28 which is more easily portable, and provides clearer feedback as to what is being applied to charts, and how people can extend that 15:24:31 eg: http://logs.openstack.org/58/666958/25/check/openstack-helm-compute-kit-rocky-opensuse_15/b23ee1e/ara-report/result/1c47ceaa-6f27-4a36-b6e5-d1f1cc67c7c9/ 15:25:21 the hardest thing here was making it work for both BSD and GNU utils ;D 15:25:33 I welcome the change generally, but I know this will break some of our toolings 15:26:20 i validated against all our gates, i hope nothing breaks - what did i miss? 15:26:26 I would have preferred to know that shell arguments would have changed 15:26:41 but it's fine, we never claimed it was a stable interface 15:27:20 it's just a surprise for me, I am just back from holidays :) 15:27:44 anyway, positive change overall, thanks for the work! :) 15:28:22 one q i have, is that i wonder if we should remove the default values for images from the charts? 15:28:41 my logic here is thus: 15:29:15 currently we have no way of validating/enforging that a particular version of openstack, or any partiuclar distro is used for deployment 15:29:24 and this would allow us to be sure of that 15:29:42 but comes with a massive downside, in that it would mean that our charts would not work 'out of the box' 15:29:56 but would need at least one set of over-rides applied to it 15:30:12 just a thought, but a conversation i think thats worth having 15:30:23 I am not fond of that approach, because it will cause so many questions 15:31:24 and also because the conversation above with releasing versions. 15:31:30 im not either :( the other thought that occured was for us to 'strip' these keys/branches out in our gates which would achive a similar effect 15:31:55 I am not really sure to understand the problem 15:32:09 you're afraid that some of the overrides wouldn't be applied? 15:32:19 more - what if we miss one 15:32:34 eg, forget to put an opensuse image in for say the keystone db sync job 15:33:26 it kinda links me to my next steps question :) 15:33:48 I thought it would be nice to remove all overrides from the shell scripts to bring them into each charts 15:34:08 currently we can only validate this by doing things like looking at the outpur here: http://logs.openstack.org/93/666193/2/check/openstack-helm-glance-rocky-opensuse_15/6e08fe3/primary/system/docker-images.txt 15:34:44 if we do so, we can have multiple files applied, and the first one could be a "gate wiper" to ensure all images are pointing to null. But that's most likely a burden to maintain 15:35:13 if its just `images: null` would be simple :D 15:35:18 i totally recognize probelm pete is saying 15:35:26 portdirect: not really 15:35:39 because when a new image is added or removed, you have to think about those overrides 15:35:53 yes! we would need to - and currently we dont 15:35:58 thats the exact point 15:36:15 the same is true of passwords etc 15:36:32 but lets stick to images for now 15:36:58 portdirect: I think all of this can be solved by the right documentation 15:37:31 and good CI-ing 15:37:34 it certainly helps - but it doesnt ensure we are validating the right stuff 15:37:49 can we have this discussion over mailing list as well? 15:37:58 jayahn: i think that would be great 15:38:22 I think it's best approach to discuss it over ML 15:38:30 +1 for those of as slow as heck today which are not understanding the issue well enough :) 15:38:34 we have very similar problem internally with a bit different use cases. 15:38:38 it impacts how OSH is consumed 15:38:44 i really want to bring this discussion to my team 15:38:48 jayahn: i suspect you are not the only ones ;) 15:38:55 portdirect: correct ;) 15:39:45 one of the pain points that ATT has consuming OSH internally is that 'default' images leak through 15:39:49 we had to make "diff function" to automatically find out if there is new images, or if we are missing any "necessary" override. 15:39:51 but I think you are pointing to multiple problems, and I think we would all benefit from splitting that into smaller chunks 15:40:00 they get through development, and then fail ci 15:40:05 (obviously) 15:40:24 it seems we all had that then 15:40:48 nice - lets take this to the ml to continue 15:41:24 one other thing i added in support of the above was getting the helm release values saved in ci: https://review.opendev.org/#/c/667178/ 15:42:16 so we can clearly see 'helms' view of the world: http://logs.openstack.org/78/667178/2/check/openstack-helm-infra-openstack-support/da1cdba/primary/helm/values/ 15:43:14 this is nice 15:43:16 very nice 15:43:26 +1 on this! 15:44:08 ok to move on? 15:44:19 I will just drop this here... 15:44:29 Maybe everything would be simpler if we used helmfile. 15:44:49 * evrardjp hides 15:45:12 or armada... 15:45:21 anyway 15:45:41 #topic meeting-time 15:45:48 ah this is me 15:45:48 mattmceuen: floor is yours 15:46:24 https://etherpad.openstack.org/p/osh-meeting-vote-2019 15:46:36 Just a reminder that we have an open vote for the time for this meeting 15:46:54 We're planning to close voting EOD today - if you have an opinion, please follow the instructions in the etherpad! 15:46:58 can we extend this vote for 1~2 days? I wrote reason in etherpad 15:47:57 mattmceuen: I don't see many core reviewers opinion there. 15:48:08 Agree, need more opinions :) 15:48:13 Not a great message :p 15:48:30 I think the message is that the core team is open to anything that facilitates the community! 15:48:30 i was confused with airship voting since mail sent out to mailing list got a wrong etherpad link. :) 15:48:36 * mattmceuen core team: prove me wrong 15:48:51 mattmceuen: wow that's awesome. 15:48:53 I've intentinally not voted - as I'll move my life around whatever the community decides 15:49:03 jayahn: sorry I have lost the etherpad, sigh 15:49:08 can you paste the reason in here 15:49:13 portdirect: this is a recipe for burnout :) 15:49:16 and I'll defer to portdirect on the timing decision 15:49:21 :( 15:49:40 one touch wrong and completely changed the meaning of my sentence! 15:49:40 there were two mails asking for vote; one for airship, one for osh 15:49:45 evrardjp: i never sleep 15:50:04 osh voting mail has etherpad link pointing to airship voting etherpad 15:50:14 oh dear 15:50:14 that got me confused, i thought i did vote 15:50:18 sorry about that 15:50:50 since we need to make sure we get everyone's vote anyway, you ok with extending a couple days portdirect? 15:50:56 and.. that was also my not-carefully-read mail problem 15:51:16 works for me mattmceuen 15:51:17 jayahn: pay attention, this channel is logged :) 15:51:25 ah.. yeap 15:51:39 ;)... 15:51:51 #action extend vote one week for meeting times 15:52:11 * jayahn now totally understand why my company sweep out my email every month. 15:52:11 well that means I have six and a half days to vote! 15:52:14 jayahn: please get your team to vote as well 15:52:22 I will 15:52:34 and samsung guys as well 15:52:43 nice - thx 15:53:18 that's all from me portdirect 15:53:48 #topic auto_bridge_add bond port support 15:53:53 cheng1: floor is yours 15:54:03 in neutron chart, we can add nic to ovs bridge according to auto_bridge_add. but we don't support adding bond to ovs bridge yet. 15:54:16 I would like to add bond support 15:54:23 https://storyboard.openstack.org/#!/story/2005946 15:54:37 sounds good to me :D 15:55:28 i think a ps, implementing that would be awesome 15:55:50 portdirect, thanks. I will create patch for this 15:55:58 nice - ok to move on? 15:56:04 another thing about ovs 15:56:16 the ovs image patch https://review.opendev.org/#/c/665310/ 15:56:35 several ovs-dpdk feature patches depends on this patch 15:56:56 as they need the dpdk-enabled ovs image. 15:57:16 Would like to get more reviews from the cores. 15:57:19 ok - so there was a q for georgk about supportability of distro packages, but if hes good with it - then lgtm 15:57:57 rihabb is trying to build bionic based images at the moment 15:58:35 let's see how that works out 15:58:53 evrardjp: you ok with waiting untill next week, or want to take your two topics to the channel? 15:59:10 the bionic upgrade is "just" a side track of the OVS activity 15:59:21 :-) 15:59:27 georgk: sounds good, look forward to seeing how this works out 15:59:56 ok - we are out of time, I'll put your items at the top of the etherpad for next week evrardjp 15:59:57 portdirect: it's feedback 16:00:03 let's move to channel 16:00:03 thanks everyone! 16:00:05 thanks! 16:00:10 thanks 16:00:11 #endmeeting openstack-helm