Thursday, 2016-11-17

*** tonanhngo has joined #openstack-kuryr00:25
*** diogogmt has joined #openstack-kuryr00:27
*** tonanhngo has quit IRC00:29
*** irenab has joined #openstack-kuryr00:32
*** david-lyle_ is now known as david-lyle00:35
*** limao has joined #openstack-kuryr00:37
*** hongbin has quit IRC00:37
*** irenab has quit IRC00:37
*** tonanhngo has joined #openstack-kuryr00:45
*** tonanhngo has quit IRC00:49
*** irenab has joined #openstack-kuryr01:27
*** irenab has quit IRC01:32
limaoping vikasc01:50
*** irenab has joined #openstack-kuryr02:21
*** irenab has quit IRC02:26
*** tonanhngo has joined #openstack-kuryr02:34
*** tonanhngo has quit IRC02:38
vikasclimao, pong03:07
limaovikasc: just want to confirm with you how did you do the devstack test?03:07
limaoI tried without neutron_plugin in local, vagrant can't enable qos03:08
limaoI also paste a doc there, please help to have a look when you have time03:09
vikasclimao, yes please share the doc03:09
vikasclimao, for my understanding i am digging into it03:10
limaohttps://www.openstack.org/assets/Uploads/QoS-Neutron-N00bie.pdf03:10
limaoP3203:10
vikasclimao, i tried yesterday without plugin but could not notice any error03:10
limaoYes, it will no error, but it will not enable qos03:10
vikasclimao, yes i can see, this document is mentioning03:10
limaocan you check the /etc/neutron/neutron.conf03:11
vikascok03:11
limaodid it enable qos service plugin?03:11
* vikasc checkoing03:11
limaohere is correct service_plugin:03:12
limaoservice_plugins = qos,neutron.services.l3_router.l3_router_plugin.L3RouterPlugin03:12
vikasclimao, there is "#service_plugins =" no service plugin at all03:16
*** irenab has joined #openstack-kuryr03:16
limaoohh... I think at least this should be l3...03:16
vikasclimao, but in screens i can see that neutron services are running fine, like q-svc and all03:16
limaoDid you use vagrant install?03:17
vikasclimao, everthing is commented in /etc/neutron/neutron.conf...03:17
vikasclimao, no vagrant03:17
vikasclimao, cloned devstack and copied localrc, and then stack.sh03:17
limaoit should be same03:17
limaoit is strange03:18
vikascyeah,03:18
vikascso you confirmed that without enabling neutron plugin, qos does not get added in neutron.conf?03:19
limaoyes, I tried03:19
vikascthen it is ok to me.. i will remove -1,03:19
limaoWell, you can try vagrant with my patch03:19
limao:)03:19
vikasc:)03:20
limaoThanks for your confirm, vikasc03:20
vikasci just wanted to confirm03:20
*** irenab has quit IRC03:20
vikascu confirmed so thank you!!!03:21
*** yedongcan has joined #openstack-kuryr03:22
vikasclimao, how devstack is running with neutron.conf totally commented still remains to be understood for me03:23
limaovikasc: yeah... at least need have mq, db info ;-)03:24
vikasclimao, yep, and on the nested_port patch of mine03:25
vikasclimao, that nested_port is vm_port and i dont think it is required in port_bind03:25
openstackgerritMerged openstack/kuryr-libnetwork: Enable neutron qos in default vagrant devstack local.conf.sample  https://review.openstack.org/39720103:25
vikasclimao, do you see a problem in that change?03:26
vikasclimao, you removed your +1 :P03:26
*** tonanhngo has joined #openstack-kuryr03:35
*** tonanhngo has quit IRC03:35
*** tonanhngo has joined #openstack-kuryr03:44
*** tonanhngo has quit IRC03:48
limaovikasc: I just want to be clear about which "port param" is for container, and if we do not use vm port in port_binding, we may remove that param. that's why remove +1 there.03:53
openstackgerritZhigang Li proposed openstack/kuryr: getting random string from neutron-lib helpers that have supported  https://review.openstack.org/39873203:55
vikasclimao, if you see veth_driver, this nested_port is not being used and veth driver is default driver..from this can we infer that 'port' param is container port. Because IP for veth is also being extracted from 'port'.03:55
vikasclimao, i would appreciate a '-1' or '+1' :)03:56
limaovikasc: yes, I think so, but toni's comments confused me "That was the intended naming indeed. nested port is the one for the container, port is the one the VM. "03:57
vikasclimao,  i asked apuimedo yesterday, lets request again today to clarify.03:58
limaovikasc : Yeah, if here is clear, this patch +1 from my point of view. (maybe need another follow up patch to remove nested_port if no need to use in bind_port)03:59
vikasclimao, or if we all agrees that nested-port is not needed, i would update same patch to remove it04:01
limaovikasc: yeah, agree04:02
vikasclimao, lets discuss with apuimedo04:02
limaosure :-)04:02
janonymousHello, can some core members can have a look on https://review.openstack.org/#/q/status:open+project:openstack/kuryr-libnetwork+branch:master+topic:bp/drop-mox , to avoid merge conflicts and rebases04:19
openstackgerritZhigang Li proposed openstack/kuryr: getting random string from neutron-lib helpers that have supported  https://review.openstack.org/39873204:24
*** tonanhngo has joined #openstack-kuryr04:55
*** tonanhngo has quit IRC04:56
yedongcanlimao: ping05:06
limaoyedongcan: hello05:06
yedongcanDo you still working on this patch: https://review.openstack.org/#/c/387835/ ?05:08
*** irenab has joined #openstack-kuryr05:09
limaoyedongcan: yeah, stopped for some time... ut need to fix in my mind05:09
limaoyedongcan: so you want to do something related?05:10
yedongcanlimao: Ok, I look it just now. The cause it we're missing subnet_pool_name in Docker option05:11
yedongcans/it/is05:12
yedongcanlimao: So we're missing subnetpool_id in create subnet05:13
limaoyedongcan : If we create a kuryr network, it will create a subnetpool and subnet, right?05:13
*** irenab has quit IRC05:14
yedongcanlimao: Yes, but we can't get subnetpool_id, if we are not passing subnet pool name.05:14
yedongcanlimao: I had a related patch can fix it, https://review.openstack.org/#/c/373977/405:15
limaoyedongcan: cool , let me check there05:15
yedongcanlimao: Thanks, but I had already forgot why I changed this at the end, I need to look in detail.05:17
limaoyedongcan: if we do not assign pool_name in option, we can find the pool_id from pool_cidr .05:20
yedongcanlimao: Yes05:21
limaoyedongcan: In this case, the subnet can still get the right subnetpool id05:21
yedongcanlimao: Right.05:22
limaoyedongcan: thanks for your reminder, I will update the patch today or tomorrow05:23
yedongcanlimao: OK, thanks.05:25
*** irenab has joined #openstack-kuryr06:03
openstackgerritDongcan Ye proposed openstack/kuryr-libnetwork: Update neutron-lib and import_exceptions  https://review.openstack.org/39875606:04
*** limao has quit IRC06:06
*** irenab has quit IRC06:08
*** limao has joined #openstack-kuryr06:08
*** tonanhngo has joined #openstack-kuryr06:08
*** tonanhngo has quit IRC06:13
*** irenab has joined #openstack-kuryr06:31
*** yedongcan has quit IRC06:47
*** irenab_ has joined #openstack-kuryr06:58
*** irenab_ has quit IRC07:02
*** yedongcan has joined #openstack-kuryr07:04
openstackgerritZhigang Li proposed openstack/kuryr: getting random string from neutron-lib helpers that have supported  https://review.openstack.org/39873207:12
openstackgerritZhigang Li proposed openstack/kuryr: getting random string from neutron-lib helpers that have supported  https://review.openstack.org/39873207:29
*** oanson has joined #openstack-kuryr07:33
*** tonanhngo has joined #openstack-kuryr07:35
*** tonanhngo has quit IRC07:39
openstackgerritDongcan Ye proposed openstack/kuryr-libnetwork: Using import_exceptions from kuryr-lib  https://review.openstack.org/39875607:48
*** irenab_ has joined #openstack-kuryr07:52
*** irenab_ has quit IRC07:56
ivc_irenab, vikasc, i've replied to your comments on https://review.openstack.org/#/c/398324/208:05
vikascthanks ivc_ , will take a look08:07
*** dimak has joined #openstack-kuryr08:12
ivc_irenab, do we really need a TODO for unit tests if we already have one for the tested module? imo that only adds confusion (i.e. consider that someone reads the note in test module and tries to move the unit tests without moving the module itself). and there is no way that we move the os_vif_utils without updating the tests accordingly as the tests would simply fail without the module itself08:12
irenabivc_, I think you can also leave it as is, its just more handy if soemone else will update it later08:13
ivc_irenab, its a trivial change and i don't mind adding a note tbh. just wanted to share my opinion that i consider it redundant :)08:16
irenabivc_, can you please share your approach for the drivers granularity, I am not sure I got your idea correct08:17
ivc_sure08:17
ivc_we'll have ProjectDriver(s) to take care of multitenancy in the future. or we could implement a driver that would take a project_id from some source other than the config file (e.g. annotation or etcd)08:18
ivc_then we have SubnetDriver that does the same for subnets08:18
ivc_then we have SecurityGroupsDriver(s)08:19
ivc_for the same reason08:19
*** gsagie has joined #openstack-kuryr08:19
ivc_then there would be VIFDriver that would be slightly different and will deal with different deployment options (i.e. one for bare-metal and another for container-in-vm)08:20
apuimedomorning all08:20
ivc_apuimedo, hey toni :)08:20
apuimedoI would need to know who would be able to attend the Atlanta PTG08:21
apuimedoivc_: irenab: vikasc: janonymous: limao: yedongcan: ltomasbo:08:21
apuimedoto decide if we book a space or not08:21
apuimedootherwise we'll try to make some virtual one08:22
irenabapuimedo, +1 on virtuyal one08:22
limaoapuimedo: currently, I do not have plan08:22
gsagieirenab: :) you need a trip..08:22
* vikasc reading back08:22
ivc_as part of VIFDriver i'll probably make some sort of NeutronToVIFConverter (it would not be in controller.drivers) to deal with 'bridge', 'ovs' and other vif types in os_vif_utils (it would serve the same role as https://github.com/openstack/nova/blob/master/nova/network/os_vif_util.py#L362, but would make it possible to have out-of-tree projects to provide their own drivers, think 'midokura' or smth)08:22
*** yuval has joined #openstack-kuryr08:23
irenabgsagie, nice to hear from you08:23
vikascneither me08:23
ivc_apuimedo, +1 on virtual too08:23
vikasc+! for virtual one08:24
irenabgsagie, planning to go to PTG?08:24
vikasc+108:24
gsagieirenab: only if you come :)08:24
apuimedoalright then. I'll make it a virtual one08:24
irenabgsagie, join us on the virtual one08:24
apuimedobut there'll be presentations and schedule nonetheless08:24
apuimedo;-)08:24
irenabapuimedo, I could consider BCN :-)08:24
apuimedoirenab: my doors are always open to kuryr contributors08:25
apuimedoI have some bunk beds08:25
apuimedo:P08:25
vikascsuper08:25
vikasc:)08:25
gsagieapuimedo: watch out with what you promise... ;)08:25
gsagieI really liked the casino in Barcelona08:25
irenabgsagie, apuimedo needs babysitters08:25
vikasc:D08:26
vikascthats the hidden plan08:26
apuimedogsagie: you'd still be 40min away from barcelona08:26
apuimedoirenab: you got that right08:26
apuimedoit's the fee08:26
irenab:-)08:27
yuvalgsagie: galllllllll08:28
gsagieyuvalllllll08:29
irenabivc_, reading the explanation08:29
yuvalgsagie: :)08:29
ivc_irenab, the idea is to make it possible to combine different drivers without tightly coupling them08:30
limaoBTW,08:30
limaoapuimedo : If you need a webex meeting for virtual meeting , I can offer  (It can free call back audio)08:31
irenabivc_, so your idea is that there is driver per neutron entity that should be managed?08:31
ivc_irenab, sort of08:32
irenabivc_, lets say there is Pod creation via k8s api, what will be the workflow to reflect it in neutron?08:33
ivc_irenab, take PodSubnetDriver for example. it takes pod object. there will also be a ServiceSubnet driver that takes service08:33
irenabivc_, so it k8s object_neutro object drivers08:34
ivc_irenab, VIFHandler takes care of managing neutron resources for Pod creation08:34
irenabivc_, sorry, still do not see the whole picture ... VIFHandler is for the local stuff, isn't it?08:35
ivc_irenab, i'll update VIFHandler patch to use drivers instead of _* methods08:35
ivc_irenab, what do you mean by 'local stuff'?08:35
irenabworker node bindings08:35
*** reedip has quit IRC08:36
ivc_no VIFHandler is for the controller. it takes care of managing neutron resources and updates pod annotation with VIF object that is later used for binding on worker nodes08:36
apuimedoI was gonna use bluejeans08:36
irenabivc_, maybe the name (VIF) is a bit misleading08:38
janonymousapuimedo: +1 for both options :)08:38
*** reedip has joined #openstack-kuryr08:38
irenabapuimedo, as long as no travel involved, any options is fine08:38
ivc_irenab, but it is what it does - it defines the os-vif VIF object08:38
ivc_irenab, and it is the controller-side part of VIF binding process08:39
irenabivc_, what would you have for Service creation?08:39
vikascivc_, but it handles pod create events08:39
vikascivc_, cant it be named PodCreateHandler08:39
vikascivc_, or PodHandler08:39
ivc_vikasc, no. because we can have some other PodHandler that does something completely different than managing VIFs/ports08:40
ivc_vikasc, irenab, i originally named it PodPortHandler, but since for the outside world it creates the VIF annotation and Neutron port is just an implementation detail, i've renamed it to VIFHandler08:41
irenabivc_, so what you have in mind is that the Handler named upon what it responsible to create?08:42
ivc_irenab, aye08:43
irenabso the ServiceHandler will be actually LoadBalancerHandler?08:43
ivc_i guess so08:43
irenabivc_, sorry, just trying to understant the intention08:43
ivc_irenab, well at some point we decided that it would be nice to have multiple handlers for the same event, right?08:44
ivc_so e.g. for pod.ADDED we have one that takes care of networking08:44
ivc_but then there were plans to do something for volumes08:45
ivc_so naming it PodHandler does not feel right imo08:45
*** irenab_ has joined #openstack-kuryr08:46
ivc_and we have OBJECT_KIND = 'Pod' that makes it clear what sort of object it handles08:46
irenabivc_, I agree on the last statement, just not sure if the 'end result' naming is the way to go, it makes me more confused08:46
irenabivc_,  but I like the 'miscroservice' like apprpach08:47
ivc_irenab, thats probably because you got used to midokura's poc approach :)08:47
irenabivc_, 'deeply involved' :-)08:47
vikascivc_, makes sense08:48
ivc_vikasc, thnx :)08:48
irenabivc_, but seriously, I am missing the overall design approach understanding08:48
vikascivc_, thanks to you !!08:48
vikasc:)08:48
vikascirenab, ivc_ i am also not clear.. trying to undrstand just by reviewing patches08:49
irenabivc_,  maybe you can push devref with the general idea, so we can start explore for next constructs08:49
irenaband be more helpful on reviews08:49
ivc_irenab, vikasc, well i'd be happy to clarify08:49
irenablets say I am about to add support for k8s net policy08:50
irenabwould it be SGHandler?08:50
*** irenab_ has quit IRC08:50
irenabor it will use SGDriver?08:50
ivc_irenab, the problem is that this thing is evolving as it goes. think agile rather than waterfall :) i only came with that 'driver' approach like last week08:51
ivc_irenab, SGDriver08:51
ivc_it will be used by VIFHandler08:51
vikascivc_, we would be happy to maintain devref also in agile approach :)08:51
irenabivc_, I am all into agile approach, but some fundamental principals should be in place :-), can be refactored of course08:51
vikascivc_, atleast with some minimum placeholders08:52
vikascivc_, and then everybody from the team will keep updating as per evolution and understanding and you will be there to clarify08:53
vikascivc_, s/placeholders/headings08:54
ivc_irenab, vikasc, well i totally agree that we need a devref08:56
ivc_i've even started one here: https://review.openstack.org/#/c/369105/08:56
ivc_but its outdated08:56
ivc_and incomplete08:57
ivc_and tbh i'm not sure what exactly needs to be explained (i.e. what questions do you have and what is not clear from code)08:58
irenabivc_, can you please update there the Handler/Driver approach as you now taking?08:58
vikascthat may help some other new developers as well08:59
irenabvikasc, +108:59
vikascbeginners08:59
vikascand then they will also be able to help08:59
irenabivc_, lets say someone is about to add support for k8s net policy, so it will help to understand that pices to add or to integrate with09:00
irenabs/pices/parts09:00
ivc_irenab, the problem is there's nothing to integrate with now09:00
irenabivc_, design wise09:00
ivc_irenab, can we turn it into some sort of Q&A? i honestly can't predict what needs to be explained09:02
irenabivc_, sure, let take the agile approach and improve as we go09:03
ivc_and then there's another problem that writing a devref takes tons of time (at least for me) and i sort of have a deadline to implement vif and lbaas (pod/service) handling09:03
ivc_and that deadline is pretty close09:03
vikasc:)09:03
vikasccool09:04
*** yuval has left #openstack-kuryr09:04
irenabivc_, for me the sw workflow you have in mind for Pod/Service creation will be enough to be more helpful on reviewing09:05
vikascivc_, please keep updating patches09:05
ivc_irenab, 'sw workflow'?09:06
irenabivc_, sequence of calls09:06
irenabivc_,  I can help with devref if you wish09:07
ivc_irenab, that'd be awesome :)09:07
vikascgreat09:07
irenabivc_, but I have to understand what you have in mind :-)09:07
ivc_irenab, sure :)09:08
*** garyloug has joined #openstack-kuryr09:33
openstackgerritAntoni Segura Puimedon proposed openstack/kuryr-kubernetes: devstack: make cni paths configurable  https://review.openstack.org/39611309:35
apuimedovikasc: ^^09:36
vikascapuimedo, can you please review my patches09:40
*** irenab_ has joined #openstack-kuryr09:40
apuimedovikasc: I will09:40
vikascapuimedo, https://review.openstack.org/#/c/397057/ i dont this nested_port(which is vm-port IMO) is needed in port_bind.09:41
apuimedovikasc: can you apply the change I ask in https://review.openstack.org/#/c/397057/209:42
ivc_vikasc, apuimedo, wait! xD09:42
apuimedovikasc: rename it to vmport09:42
apuimedoivc_: ?09:42
ivc_dont merge loopback.conf :)09:43
ivc_i'm writing a comment09:43
ivc_done :)09:43
vikascapuimedo, why do we need vm-port in port-bind?09:43
*** yedongcan has quit IRC09:44
*** irenab_ has quit IRC09:45
*** yedongcan has joined #openstack-kuryr09:45
apuimedovikasc: to, for instance, find the device which the port should be linked to09:47
apuimedoif you have the vmport info you can match by UP09:47
apuimedo*IP09:47
vikascapuimedo, that info will be needed in kuryr-libnetwork or kuryr-kubernetes controller i think09:48
*** openstackgerrit has quit IRC09:48
vikascapuimedo, which driver will use this?09:48
*** openstackgerrit has joined #openstack-kuryr09:48
apuimedoivc_: that's an interesting comment. I saw some examples with multiple conf for multiple drivers. I'll check the code to make sure the documentation is up to date09:49
vikascapuimedo, currently no driver seem to be using it09:49
ivc_apuimedo, ok09:49
*** yedongcan has quit IRC09:49
apuimedovikasc: no driver is using this because we hardcode or have it configurable in kuryr.conf (something like bindinglink09:49
apuimedobinding_link_device)09:49
*** yedongcan has joined #openstack-kuryr09:50
apuimedoivc_: hyperkube official image does have two configs09:52
apuimedo99-loopback.conf09:52
apuimedoand09:52
apuimedo10-containernet.conf09:53
ivc_apuimedo, i like that 10-/99- approach09:53
ivc_even if it will never read loopback.conf, we make the order explicit09:53
apuimedoivc_: and it does look at all the conf files09:54
apuimedoah no, sorry09:55
apuimedothere is a return09:55
apuimedothis darned habit of putting returns instead of breaks...09:55
ivc_apuimedo, then it'll need some selector to pick the right driver09:55
ivc_which is not there (yet)09:55
apuimedoin pkg/kubelet/network/cni/cni.go:11209:55
apuimedoit does return after the first valid entry09:55
apuimedoso I say we keep both, but with the 10- 99- approach09:56
ivc_apuimedo, i think they'll eventually add an option like --cni-driver or something09:56
ivc_aye09:56
apuimedovery well09:56
apuimedoI'll update the patch09:56
*** lmdaly has joined #openstack-kuryr09:56
*** garyloug has quit IRC09:56
ivc_right now its just pure luck our project name starts with "K" :)09:56
apuimedo:P09:57
apuimedoit's not luck, it is destiny09:57
ivc_haha, i guess you envisioned that problem when you were considering the name :)09:58
apuimedoxD09:58
openstackgerritAntoni Segura Puimedon proposed openstack/kuryr-kubernetes: devstack: make cni paths configurable  https://review.openstack.org/39611310:02
apuimedoivc_: there10:02
apuimedovikasc: ^^10:02
vikascapuimedo, so intention to passing vmport in port_bind is that some coe might pass vm_port instead of mentioning in config file?10:02
ivc_apuimedo, thnx10:02
apuimedovikasc: right10:02
apuimedoit is a nullable parameter10:02
vikascapuimedo, or even in kuryr-libnetwork  eventually we will be able to skip config file part10:02
apuimedoexactly10:03
apuimedoif we can do without config, better10:03
vikascapuimedo, yep, cool10:03
ivc_apuimedo, https://review.openstack.org/#/c/396113/3/devstack/plugin.sh@27510:04
ivc_does it work as you expected now without "/" between ${KURYR_HOME}${kubelet_plugin_dir}10:05
apuimedoheh. It won't10:05
apuimedoI was now restacking10:05
apuimedoxD10:05
ivc_also10:05
ivc_you state in commit message it is /opt/stack/cni/bin10:06
ivc_but it is not :P10:06
ivc_i was too fast about +1 xD10:06
apuimedoivc_: the one we use in devstack is /opt/stack/cni/bin10:06
ivc_s@/opt/stack/cni/bin@/opt/stack/cni/conf@10:07
apuimedoCNI_CONF_DIR10:07
openstackgerritAntoni Segura Puimedon proposed openstack/kuryr-kubernetes: devstack: make cni paths configurable  https://review.openstack.org/39611310:08
ivc_right, my bad10:08
apuimedoivc_: https://review.openstack.org/#/c/396113/3..4/devstack/plugin.sh10:08
apuimedothat was the mistake. Well spotted10:08
* apuimedo restacking10:08
ivc_apuimedo, i wonder if we can have some tests to validate devstack setup on gates10:14
ivc_not in this patch ofc10:14
openstackgerritIlya Chukhnakov proposed openstack/kuryr-kubernetes: Default pod subnet driver and os-vif utils  https://review.openstack.org/39832410:17
ivc_vikasc, irenab, ^^ https://review.openstack.org/#/c/398324/2..3 updated commit message and todo for tests10:18
*** yedongcan has quit IRC10:20
vikascivc_, thanks !!10:21
apuimedoivc_: yes. We should10:22
*** limao has quit IRC10:24
*** yedongcan has joined #openstack-kuryr10:24
openstackgerritvikas choudhary proposed openstack/kuryr: Fix container port ipaddress setting in ipvlan/macvlan drivers  https://review.openstack.org/39705710:29
openstackgerritAntoni Segura Puimedon proposed openstack/kuryr-kubernetes: devstack: make cni paths configurable  https://review.openstack.org/39611310:30
*** yedongcan has left #openstack-kuryr10:38
ivc_vikasc, i've noticed your request about config.py tests in some of my patchsets. do you mind if we add unit tests for config.py in a later patch after VIFHandler? or do you want it asap (then we need another patch that would add the testing facility and rebase everything on it)?10:39
vikascivc_, i am fine either way.. may be we can open a bug for the sake of tracking10:41
vikascivc_, in case you prefer in a later patch10:41
ivc_vikasc, i'd prefer a bug. it would be a low-hanging-fruit one and might attract some other contributors :)10:44
ivc_vikasc, my point is that it is non-essential and if we add it as a dependency for the drivers/VIFHandler it does not help us merging those - and i want them done asap along with the CNI driver so ppl can actually run our devstack setup10:48
vikascivc_, sounds reasonable10:49
ivc_https://bugs.launchpad.net/kuryr-kubernetes/+bug/1640446 - here's an example of the problem that we have now10:50
openstackLaunchpad bug 1640446 in kuryr-kubernetes "Kuryr-kubernetes services throws Dummy exception while creating a POD" [Undecided,In progress] - Assigned to Ilya Chukhnakov (ichukhnakov)10:50
*** gsagie has quit IRC11:14
*** lmdaly has quit IRC11:15
*** irenab_ has joined #openstack-kuryr11:28
*** irenab_ has quit IRC11:33
*** garyloug has joined #openstack-kuryr11:54
*** reedip has quit IRC12:19
*** irenab_ has joined #openstack-kuryr12:22
apuimedoivc_: we can mark it as closed, not a bug, since with dummy it is expected12:23
ivc_apuimedo, i don't mind and it was my first intention to do so12:25
apuimedo;-)12:25
ivc_but it's getting fixed by the linked patch so i thought it would make sense to close it 'properly' :)12:27
*** irenab_ has quit IRC12:27
* ivc_ hates 'not-a-bug' resolutions12:27
*** reedip has joined #openstack-kuryr12:31
openstackgerritGary Loughnane proposed openstack/kuryr-libnetwork: Fix default subnetpool assignmens from config file  https://review.openstack.org/39764012:31
*** garyloug has quit IRC13:16
*** irenab_ has joined #openstack-kuryr13:17
*** lmdaly has joined #openstack-kuryr13:20
*** irenab_ has quit IRC13:21
*** lmdaly has quit IRC13:21
*** lmdaly has joined #openstack-kuryr13:21
apuimedoivc_: agreed13:26
*** lmdaly has quit IRC13:26
*** lmdaly has joined #openstack-kuryr13:27
openstackgerritvikas choudhary proposed openstack/kuryr: Fix container port ipaddress setting in ipvlan/macvlan drivers  https://review.openstack.org/39705713:30
*** limao has joined #openstack-kuryr13:56
*** diogogmt has quit IRC13:58
*** irenab has quit IRC14:09
*** irenab has joined #openstack-kuryr14:11
*** oanson has quit IRC14:13
*** irenab has quit IRC14:15
*** janonymous has quit IRC14:34
*** limao has quit IRC14:47
openstackgerritOpenStack Proposal Bot proposed openstack/kuryr-libnetwork: Updated from global requirements  https://review.openstack.org/35197615:01
*** yamamoto has joined #openstack-kuryr15:03
*** irenab has joined #openstack-kuryr15:05
*** hongbin has joined #openstack-kuryr15:08
*** irenab has quit IRC15:09
*** garyloug has joined #openstack-kuryr15:12
*** janki has joined #openstack-kuryr15:22
*** diogogmt has joined #openstack-kuryr15:46
*** janonymous has joined #openstack-kuryr16:07
*** yamamoto has quit IRC16:34
*** yamamoto has joined #openstack-kuryr16:43
*** tonanhngo has joined #openstack-kuryr16:46
*** dimak has quit IRC16:46
*** yamamoto has quit IRC16:48
*** garyloug has quit IRC17:03
*** janki has quit IRC17:04
*** tonanhngo has quit IRC17:27
*** lmdaly has quit IRC17:46
*** tonanhngo has joined #openstack-kuryr18:07
*** tonanhngo_ has joined #openstack-kuryr18:10
*** tonanhngo_ has quit IRC18:11
*** tonanhngo has quit IRC18:11
*** tonanhngo has joined #openstack-kuryr18:11
*** yamamoto has joined #openstack-kuryr18:13
*** tonanhngo has quit IRC18:13
*** tonanhngo has joined #openstack-kuryr18:15
*** tonanhngo has quit IRC18:17
*** yamamoto has quit IRC18:19
*** irenab has joined #openstack-kuryr18:25
*** irenab has quit IRC18:29
*** diogogmt has quit IRC18:55
*** diogogmt has joined #openstack-kuryr18:57
*** irenab has joined #openstack-kuryr18:58
*** diogogmt has quit IRC19:02
*** irenab has quit IRC19:03
*** dimak has joined #openstack-kuryr19:19
*** tonanhngo has joined #openstack-kuryr19:19
*** dimak_ has joined #openstack-kuryr19:37
*** dimak_ has quit IRC19:39
*** openstackgerrit has quit IRC19:48
*** openstackgerrit has joined #openstack-kuryr19:48
*** irenab has joined #openstack-kuryr19:52
*** irenab has quit IRC19:57
*** irenab has joined #openstack-kuryr20:03
*** irenab has quit IRC20:07
*** irenab has joined #openstack-kuryr20:48
*** irenab has quit IRC20:52
*** dimak has quit IRC21:30
*** irenab has joined #openstack-kuryr21:41
*** irenab has quit IRC21:46
*** irenab has joined #openstack-kuryr22:36
*** irenab has quit IRC22:40
openstackgerritHongbin Lu proposed openstack/fuxi: Fix the .gitignore file  https://review.openstack.org/39928222:41
*** irenab has joined #openstack-kuryr23:30
*** irenab has quit IRC23:34
*** irenab has joined #openstack-kuryr23:35
*** irenab has quit IRC23:40
openstackgerritHongbin Lu proposed openstack/fuxi: Add cffi to requirement.txt  https://review.openstack.org/39929523:42
openstackgerritHongbin Lu proposed openstack/fuxi: [WIP] Fix the installation guide  https://review.openstack.org/39929623:45
*** hongbin has quit IRC23:46

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