15:00:05 <srwilkers> #startmeeting openstack-helm 15:00:05 <openstack> Meeting started Tue Aug 1 15:00:05 2017 UTC and is due to finish in 60 minutes. The chair is srwilkers. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:09 <openstack> The meeting name has been set to 'openstack_helm' 15:00:14 <korzen> hello 15:00:21 <srwilkers> hello everyone o/ 15:00:26 <alraddarla> o/ 15:00:46 <srwilkers> got the link out late -- here's the etherpad for today. let's take about 5 minutes and add any agenda items we'd like to discuss today: https://etherpad.openstack.org/p/openstack-helm-meeting-2017-08-01 15:01:29 <lrensing> o/ 15:01:30 <jayahn> o/ 15:05:10 <srwilkers> nice :) let's get to it then 15:05:20 <srwilkers> #topic release schedule 15:05:26 <srwilkers> v1k0d3n: floors yours 15:07:19 <srwilkers> portdirect: ill defer to you since i've seen you've left comments here 15:07:27 <v1k0d3n> hey all o/ 15:07:33 <srwilkers> hey dude :) 15:07:35 <srwilkers> floors yours 15:07:38 <v1k0d3n> crazy morning, sorry for being late. 15:07:40 <portdirect> oh - its started -lol 15:07:55 <v1k0d3n> so i see that this is a topic at PTG too... 15:08:09 <v1k0d3n> but can we at least get the ball rolling a bit on RC releases? 15:08:35 <portdirect> I think we need to define what we mean by a release 15:08:39 <portdirect> and what that entails 15:08:52 <portdirect> from my perspective there are two criteria: 15:08:57 <portdirect> 1) we work :D 15:09:34 <v1k0d3n> it would help first with point in time releases, and it would also help with getting vendors involved...because they can reliably say "use this rc release with our code". contrail is a good example of this, who is currently using tiller v2.4.2. as we keep moving forward...they are left behind, and this can be frustrating. 15:09:36 <portdirect> 2) we are locking in a version of our format/layout of charts 15:09:59 <portdirect> v1k0d3n: they are using tiller 2.5 on their master 15:10:16 <portdirect> i"ll push them to update their public code 15:10:18 <v1k0d3n> yes...working is good. i think identifying _what_ works is good enough for RC releases though. and of course documenting what we know _doesn't_ work. 15:10:22 <v1k0d3n> would that be ok? 15:10:51 <v1k0d3n> i thought i was using master when attempting to package. i will check again. 15:11:08 <v1k0d3n> i am starting to work with them here as well. also folks on the ODL side. 15:11:27 <v1k0d3n> thanks for the extra push portdirect :) 15:11:39 <portdirect> nice - we have a bm lab that we are working with juniper here 15:11:40 <v1k0d3n> but would RC releases be acceptable for the team? 15:12:02 <v1k0d3n> under the conditions that we document what does/doesn't work for that RC? 15:12:05 <portdirect> I'd be more comfortble defining the criteria for a release before pushing for one 15:12:16 <portdirect> can we make this a topic at ptg 15:12:18 <jayahn> +1 on portdirect 15:12:25 <srwilkers> there are some things that need tied up before i think setting releases is appropriate 15:12:53 <v1k0d3n> that works too. but to be fair, we've had a few releases that were mostly working at one point...and ever really branched/tagged anything. it would be nice to capture those when we hit a milestone. 15:13:05 <portdirect> currently master always works :D 15:13:28 <v1k0d3n> with conditions ;) 15:13:30 <jayahn> should make that way. :D 15:14:16 <jayahn> i also would like to discuss what "dependencies" we would like to present with our release/tag policy. for exmpale, openstack version info. 15:14:25 <portdirect> if you were abloe to start working n the code again v1k0d3n it would be awesome - would help us get there quicker 15:14:28 <portdirect> *able 15:14:50 <v1k0d3n> as a user explores openstack-helm...there's no real snapshot view of what works and what doesn't. 15:15:11 <v1k0d3n> i am trying portdirect. changing jobs is pretty....disruptive. :) 15:15:25 <v1k0d3n> so, i guess no on the RC releases is what i'm hearing. 15:15:55 <v1k0d3n> which is fine...but how do we proceed. what is expected or what is the schedule, besides AT&T's 1710 and 1802? 15:15:55 <srwilkers> i think it'd be appropriate to discuss this more in detail during the PTG -- i think timeboxing that decision to part of a weekly meeting is difficult 15:16:11 <korzen> in order to reliably release anything, the gates and functional tests should be improved 15:16:54 <korzen> to make sure that ceph, ingress or any OpenStack project is working correctly 15:17:28 <v1k0d3n> ok, well i guess it will have to wait until PTG. 15:18:44 <srwilkers> any other points of discussion here? 15:19:43 <srwilkers> #topic list of reviews 15:19:51 <srwilkers> korzen: floors yours to start :) 15:20:18 <korzen> ok, so I like I have told you last meeting 15:20:33 <korzen> I have prepared the specs for the Neutron multi-SDN approach 15:20:51 <korzen> I would like to have some review there 15:21:01 <korzen> if everybody is on the same page 15:21:19 <srwilkers> korzen: glanced at it this morning. looking good :) 15:21:19 <korzen> there are general approach captured: 15:21:37 <korzen> #link https://review.openstack.org/#/c/487427/1 spec: Neutron multiple SDNs design 15:21:53 <korzen> #link https://review.openstack.org/#/c/489580/2 spec: Add linux bridge to Neutron chart 15:22:06 <korzen> as well as detailed implementation: 15:22:14 <korzen> #link https://review.openstack.org/#/c/481225 Neutron: Enable decomposition of chart into descrete manifests 15:22:30 <korzen> #link https://review.openstack.org/#/c/466293/14 Neutron: add linuxbridge daemonset and config script 15:22:33 <korzen> for those specs 15:22:41 <korzen> so you can take a look at general idea 15:22:50 <korzen> as well as the implementation details 15:22:56 <portdirect> I need to review the working of the 1st two - but am totally happy with the direction. 15:23:15 <portdirect> we should get infra to provide another three node gate for lb 15:23:20 <portdirect> and reture the two node i think 15:23:26 <portdirect> *retire 15:23:32 <srwilkers> yeah, two node can go as far as im concerned 15:23:47 <korzen> thanks jayahn for updating the SONA chart 15:23:59 <korzen> #link https://review.openstack.org/#/c/489500/ SONA 15:24:13 <korzen> in that link, you can see how external SDN integration would look like 15:24:16 <jayahn> not me, it is siri. :) 15:24:24 <portdirect> ^^ lets get that in the gate too :) 15:24:41 <portdirect> as without its hard for many people to review 15:25:10 <korzen> yes 15:25:10 <srwilkers> +1 15:25:12 <jayahn> any thing we need to follow up to do "lets get that in the gate too"? 15:25:13 <korzen> and the docs 15:25:58 <korzen> #link https://review.openstack.org/#/c/470326 15:25:58 <korzen> docs: Neutron multiple SDN approach design 15:26:10 <portdirect> jayahn: i'll ask for a three node for osh infra as well 15:26:11 <korzen> this is my old documentation around 15:26:49 <korzen> I would need to rewrite it 15:27:15 <korzen> and it should contain the overall information about networking inside OSH 15:27:17 <portdirect> korzen: if you could that would be awesome - thanks for really moving this forward 15:28:08 <srwilkers> korzen: nice 15:28:40 <korzen> ok, I guess I'm doen here 15:28:42 <korzen> done* 15:28:55 <korzen> really hoping for the review 15:28:57 <korzen> :) 15:29:04 <srwilkers> any other review related topics from anyone? 15:29:24 <korzen> I do not see dulek around, but his fernet tokens? 15:30:22 <korzen> #link https://review.openstack.org/#/c/463730/ 15:30:23 <korzen> Add support for Keystone's fernet tokens 15:31:54 <portdirect> I kinda dropped the ball there 15:32:01 <portdirect> really want it 15:32:08 <portdirect> but also want it in the gate properly 15:32:31 <portdirect> if dulek could add support and the docs for cron jobs then we should merge asap 15:32:45 <portdirect> but I'll try to find a window to complete my ps there 15:32:51 <korzen> ok 15:33:14 <portdirect> https://review.openstack.org/#/c/484958/ 15:33:34 <portdirect> though if anyone wanted to take that over I'd be greatful :) 15:35:06 <srwilkers> #topic open discussion 15:35:18 <srwilkers> any other topics not listed to cover? 15:36:29 <jayahn> not from me 15:36:53 <jayahn> ah. 15:37:07 <jayahn> one question about liveness check 15:37:26 <jayahn> what is the current status on implementing liveness check? 15:38:13 <jayahn> for each service? i was following up, then it seems like ended with "we need operator feedback on this". correct? 15:39:15 <srwilkers> i think the takeaway was that we'd tie that in to some of the prometheus work that was targeted 15:42:37 <srwilkers> anything else? 15:43:51 <korzen> we agreed that the liveness should be reproted via log analyzing 15:44:03 <korzen> thus the work on LMA 15:44:28 <srwilkers> yep. there's been some feedback left on the LMA spec in flight. I'll get that updated accordingly today 15:44:51 <jayahn> setting up liveness probe on each pod, that should be reported via log analyzing? 15:45:41 <korzen> we have the first idea that we should check DB connection, rabbitmq 15:45:59 <korzen> and service reporting in the server, like nova-manage service list 15:46:10 <korzen> as liveness check 15:46:57 <korzen> but then the conclusion was, if service is not able to connect to the DB/rabbit/nova api - can we restart the pod and expect to fix the situation? 15:47:55 <korzen> so second idea is to report that some service has issues as alarms 15:48:31 <jayahn> okay, i got the idea on how discussion went. :) I will also think about this more. 15:48:48 <portdirect> yeah its a tricky one 15:48:48 <srwilkers> yeah, feedback would be awesome. :) can adjust as necessary 15:48:53 <jayahn> can be very service / case specific. 15:49:03 <portdirect> personally I'm very worried about restarting the pod if a dep goes down 15:49:18 <portdirect> as I have nightmares of a situation cascading out of control 15:49:27 <lrensing> ++ portdirect 15:49:28 <portdirect> in the event of a small outage of say rabbitmq 15:49:33 <lrensing> domino effect 15:49:37 <korzen> true 15:50:54 <jayahn> yeah, true. 15:51:07 <korzen> so we are currently working on LMA infra 15:51:13 <korzen> prometheus, fluentd 15:51:28 <korzen> to be able to support such use-case 15:54:08 <jayahn> okay, we can end this one now, only 7min left. obviously, this requires more thinking. 15:54:24 <srwilkers> sounds good :) 15:55:26 <srwilkers> ill go ahead and close out the meeting. we can carry over any remaining conversation to openstack-helm. see you there :) 15:55:29 <srwilkers> #endmeeting