Wednesday, 2017-03-29

*** neiljerram has quit IRC00:17
*** apuimedo has quit IRC00:17
*** yedongcan has joined #openstack-kuryr00:40
*** apuimedo has joined #openstack-kuryr00:42
*** hongbin has quit IRC00:45
*** rubabsyed has quit IRC00:50
*** limao has joined #openstack-kuryr01:09
openstackgerritgecong proposed openstack/kuryr-libnetwork master: delete unused log translations in kuryr_libnetwork  https://review.openstack.org/45065901:29
openstackgerritgecong proposed openstack/kuryr-libnetwork master: delete unused log translations in kuryr_libnetwork  https://review.openstack.org/45065901:31
openstackgerritgecong proposed openstack/kuryr-libnetwork master: delete unused log translations in kuryr_libnetwork  https://review.openstack.org/45065901:33
openstackgerritgecong proposed openstack/kuryr-libnetwork master: delete unused log translations in kuryr_libnetwork  https://review.openstack.org/45065901:35
openstackgerritgecong proposed openstack/kuryr-libnetwork master: delete unused log translations in kuryr_libnetwork  https://review.openstack.org/45065901:45
*** limao has quit IRC01:47
*** limao has joined #openstack-kuryr01:47
*** yedongcan has quit IRC01:49
openstackgerritgecong proposed openstack/kuryr-libnetwork master: delete unused log translations in kuryr_libnetwork  https://review.openstack.org/45065901:58
*** yedongcan has joined #openstack-kuryr02:01
*** yamamoto has joined #openstack-kuryr02:29
*** yamamoto has quit IRC02:33
*** aojea has joined #openstack-kuryr02:49
*** aojea has quit IRC02:54
*** yuanying has quit IRC02:55
openstackgerritgecong proposed openstack/kuryr-libnetwork master: delete unused log translations in kuryr_libnetwork  https://review.openstack.org/45065902:59
openstackgerritgecong proposed openstack/kuryr-libnetwork master: delete unused log translations in kuryr_libnetwork  https://review.openstack.org/45065903:01
*** vikasc has joined #openstack-kuryr03:14
*** yuanying has joined #openstack-kuryr04:39
*** hlo323 has quit IRC05:09
*** vikasc has quit IRC05:17
*** vikasc has joined #openstack-kuryr05:29
*** yamamoto has joined #openstack-kuryr05:35
*** limao has quit IRC05:38
*** limao_ has joined #openstack-kuryr05:38
*** yamamoto has quit IRC05:40
*** huats has quit IRC05:56
*** ltomasbo|away is now known as ltomasbo06:03
*** pcaruana has joined #openstack-kuryr06:24
*** yamamoto has joined #openstack-kuryr06:41
*** lihi has quit IRC06:46
*** irenab has quit IRC06:46
*** yamamoto has quit IRC06:47
*** oanson has quit IRC06:48
*** yedongcan has quit IRC06:50
*** yedongcan has joined #openstack-kuryr06:52
*** yedongcan has quit IRC07:04
*** yedongcan has joined #openstack-kuryr07:05
*** aojea has joined #openstack-kuryr07:20
*** dimak has joined #openstack-kuryr07:27
*** svinota has joined #openstack-kuryr07:31
dmelladoapuimedo: ping re: packaging07:36
dmelladowe need to do some changes07:36
dmelladoxD07:36
apuimedodmellado: want to discuss them or send merge req?07:38
dmelladoapuimedo: want to discuss a few things before modifying the rdo stuff07:39
dmelladoI mean, I was asked to match the upstream repo name07:39
dmelladoi.e. kuryr and kuryr-kubernetes07:39
dmelladogthen the package names would be python-kuryr and so07:39
* dmellado will pm you07:40
apuimedook07:40
*** aojea_ has joined #openstack-kuryr07:41
*** yamamoto has joined #openstack-kuryr07:43
*** aojea has quit IRC07:44
*** yamamoto has quit IRC07:48
janonymoushongbin:hi, can i know the problem about etcd? would a check on installation will not be gud?08:00
*** svinota has quit IRC08:13
*** yuanying has quit IRC08:31
*** limao has joined #openstack-kuryr08:34
*** limao_ has quit IRC08:34
*** neiljerram has joined #openstack-kuryr08:36
*** yamamoto has joined #openstack-kuryr08:45
*** yamamoto has quit IRC08:50
*** limao has quit IRC09:04
*** limao has joined #openstack-kuryr09:05
*** egonzalez has joined #openstack-kuryr09:15
*** pmannidi has quit IRC09:16
*** yuanying has joined #openstack-kuryr09:39
*** yuanying has quit IRC09:44
janonymousirenab: hi,This patch looks a bit different from explanation in bp:  http://paste.openstack.org/show/602736/09:45
janonymousirenab: which one is better approach?09:45
*** yamamoto has joined #openstack-kuryr09:46
*** yuanying has joined #openstack-kuryr09:47
*** yamamoto has quit IRC09:52
*** ltomasbo is now known as ltomasbo|away09:55
*** limao has quit IRC10:15
*** limao has joined #openstack-kuryr10:16
*** limao has quit IRC10:20
*** yedongcan has left #openstack-kuryr10:22
*** yamamoto has joined #openstack-kuryr10:48
*** egonzalez has quit IRC10:50
*** yamamoto has quit IRC10:54
*** yamamoto has joined #openstack-kuryr11:09
*** yamamoto has quit IRC11:19
*** svinota has joined #openstack-kuryr11:35
*** ltomasbo|away is now known as ltomasbo11:42
kzaitsev_wshm. does anybody know — how does k8s allocates ips for services? It looks like kubernetes just chooses one from --service-cluster-ip-range and then asks kuryr-k8s to create one11:49
openstackgerritKirill Zaitsev proposed openstack/kuryr-kubernetes master: [WIP] K8s Services support: LoadBalancerHandler  https://review.openstack.org/37604511:52
kzaitsev_wslogic looks a bit inverted here tbh =)11:57
*** egonzalez has joined #openstack-kuryr12:07
*** limao has joined #openstack-kuryr12:17
*** yamamoto has joined #openstack-kuryr12:20
*** limao_ has joined #openstack-kuryr12:20
*** limao has quit IRC12:22
*** yamamoto has quit IRC12:25
*** janki has joined #openstack-kuryr12:27
ivc_kzaitsev_ws what do you mean by 'inverted logic'?12:33
ivc_kzaitsev_ws and yes, clusterip is selected by k8s and passed to neutron12:34
*** limao_ has quit IRC12:39
*** limao has joined #openstack-kuryr12:39
apuimedokzaitsev_ws: yes. It decides as it wants12:58
apuimedoit doesn't support external ipam :'(12:58
*** limao has quit IRC13:00
*** limao has joined #openstack-kuryr13:01
dmelladoapuimedo: too bad13:02
dmelladoI was expecting so much more from you13:02
apuimedodmellado: As wormtongue told Gandalf in the golden hall, they tell me in K8s "You have no power here, Gandalf the grey"13:04
dmelladobut I pictured you as the Evil Angmar Witch-King13:05
dmelladowell, it was either that or Gollum, but...13:05
apuimedoI see myself as a hobbit13:05
apuimedoa glutton one13:06
apuimedoivc_: well, the ideal would be to have external ipam for the services... I think mesos has that. But it's no big deal13:06
apuimedokzaitsev_ws: just remember to have the router interface on the service network on the last IP address of the range13:06
apuimedoif you have it on the first one, k8s allocates it quickly13:06
* apuimedo is ashamed. It was not wormtongue. It was Saruman through Theoden's mouth13:08
apuimedoI'll go cry at my mistake13:08
ivc_apuimedo we solved it for devstack, but i wonder how to properly handle it in prod envs13:08
ivc_apuimedo the router ip i mean13:08
apuimedoivc_: it's deployment13:08
apuimedoso for openshift, for example13:08
apuimedoI'll have openshift ansible, which uses Heat, deal with it in heat template13:08
apuimedoI suppose13:08
*** mattmceuen has joined #openstack-kuryr13:10
ivc_apuimedo yes it is deployment, but maybe we should check/validate. right now it would lead to a stack trace with something like 'ip in use' neutron exc13:11
ivc_apuimedo which is fine, but i'd prefer a better ux and us telling the user what he did wrong in log instead of stack-trace13:11
apuimedoagreed13:12
ivc_not in this patch tho XD13:12
apuimedoThis is a bug. We should at least notify that is being used by the router13:12
ivc_i wont call it a bug - its a result of misconfiguration13:13
apuimedoux bug13:14
ivc_apuimedo btw can you remind me whats our current view of using k8s third party resources?13:19
apuimedoivc_: avoid if possible. Use if it brings something worth it13:20
apuimedoits usage is not discouraged13:20
ivc_apuimedo yeah, i remember that, but whats the reasoning behind 'avoid if possible'?13:21
*** limao has quit IRC13:22
ivc_apuimedo is it only due to the k8s api not being stable yet or something else?13:22
*** yamamoto has joined #openstack-kuryr13:22
*** limao has joined #openstack-kuryr13:22
apuimedoivc_: no. It's like. If we can do things without using at no cost, we don't use it13:24
apuimedolike for example, if we said, ok, let's use it for vifs instead of annotations13:25
apuimedoI'd say it would probably be misguided13:25
dmelladoapuimedo: go cry, yep13:25
dmelladonow seriously, +1 on ivc_ suggestion13:26
apuimedodmellado: I'll take my illustrated version of the lord of the rings and beat my head with it13:26
dmelladoapuimedo: let's meet f2f, I'd love to see that13:26
dmelladoxD13:26
apuimedodmellado: you're just hurt by your deployment failure last week xD13:26
ivc_apuimedo i'd say it should be all-or-nothing - mixing them with annotations would be a mess13:26
dmelladoapuimedo: I am, totally13:26
apuimedoivc_: how so?13:27
apuimedoivc_: tbh, I've considered moving the vif creation to a scheduler extension13:27
ivc_apuimedo well say we use tpr for services and annotations for vifs - would be kinda ugly13:27
apuimedoand then it makes sense to use 3rd party13:28
*** yamamoto has quit IRC13:28
apuimedooh no, you still need to watch the pods13:28
apuimedodue to the pod deleted event13:28
ivc_yes, but it would be similar to how service-endpoints flow works now13:28
* apuimedo was thinking of reducing the events to watch by having the controller ignore pod events for a moment (when blood wasn't reaching brain)13:28
ivc_apuimedo so pod handler would only update tpr and tpr would do the actual work13:29
ivc_apuimedo thats is mostly about deletion/cleanup - we have leftovers if kuryr is down/failing during k8s object deletion13:30
apuimedoivc_: yup. You have the deletion/cleanup still13:30
apuimedohow nice would it be for tpr to have cascading :P13:31
ivc_apuimedo what do you mean by cascading?13:31
apuimedotpr linked to pod resource for example, when pod goes, tpr goes13:31
apuimedoxD13:31
apuimedobut I'm just being nonsensical13:32
ivc_no! thats exactly what we dont need :)13:32
apuimedoIt would allow us to ignore pod events13:32
apuimedowhich is a nice thing™13:32
ivc_i mean right now if we miss pod deletion event (e.g kuryr down) - we do not cleanup13:33
apuimedoright13:33
ivc_but with tpr thats not an issue13:33
ivc_if we miss pod deletion, we'll resync when processing tpr and will cleanup properly13:33
apuimedommm13:35
apuimedoyou mean with the async task?13:35
ivc_not necessary, but thats an option. can actually have it as part of handler13:36
apuimedocan you describe the flow?13:37
dmelladohow much of a delay would be that13:37
dmellado+1 on describing the flow, I'd like to understand the whole scenario13:37
ivc_i've done something like that in my early patches around september i think - had a timestamp on the object and validated it from time to time13:37
dmelladothanks in advance ivc_ ;)13:37
ivc_the flow in general would be similar to current service->endpoints handlers relationship (service sends a 'spec' to endpoints and endpoints do the dirty work)13:39
ivc_so for vifs we'll have pod handler posting 'something' spec-like to the tps13:40
ivc_tps will hold both the spec and neutron reflection of that spec (e.g VIF object)13:41
ivc_ADDED k8s event is trivial and would be same as current13:41
ivc_s/ADDED/MODIFIED/13:42
dmelladoivc_: I see, thanks for the explanation13:42
ivc_but will also have some sort of 'last_verified' timestamp13:42
*** limao has quit IRC13:43
dmelladoivc_: and how often would you be planning to validate?13:43
*** limao has joined #openstack-kuryr13:43
ivc_should be a configuration option13:44
dmelladogotcha13:44
ivc_if in addition to that we make our watcher restart from time to time (based on that validation interval) - we wont need any async tasks for cleanup13:46
* ivc_ would like to avoid adding tasks/scheduler if possible13:46
ivc_by 'watcher restart' i mean the http request, not the service13:47
ivc_this part: https://github.com/openstack/kuryr-kubernetes/blob/master/kuryr_kubernetes/k8s_client.py#L11413:48
ivc_afaik there's an argument to k8s 'watch' that allows that, but we could also implement it ourselves13:50
apuimedoI'm not sure I see enough benefit for the added roundtrips13:51
ivc_apuimedo you need those roundtrips for cleanup anyway13:52
ivc_apuimedo even with async tasks13:53
apuimedobut not for creation13:53
* apuimedo is creation obsessed13:53
ivc_creation wont necessary require any roundtrips13:53
*** svinota has quit IRC13:54
apuimedoivc_: you see pod, you create tpr, you see tpr, you create neutron resource13:55
apuimedothere's an extra roundtrip13:55
ivc_ah you mean that13:56
apuimedoyup13:58
dmelladowell, I don't think that would be *that much* extra roundtrips14:00
dmelladobut we could try to check out some another workflows14:00
ivc_well then it leaves us to prolly the only other option of tracking objects in kuryr's memory14:00
apuimedoivc_: kuryr is like me. Its memory is not trustworthy14:01
ivc_how so?14:01
*** janki has quit IRC14:02
ivc_and i did not say i'd like the 'in-memory' approach btw, cuz it prolly lead to scalability issues14:02
apuimedoah, ok14:02
*** limao has quit IRC14:04
*** limao has joined #openstack-kuryr14:05
ivc_ok lets look at it from different perspective. what i'm saying is that i'd like some sort of 'storage' for objects instead of annotations, mostly due to cleanup issues14:05
ivc_that 'storage' can be populated by watch handlers from one side and by querying (list'ing) neutron resources from the other side14:06
apuimedoI'm just missing the advantage over annotations somehow14:07
apuimedo:(14:07
ivc_cleanup is a mess with annotations14:07
apuimedoI agree with that14:07
apuimedowith tpr, you still have to go and check if the fpr exists though, for all the tprs14:08
apuimedowhen you want to cleanup orphan resources14:08
ivc_you can call 'storage' the 'resource manager' if you like14:08
apuimedoas in the pool?14:11
ivc_not exactly implementation-wise :)14:12
apuimedowell, the storage for that was agreed to be neutron/octavia14:14
apuimedowith tags and stuff like that14:14
*** dimak has quit IRC14:16
*** yamamoto has joined #openstack-kuryr14:24
*** limao has quit IRC14:25
*** limao has joined #openstack-kuryr14:26
ivc_yes but imo we need a generalised api. right now it is part of the driver and each driver has to re-implement things like 'ensure' logic14:26
ivc_so i'm suggesting the drivers to be low-level stuff (list/create/delete) and the 'ensure' logic to be composable14:27
ivc_and cleanup14:28
ivc_i'd hate if we need to implement cleanup tasks as part of the drivers14:29
*** yamamoto has quit IRC14:29
ivc_apuimedo ^14:29
ivc_apuimedo also we need to consider using iterator-based 'list', but thats another topic14:31
apuimedoivc_: it's tough to generalize14:31
apuimedosorry, I missed the reference to the new topic14:32
ivc_if you have thousands of ports, neutron list will return a huge dict that eats memory14:33
ivc_afaik there's an option to neutron client to return iterator instead (dno how it works internally) or one can use pagination14:34
apuimedooh, sure. I'd prefer that very much14:34
apuimedoI hate lists14:34
apuimedoI like generators and iterators only14:34
ivc_so that must be enforced on api level for drivers14:34
apuimedoreview enforcement or "hacking" ?14:35
ivc_hacking?14:35
apuimedoyes, some hacking rules14:35
apuimedo:P14:35
apuimedoto be enforced at PEP8 time14:35
*** ltomasbo is now known as ltomasbo|away14:36
dmelladohacking++14:36
ivc_that'd be hard to implement. more like a ResourceDriver base class with create/delete/get/__iter__ methods14:38
apuimedodmellado: you are volunteering for the hacking patch, do I get this right?14:39
dmelladolol14:39
dmelladoI can do that14:39
dmelladoyep14:39
dmelladoxD14:39
dmelladobut /me needs to go now14:39
dmelladoor I'll be left behinf14:39
apuimedovery well14:39
apuimedodon't stay in Romania14:39
apuimedocome back to the west!14:39
*** limao has quit IRC14:47
*** limao has joined #openstack-kuryr14:47
openstackgerritSiyi Luo proposed openstack/fuxi master: Use HostAddressOpt for opts that accept IP and hostnames  https://review.openstack.org/45144814:53
*** limao has quit IRC15:08
*** limao has joined #openstack-kuryr15:09
*** yamamoto has joined #openstack-kuryr15:26
*** limao has quit IRC15:29
*** limao has joined #openstack-kuryr15:30
*** yamamoto has quit IRC15:31
openstackgerritLiping Mao proposed openstack/kuryr-libnetwork master: Kuryr-libnetwork Docker managed plugin  https://review.openstack.org/44903815:32
*** limao has quit IRC15:50
*** limao has joined #openstack-kuryr15:51
*** aojea_ has quit IRC15:56
*** limao has quit IRC16:12
openstackgerritLiping Mao proposed openstack/kuryr-libnetwork master: Add NetworkDriver api AllocateNetwork and FreeNetwork  https://review.openstack.org/45147516:12
*** limao has joined #openstack-kuryr16:12
*** yamamoto has joined #openstack-kuryr16:27
*** yamamoto has quit IRC16:33
*** limao has quit IRC16:33
*** limao has joined #openstack-kuryr16:34
*** egonzalez has quit IRC16:34
openstackgerritLiping Mao proposed openstack/kuryr-libnetwork master: Update Kuryr-libnetwork Docker managed plugin related doc  https://review.openstack.org/45147916:40
openstackgerritLiping Mao proposed openstack/kuryr-libnetwork master: [WIP]Update Kuryr-libnetwork Docker managed plugin related doc  https://review.openstack.org/45147916:41
*** kzaitsev_ws has quit IRC16:44
openstackgerritLiping Mao proposed openstack/kuryr-libnetwork master: Add NetworkDriver api AllocateNetwork and FreeNetwork  https://review.openstack.org/45147516:44
*** limao has quit IRC16:55
*** svinota has joined #openstack-kuryr17:10
*** yamamoto has joined #openstack-kuryr17:29
*** yamamoto has quit IRC17:35
*** tonanhngo has joined #openstack-kuryr17:44
*** tonanhngo_ has joined #openstack-kuryr17:48
*** tonanhngo has quit IRC17:48
*** pcaruana has quit IRC17:52
*** tonanhngo_ has quit IRC17:52
*** tonanhngo has joined #openstack-kuryr17:54
*** aojea has joined #openstack-kuryr18:24
*** yamamoto has joined #openstack-kuryr18:31
*** yamamoto has quit IRC18:36
*** kzaitsev_mb has joined #openstack-kuryr18:42
*** dimak has joined #openstack-kuryr18:43
*** hongbin has joined #openstack-kuryr18:59
*** yamamoto has joined #openstack-kuryr19:32
*** openstackgerrit has quit IRC19:33
*** yamamoto has quit IRC19:38
*** alraddarla has quit IRC19:45
*** dimak has quit IRC19:51
*** mchiappero has quit IRC20:31
*** mchiappero has joined #openstack-kuryr20:33
*** yamamoto has joined #openstack-kuryr20:34
*** yamamoto has quit IRC20:40
*** mattmceuen has quit IRC21:28
*** aojea has quit IRC21:34
*** yamamoto has joined #openstack-kuryr21:36
*** kzaitsev_mb has quit IRC21:40
*** yamamoto has quit IRC21:42
*** svinota has quit IRC21:48
*** kzaitsev_mb has joined #openstack-kuryr22:11
*** alraddarla has joined #openstack-kuryr22:20
*** kzaitsev_mb has quit IRC22:24
*** yamamoto has joined #openstack-kuryr22:38
*** yamamoto has quit IRC22:42
*** kzaitsev_mb has joined #openstack-kuryr22:50
*** pmannidi has joined #openstack-kuryr23:14
*** yamamoto has joined #openstack-kuryr23:39
*** yamamoto has quit IRC23:44

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!