15:00:20 <mattmceuen> #startmeeting openstack-helm 15:00:21 <openstack> Meeting started Tue Mar 20 15:00:20 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:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:24 <mattmceuen> #topic rollcall 15:00:25 <openstack> The meeting name has been set to 'openstack_helm' 15:00:36 <d|k`> hihi! 15:00:39 <mattmceuen> GM! 15:00:41 <mattmceuen> Agenda: https://etherpad.openstack.org/p/openstack-helm-meeting-2018-03-20 15:00:41 <srwilkers> ¯\_(ツ)_/¯ 15:01:48 <portdirect> hello 15:01:50 <mattmceuen> giving folks 2min to join 15:01:58 * portdirect taps feet 15:02:02 <mattmceuen> GM all 15:02:08 <gmmaha> o/ 15:02:15 <eeiden> o/ 15:03:08 <mattmceuen> Here we go 15:03:27 <mattmceuen> #topic kubernetes-entrypoint enhancement 15:03:44 <mattmceuen> @seaneagan made an update to k8s entrypoint to target pods - sean, want to share? 15:04:21 <seaneagan> docs: https://github.com/stackanetes/kubernetes-entrypoint#pod kubernetes-entrypoint pull request and release: https://github.com/stackanetes/kubernetes-entrypoint/pull/31 https://github.com/stackanetes/kubernetes-entrypoint/releases/tag/v0.3.0 osh support patchsets: nova: https://review.openstack.org/#/c/552572/ neutron: https://review.openstack.org/#/c/553622/ other charts: https://review.openstack.org/#/c/55426 15:04:45 <mattmceuen> awesome, I'll add to the agenda notes 15:04:54 <portdirect> this is a big win :) 15:04:57 <portdirect> thanks seaneagan 15:05:32 <portdirect> I's love to see this for jobs as well :) 15:06:01 <mattmceuen> yes thanks seaneagan! 15:06:35 <mattmceuen> portdirect or seanegan, can you please illustrate an example cases for this work? 15:06:39 <seaneagan> np, I'll look into that as well 15:06:55 <seaneagan> The initial use case for this is to use them in conjunction with daemonset overrides, which enable overriding daemonset configuration by by node labels and/or individual hosts, via separate daemonsets for each configuration. We can thus no longer depend an individual daemonset, but instead on a pod owned by one of these daemonsets, which all share a set of labels. We chose to depend on pod labels rather than daemonse 15:07:39 <seaneagan> https://github.com/openstack/openstack-helm/blob/dbb778a7840d33ae589d4d875bb623970b449988/helm-toolkit/templates/utils/_daemonset_overrides.tpl 15:08:37 <portdirect> I'm working on a PS that i hope to have up later today that will leverage this 15:09:01 <portdirect> allowing us to have both host/label specific nova compute and neutron agent pods on a host 15:09:22 <seaneagan> (to finish my sentence): we can depend on a set of pod labels regardless of how they got there, daemonset or otherwise 15:10:01 <portdirect> the only minor issue i have with this - is we probably should have called out that it is 'pod on same host' not 'pod in cluster' 15:10:14 <portdirect> though i think seaneagan has ideas for how to handle this 15:11:17 <mattmceuen> this was a non-trivial and extremely important feature that we need for real-world use. Any questions on this topic? 15:11:57 <seaneagan> we should be able to extend "pod dependencies" by taking advantage of the extensibility of json, such as by adding a `local: <true|false>` field to take care of that 15:12:31 <portdirect> +++ 15:12:32 <mattmceuen> Want to make sure everyone is looped in on the "why" and the "how to use" -- please refer to Sean's links above if you find yourself with a dependency on something host-specific 15:12:54 <mattmceuen> neat 15:13:15 <portdirect> `extensibility of json` 15:13:19 <portdirect> qotd 15:13:44 <mattmceuen> :-D 15:14:36 <mattmceuen> portdirect, you want to discuss SRIOV support yet, or save that for next time? 15:14:47 <mattmceuen> (see I am whetting peoples' appetites) 15:14:57 <srwilkers> he does 15:15:04 <mattmceuen> #topic SRIOV Support 15:15:41 <srwilkers> he said he needs a few minutes and to come back around to it 15:16:13 <mattmceuen> deal 15:16:23 <mattmceuen> #topic Slack integration going away 15:16:35 <mattmceuen> :( 15:16:37 <mattmceuen> https://get.slack.help/hc/en-us/articles/201727913-Connect-to-Slack-over-IRC-and-XMPP 15:17:11 <mattmceuen> Slack is unfortunately deprecating the gateway functionality that facilitates Slack<->IRC mirroring, effective May 15 15:17:48 <d|k`> @slack: grrrrrrr 15:17:57 <mattmceuen> I will be posting a few messages in slack before and after the move to try to wrangle folks to IRC 15:18:23 <mattmceuen> So the question for y'all is: is it worth keeping the OSH Slack channel as a secondary chat room? 15:18:32 <mattmceuen> Pro: more newbies may run across it 15:18:44 <mattmceuen> Con: more chat room 15:20:06 <mattmceuen> I have an opinion which is informed by having more blinky lights on my computers than I can keep up with already 15:20:40 * portdirect has finished his nap 15:20:58 <mattmceuen> I propose we leave it there with a note that sets expectations, e.g. "main conversation has moved to the IRC #openstack-helm channel on freenode, please expect very delayed responses in this channel" or something 15:21:21 <portdirect> I think we should focus the slack channel on user support? and irc on dev? 15:21:39 <portdirect> or is that a horrrible idea? 15:21:41 <srwilkers> without something mirroring the chat, i think it's going to be difficult to maintain two separately. 15:21:44 <srwilkers> thats a horrible idea 15:22:14 <srwilkers> does the openstack kubernetes sig have a slack channel? i think that'd be an appropriate place to lurk if we're going to suggest having two disjoint chat rooms 15:22:21 <portdirect> wfm 15:22:24 <srwilkers> as it'd help push that initiative 15:22:35 <mattmceuen> that is a good idea 15:23:28 <mattmceuen> I'll plan to set up a note directing folks to both #openstack-helm IRC and sig-openstack slack 15:24:08 <mattmceuen> #topic The legend of SRIOV 15:24:12 <mattmceuen> portdirect take it away 15:25:15 <portdirect> so we merged this recently :) 15:25:37 <portdirect> though theres more working coming 15:26:24 <portdirect> the big hitters here were seans work, and the sr-iov agent 15:26:43 <portdirect> which introduced to neutron the ability to use multiple backends 15:27:00 <portdirect> and leveraged the conditional deps work we brought in a few weeks ago 15:27:11 <portdirect> also we are using some ubuntu:18.04 images 15:27:36 <portdirect> to let us enable promisc and trusted mode on newer nics 15:27:43 <jayahn> o/ late for the game. 15:28:03 <mattmceuen> o/ jayahn! 15:28:12 <portdirect> I'm hoping that today/tomorrow I'll have a ps up that will also let us target hosts for diff configs for all the neutron agents 15:28:30 <portdirect> though dev time has been in short supply lately ;) 15:28:39 <portdirect> think thats it 15:29:26 <jayahn> portdirect: i am pretty sure hyunsun will have her own idea on this. we let this ps merged since it seems urgent. 15:30:09 <mattmceuen> does hyunsun have a different approach to multi-backend in mind? 15:30:20 <jayahn> but hope we cloud've had more chance to discuss upfront. (that is all I heard from her. :) ) 15:30:41 <d|k`> portdirect: dumb question: is there anything nic-specific in the sriov patchset, and if so are there particular nic models it's known to work with? 15:30:44 <jayahn> not really, she has some idea on improving it as long as i know 15:31:17 <portdirect> jayahn: it was a wip for three weeks 15:31:20 <mattmceuen> Awesome, would love to discuss it - can she bring it up in the irc channel or the ML? 15:31:41 <portdirect> would have been great to have her feedback as I added her as a reviewer on the 1st ps :) 15:32:18 <portdirect> https://review.openstack.org/#/c/547890/ 15:32:38 <jayahn> it was titled with sriov, so we did not keep our eye on it first time. :) then, reallized it has more in it. 15:32:59 <mattmceuen> Would like her input in any case 15:33:08 <jayahn> sure thing. 15:33:09 <mattmceuen> Can you please share this meeting transcript with her jayahn? 15:33:13 <portdirect> d|k`: nothing nic specific really, other than 18.04 lets us use fancy new 25g nics :) 15:33:21 <mattmceuen> The background on the k8s entrypoint pod targeting will be valuable context 15:33:32 <jayahn> i will. 15:33:37 <mattmceuen> awesome 15:34:01 <d|k`> portdirect: thx. since those are prolly what i'll end up poking at it's worth knowing. 15:34:43 <mattmceuen> #topic Source code copyright attribution 15:35:30 <mattmceuen> So, we have as a somewhat historical remnant a copyright attribution of "The Openstack-Helm Authors" in the majority of our source, sometimes along with additional copyright for any code that has been comingled in our source 15:35:48 <mattmceuen> This was the approach used in the beginning as it follows common community conventions 15:36:18 <portdirect> (from when we were thinking of kube-incubator as a home for us) 15:36:31 <mattmceuen> However, the norm for official openstack projects is to assign copyright to the "OpenStack Foundation" when feasible (the Foundation itself is very flexible) 15:37:03 <mattmceuen> The biggest driver for changing is that the OpenStack Foundation is a legal entity, and the OpenStack-Helm Authors is not :) 15:38:13 <mattmceuen> Now that we are an official project, I'd like to reassign copyright to the OpenStack Foundation from the OpenStack-Helm Authors, under the merit that they're approximately the same thing, we have a more legally-grounded assignment, and we're following the conventions of core OS projects that way. 15:38:30 <portdirect> I'm happy for all work I contributed prior to 13th March 2017 under the guise of `OpenStack-Helm Authors` to be re-assigned to `OpenStack Foundation` 15:38:47 <mattmceuen> Note: that would only be a search an replace of those two terms; it would not impact any OTHER copyright in the code 15:38:51 <portdirect> after then its up to my employer to decide ;) 15:39:26 <mattmceuen> Any objections or concerns team? 15:39:54 <jayahn> nope 15:40:44 <mattmceuen> Awesome. Let's consider this the plan of record, and allow some additional time for folks to chew on it and present any other opinions. 15:41:08 <mattmceuen> #topic Senlin, Magnum, Mistral Broken 15:41:23 <mattmceuen> I didn't even realize that these three were broken, unfortunately 15:41:47 <mattmceuen> Which illustrates: these charts aren't necessarily used as heavily by as many folks in the community 15:42:43 <portdirect> I had a poke around 15:42:46 <mattmceuen> It would be great for someone to take a look at these, why they stopped functioning, and get 'em gated 15:43:05 <mattmceuen> Any insight portdirect? 15:43:08 <portdirect> and it looks like theres an issue with the messaging between the apis and engines 15:43:34 <portdirect> may be simple, or a bit more in depth to solve, ive just not had the b/w to look into it 15:43:49 <portdirect> but would be a great onboarding problem to solve 15:44:11 <mattmceuen> Agree - good opportunity to learn more of how the charts fit together 15:45:40 <mattmceuen> Any volunteers? Or is anyone aware of actual users of these charts, who might be able to help contribute to OSH? 15:46:08 <portdirect> I would like to see helm test added for each of these 15:46:19 <mattmceuen> +1 15:46:22 <portdirect> I was actually doing that when i discovered they were broken 15:46:23 <portdirect> :) 15:46:50 <portdirect> I have no immediate plans for these charts in a professional capacity 15:46:51 <mattmceuen> yeah, those are remnant of the days when we were more laisses-faire... 15:46:59 <portdirect> but would really like to see magnum working again 15:47:09 <portdirect> as it closes the loop of osh 15:47:27 <portdirect> and gives us a nice sandwich proposition to the community 15:49:30 <mattmceuen> I'll socialize some bugs for these to try to get some support from the community 15:50:09 <mattmceuen> #topic Release Schedule and rational spec (portdirect) 15:50:26 <portdirect> oh hai 15:50:56 <portdirect> so during the PTG we used a variety of props to try and hash out a release plan and rational 15:51:31 <portdirect> I was wondering if it would be helpful to translate where we ended up into a spec 15:51:52 <portdirect> if applicable i think LOCI would like to follow the same format 15:52:13 <portdirect> though that will be up to the PTL and other cores over there to decide 15:52:38 <portdirect> i could try and get something up before the next meeting 15:52:49 <portdirect> unless anyone else wanted to take this on? 15:54:05 <mattmceuen> Next week sounds like a good plan to get the spec out for our 1.0 readiness that I committed to as well :) 15:54:39 <mattmceuen> I think the release plan will be highly valuable portdirect 15:55:12 <mattmceuen> It will help illustrate the differences between OSH releases & OpenStack releases, and how they fit together 15:55:26 <jayahn> +++ 15:55:38 <portdirect> Yup - and how being release independent is the path 15:56:15 <portdirect> to openstack bliss when you are trying to provide paths from one to the other 15:56:16 <portdirect> :) 15:57:27 <mattmceuen> yikes we're running low on time 15:57:34 <mattmceuen> so much bliss this week 15:57:42 <mattmceuen> #topic topics to discuss next time 15:57:54 <mattmceuen> jayahn - log: multiline support issue 15:58:11 <jayahn> i saw some discussion on openstack-helm channel. 15:58:50 <jayahn> pls let's discuss over this week, if you can share idea on email, it would be super great for us to follow up, but, irc would be also okay. 15:58:56 <mattmceuen> I will add that one to the agenda for next time and make sure we're ready to discuss 15:59:08 <mattmceuen> perfect - will do 15:59:18 <mattmceuen> about out of time but 15:59:23 <mattmceuen> #topic Roundtable 15:59:33 <mattmceuen> jayahn added some of our talks that got accepted to our agenda https://etherpad.openstack.org/p/openstack-helm-meeting-2018-03-20 15:59:35 <mattmceuen> wooooo 15:59:55 <mattmceuen> Please add any other OSH or related talks from our team to that agenda, so we can all be aware 15:59:58 <jayahn> yeap. thanks folks for much efforts. 16:00:02 <mattmceuen> Agree! 16:00:07 <mattmceuen> #endmeeting