14:00:54 <dmellado> #startmeeting kuryr 14:00:56 <openstack> Meeting started Mon Oct 1 14:00:54 2018 UTC and is due to finish in 60 minutes. The chair is dmellado. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:59 <openstack> The meeting name has been set to 'kuryr' 14:01:08 <dmellado> Who's around here today? ;) 14:01:13 <ltomasbo> o/ 14:01:19 <aperevalov> o/ 14:01:33 <celebdor> dmellado: tell me? 14:01:39 <celebdor> oh, you start early 14:01:48 <celebdor> I didn't hear the town bell yet 14:02:37 <dmellado> I guess they made it a fake one so kids go to school without complaining 14:02:45 <dmellado> #chair celebdor ltomasbo 14:02:46 <openstack> Current chairs: celebdor dmellado ltomasbo 14:02:51 <dmellado> hi aperevalov 14:02:54 <dmellado> dulek: around? 14:03:06 <dulek> Yup! Hello! 14:03:09 <dmellado> I kinda recall that you said you had something to discuss today at the meeting 14:03:12 <dmellado> so I'll let you start 14:03:14 <dmellado> ;) 14:03:20 <dmellado> #chair dulek 14:03:21 <openstack> Current chairs: celebdor dmellado dulek ltomasbo 14:03:37 <dulek> Ah, right. Just a second, need to recall this. :P 14:04:02 <dulek> Right, gate consolidation. 14:04:41 <dulek> So I don't see a point in having separated ingress and namespace and port pools gates. 14:05:05 <dulek> IMO we should start enabling some of those features on the regular gates. 14:05:19 <dmellado> +1, they have been around for a while 14:05:19 <aperevalov_> hi, I was disconnected from IRC server 14:05:23 <ltomasbo> +1 (though for the pools, they needed to run it sequential 14:05:26 <dmellado> and should now be considered as deafault 14:05:33 <dulek> ltomasbo: Ah, you're right. 14:05:37 <dmellado> ltomasbo: we can keep that one split 14:05:44 <aperevalov_> are there any questions to me 14:05:47 <dulek> Like - ingress and namespaces separation should run on regular OpenShift job. 14:06:05 <ltomasbo> dulek, but, with the namespace feature, there is actaully no need for the sequential gate 14:06:31 <ltomasbo> dulek, so, adjusting the test, there should be no problem on consolidating it 14:07:20 <dmellado> so we can just make a specific ggate for pools 14:07:23 <dulek> ltomasbo: That's my point. 14:07:26 <dmellado> but keeping the another ones just sane 14:07:32 <dmellado> +1, let's address this 14:07:52 <dulek> So if no one is opposed to this I'll start looking at that. 14:08:51 <dmellado> dulek: awesome, thanks 14:09:08 <dmellado> #TODO: dulek to start consolidating the upstream gates 14:09:31 <dmellado> dulek: feel free pinging me if you need help on $topic 14:09:31 <dulek> #action dulek to start consolidating the upstream gates. 14:09:43 <dmellado> oh, action instead of todo 14:09:55 <dmellado> s/s anyways 14:09:58 <dmellado> cool 14:10:04 <dmellado> dulek: anything else from your side? 14:10:19 <dulek> Nope. 14:11:14 <ltomasbo> dmellado, dulek I remember we also discussed about removing non-daemonized cni code 14:11:51 <dmellado> ltomasbo: like dropping it as well? 14:11:55 <dulek> Right… I was a bit undecided here due to misunderstanding the OpenStack policy. 14:12:03 <dulek> Like the deprecation policy. 14:12:16 <dulek> But turns out we're okay to remove it as it was deprecated a while ago. 14:12:17 <dmellado> shouldn't we have to keep it like for this release at least? 14:13:06 <dulek> dmellado: "At the very minimum the feature (or API, or configuration option) should be marked deprecated (and still be supported) in the next stable release branch, and for at least three months linear time." 14:13:18 <dmellado> oh, then we're fine 14:13:25 <dmellado> I was thinking about double the time 14:13:26 <dmellado> cool! 14:13:29 <dulek> So IMO we're fine. :) 14:13:45 <dulek> Yup, so that's something I'll try to do as well. 14:14:05 <dmellado> dulek: just create a gerrit topic 14:14:07 <ltomasbo> that means we are also fine dropping lbaasv2 suuport? 14:14:09 <dmellado> so we can follow this 14:14:24 <dmellado> ltomasbo: I guess so, we'll keep them only on stable branches 14:14:32 <dulek> ltomasbo: Had we deprecated it like, officially? :P 14:14:42 <celebdor> :O 14:14:47 * celebdor loves dropping code 14:14:47 <dmellado> neutron has 14:14:48 <ltomasbo> dulek, I think that dmellado did a while ago (not sure if 3 months or not) 14:14:54 <celebdor> have my axe 14:14:58 <dmellado> I don't recall exactly when 14:14:59 <ltomasbo> lol 14:15:04 <dmellado> but let's say we're fine in time 14:15:06 <dmellado> xD 14:15:16 <dmellado> I'll send an email about these actions 14:15:19 <dmellado> so dulek 14:15:24 <dmellado> burn 'em with fire 14:15:45 <dulek> dmellado: In case of lbaas v2 it's a bit more difficult. 14:15:55 <dmellado> let's see 14:15:58 <dulek> Do we leave our python-neutronclient hack? 14:16:02 <dmellado> neutron dropped that quite a while ago 14:16:06 <dulek> Or do we move to python-octaviaclient? 14:16:09 <dmellado> and I'd say we can substitute that 14:16:11 <dmellado> with requests 14:16:24 <dmellado> celebdor: weren't you on that? 14:16:26 <dmellado> ^^ 14:16:55 <dmellado> I mean, I'd really love not having any additional dependencies into out codebase 14:18:04 <dulek> Yeah, agreed. So I'll take a look on removing lbaas v2 code, but won't rewrite it to requests immediately. :P 14:18:15 <dmellado> lol 14:18:17 <celebdor> I was 14:18:22 <dmellado> fair enough dulek 14:18:23 <celebdor> and I said no to python-octaviaclient 14:18:24 <dmellado> xD 14:18:26 <celebdor> requests all the way 14:19:44 <dmellado> all right, we got a deal 14:19:47 <dmellado> what else around 14:19:49 <dmellado> oh, yeah, 14:20:01 <dmellado> did you see the open bug against us? I was discussing with the infra folks 14:20:36 <dmellado> #link https://bugs.launchpad.net/kuryr-kubernetes/+bug/1795067 14:20:36 <openstack> Launchpad bug 1795067 in kuryr-kubernetes "screen-kubelet.txt is causing logstash index OOM errors" [Undecided,New] 14:20:51 <dmellado> basically this means that due to OOM errors 14:21:02 <dmellado> the infra folks will no longer keep track of kubelet logs on e-r 14:21:16 <dmellado> not that it would be a great requested use for us 14:21:25 <dulek> Hah, cool. 14:21:28 <dmellado> as there's no **** way we'll rewrite this in oslo-log format 14:21:47 <dulek> dmellado: Can't we just set different format in kubernetes? 14:22:07 <dmellado> we can take a look at that, don't really know if it'd help that much, though 14:22:25 <dmellado> basically they expect 14:22:27 <dmellado> oslo-log formatting 14:22:40 <dmellado> and I'm not sure whether we can tweak k8s to handle that 14:23:08 <dmellado> even if so, I don't see that much gain from having e-r on hyperkube services, tbh 14:23:18 <ltomasbo> dmellado, dulek: can we add something similar to what dulek did with the pods, so taht we store that information in a different folder? 14:23:28 <dulek> dmellado: Yeah, I don't think I've used graphana lately. :P 14:23:53 <dulek> ltomasbo: Not really. I mean blacklisting from indexing isn't too much of an issue. 14:24:01 <celebdor> lol what? 14:24:25 <dmellado> dulek: exactly, so at least from my side is a matter of bandwidth 14:24:25 <dulek> But having that file in oslo.log format would be nice - logs will get nicely formatted and timestamped. 14:24:50 <dmellado> ltomasbo: they will get stored 14:24:56 <dmellado> and you'll see them on the infra runs 14:25:01 <dmellado> just e-r won't be available 14:25:09 <ltomasbo> ahh, ok ok 14:25:11 <dmellado> so yeah, forget about grafana (in case you ever used it) 14:25:13 <ltomasbo> then I don't care! 14:25:13 <dmellado> xD 14:25:36 <dmellado> dulek: if you want to take a quick look fine 14:25:41 <dmellado> just don't spend too much time on it 14:25:52 <dulek> dmellado: Sure! 14:26:13 <dmellado> ok, so anyone else 14:26:25 <dmellado> celebdor: aperevalov_? 14:26:31 <celebdor> nothing 14:27:05 <aperevalov_> not, so much to say. Finally Dan reviewed my patch for k8s. 14:27:21 <dmellado> aperevalov_: oh, great to hear! 14:27:33 <dmellado> then let's get back to the kuryr channel in any case 14:27:35 <aperevalov_> also we almost finished our deployment tasks, so soon our collegues will be able to verify SR-IOV patches 14:27:36 <dmellado> thanks all for coming! 14:27:50 <dmellado> aperevalov_: please ping me when you reach that phase 14:28:10 <aperevalov_> dmellado: ok 14:28:54 <dmellado> #endmeeting