| *** limao has joined #openstack-kuryr | 00:46 | |
| openstackgerrit | Liping Mao proposed openstack/kuryr-libnetwork: kuryr-libnetwork rally test job error log https://review.openstack.org/399950 | 00:57 |
|---|---|---|
| *** tonanhngo has joined #openstack-kuryr | 01:13 | |
| *** tonanhngo has quit IRC | 01:16 | |
| *** yedongcan has joined #openstack-kuryr | 01:41 | |
| *** tonanhngo has joined #openstack-kuryr | 02:11 | |
| *** tonanhngo has quit IRC | 02:12 | |
| janonymous | yedongcan: ping | 02:52 |
| yedongcan | janonymous: pong | 02:56 |
| *** tonanhngo has joined #openstack-kuryr | 02:57 | |
| yedongcan | janonymous: Hi, are you planning to rebase your mock test code? | 02:58 |
| *** tonanhngo has quit IRC | 02:58 | |
| *** tonanhngo has joined #openstack-kuryr | 03:03 | |
| *** tonanhngo has quit IRC | 03:07 | |
| *** limao_ has joined #openstack-kuryr | 03:10 | |
| *** limao has quit IRC | 03:13 | |
| janonymous | yedongcan: yeah | 03:17 |
| janonymous | yedongcan: i was thinking to do one by one to avoid merge conflicts... | 03:18 |
| yedongcan | janonymous: Thanks, I see that most conflicts are caused by generate uuid. | 03:38 |
| janonymous | yedongcan: yes :( | 03:41 |
| *** yamamoto_ has joined #openstack-kuryr | 04:05 | |
| *** yuanying has quit IRC | 04:57 | |
| *** janki has joined #openstack-kuryr | 05:21 | |
| *** shashank_hegde has joined #openstack-kuryr | 05:32 | |
| *** shashank_hegde has quit IRC | 05:40 | |
| *** shashank_hegde has joined #openstack-kuryr | 05:42 | |
| *** tonanhngo has joined #openstack-kuryr | 05:43 | |
| *** tonanhngo has quit IRC | 05:45 | |
| *** yedongcan has quit IRC | 05:49 | |
| *** yuanying has joined #openstack-kuryr | 06:02 | |
| *** yedongcan has joined #openstack-kuryr | 06:02 | |
| *** yedongcan1 has joined #openstack-kuryr | 06:20 | |
| *** yedongcan has quit IRC | 06:22 | |
| *** yedongcan1 has quit IRC | 06:40 | |
| *** oanson has joined #openstack-kuryr | 07:00 | |
| *** pmannidi has quit IRC | 07:01 | |
| *** yuanying has quit IRC | 07:04 | |
| *** yamamoto_ has quit IRC | 07:11 | |
| *** yedongcan has joined #openstack-kuryr | 07:19 | |
| *** irenab has quit IRC | 07:46 | |
| *** irenab has joined #openstack-kuryr | 07:47 | |
| *** janki is now known as janki|lunch | 07:49 | |
| *** irenab has quit IRC | 07:55 | |
| *** yamamoto_ has joined #openstack-kuryr | 07:55 | |
| *** irenab has joined #openstack-kuryr | 07:55 | |
| *** yedongcan has quit IRC | 08:00 | |
| *** dimak has joined #openstack-kuryr | 08:02 | |
| *** tonanhngo has joined #openstack-kuryr | 08:02 | |
| *** tonanhngo has quit IRC | 08:04 | |
| *** irenab has quit IRC | 08:12 | |
| *** irenab has joined #openstack-kuryr | 08:13 | |
| openstackgerrit | Merged openstack/fuxi: Update flake8 ignore list https://review.openstack.org/378250 | 08:14 |
| openstackgerrit | Merged openstack/fuxi: Add py34 for fuxi test https://review.openstack.org/393347 | 08:23 |
| *** yedongcan has joined #openstack-kuryr | 08:31 | |
| *** shashank_hegde has quit IRC | 08:37 | |
| *** shashank_hegde has joined #openstack-kuryr | 08:37 | |
| *** shashank_hegde has quit IRC | 08:44 | |
| *** shashank_hegde has joined #openstack-kuryr | 08:46 | |
| openstackgerrit | Merged openstack/fuxi: Fix typos in rootwrap.conf https://review.openstack.org/373585 | 08:48 |
| openstackgerrit | Merged openstack/fuxi: Show team and repo badges on README https://review.openstack.org/402538 | 08:52 |
| *** shashank_hegde has quit IRC | 08:55 | |
| *** apuimedo has quit IRC | 08:55 | |
| *** gsagie has joined #openstack-kuryr | 08:55 | |
| *** apuimedo has joined #openstack-kuryr | 08:55 | |
| apuimedo | vikasc: did you find out what's the problem with the config? | 09:02 |
| vikasc | apuimedo, yes, and pushed fix as well | 09:03 |
| vikasc | apuimedo, https://review.openstack.org/#/c/403325/ | 09:03 |
| openstackgerrit | Merged openstack/kuryr: Show team and repo badges on README https://review.openstack.org/402539 | 09:04 |
| vikasc | apuimedo, in server.py controller's import happens before config file is read | 09:04 |
| apuimedo | heh... That's what I said on Friday :P | 09:04 |
| vikasc | apuimedo, this issue was noticed before split as well but then got missed somewhere :) | 09:04 |
| apuimedo | but I got the place wrong | 09:04 |
| apuimedo | :-) | 09:04 |
| vikasc | apuimedo, yep, you suggested import order in controllers.py | 09:05 |
| vikasc | apuimedo, and i tried to address your concern about import fail if binding driver is not configurd vlan on vlan driver patch | 09:06 |
| apuimedo | ok | 09:06 |
| apuimedo | vikasc: I saw irenab minused it | 09:06 |
| vikasc | apuimedo, yeah, irenab raised concern on that, so i tried to explain | 09:07 |
| vikasc | limao_, "I mean if you do not seperate the them, when you just want to initial the vlan ids cache, you will aslo allocate one free vlan from them." | 09:09 |
| limao_ | vikasc: hi | 09:09 |
| vikasc | limao_, sorry, i could not get your comment, would you mind please rewording it | 09:09 |
| irenab | vikasc: sorry for not following your intention on this patch. I just want to keep code as much as possible close for future modifications, so since we already have drivers model, I do not think the manager should have if/else per driver type | 09:09 |
| limao_ | vikasc: I'm thinking this case: if kuryr-libnetwork is rebooted, coe(kuryr-libnetwork) need to re-initial the available_local_vlans in SegmentationDriver, how do you do this? | 09:11 |
| limao_ | vikasc: if you call allocate_segmentation_id, it can initial the available_local_vlans, but it will also allocate one more vlan in this function. | 09:12 |
| vikasc | limao_, PTAL https://review.openstack.org/#/c/402462/ | 09:13 |
| vikasc | limao_, this is kuryr-libnetwork side work by ltomasbo | 09:13 |
| vikasc | limao_, SegmentationDriver is imported in controllers.py, so available_local_vlans will get initialised soon after kuryr-libnetwork is up | 09:14 |
| ltomasbo | limao_, yes, I included a check_for_vlan_ids function wheb kuryr-libnetwork is rebooted | 09:18 |
| ltomasbo | so that the already used vlan ids are passed to segmentationDriver functions | 09:18 |
| limao_ | ltomasbo: vikasc: yeah, reading that part, thanks :) | 09:19 |
| ltomasbo | great! :D | 09:19 |
| vikasc | limao_, :) | 09:19 |
| ltomasbo | reviews on the patch are welcomed! | 09:19 |
| vikasc | irenab, thinking on hw can i make it better | 09:20 |
| limao_ | ltomasbo: vikasc: I think the action should be in initial phase, not in ipam_request_address | 09:21 |
| irenab | vikasc: you should get the SegDriver created only when required | 09:22 |
| limao_ | ltomasbo: vikasc: Think about the case which I mentioned, if we restart kuryr-libnetwork, then delete a existed container, the available_local_vlans has not initial in this case(I see it is initial in ipam_request_address) | 09:22 |
| ltomasbo | in ipan_request_address we call the get_segmentation_ids | 09:24 |
| *** lmdaly has joined #openstack-kuryr | 09:24 | |
| ltomasbo | but the port_vlan_dic is initialized when the kuryr-libnetwork is rebooted | 09:24 |
| *** janki|lunch is now known as janki | 09:24 | |
| ltomasbo | so, it should have all the vlan ids being used at the reboot, right? | 09:24 |
| limao_ | ltomasbo: _get_segmentation_id will also pass the vlan ids into SegmentationDriver | 09:25 |
| ltomasbo | yes, the current set | 09:25 |
| limao_ | ltomasbo: oh, it may not have impact... (if available_local_vlans in SegmentationDriver is out of date) , you have latest in port_vlan_dic | 09:27 |
| ltomasbo | but yes, we can change the SegmentationDriver so that it gets initialized with a current set, without returning a vlan id (when kuryr-libnetwork is rebooted) | 09:27 |
| ltomasbo | and then no need to sent the current set | 09:27 |
| ltomasbo | yes, the idea is that you always have port_vlan_dic with the latest one | 09:28 |
| limao_ | ltomasbo: yes, that is what I mean, I think maybe seperate init and allocate vlan id will be better | 09:28 |
| irenab | ltomasbo: I wonder if we need to keep nested case handling on the top Controller level | 09:28 |
| ltomasbo | irenab: what do you propose instead? | 09:29 |
| irenab | we have drivers model, but still keep patching the code with if/else driver_type is XXX | 09:29 |
| limao_ | vikasc: ltomasbo: but it depend on you, currently is also ok. For me, if seperate, it will be more clear :-) | 09:29 |
| irenab | ltomasbo: there are number of alternatives, for example you can have deafault Noop driver | 09:30 |
| irenab | ltomasbo: you can subclass Controller for nested case | 09:31 |
| ltomasbo | actually, I think controller.py is getting too big and it could be good to split it to keep concepts clearer | 09:32 |
| irenab | and also keep in mind that bare metal libnetwork support can be used with neutron before trunck port API was added | 09:32 |
| irenab | ltomasbo: I agree. Maybe worth to subclass or delegate nested case handling to some sort of ‘handler’ of the controller | 09:35 |
| vikasc | limao_, " I think maybe seperate init and allocate vlan id will be better" . As I understand, init is already seperate from allocate_vlan_ids, i still dont get your point :) | 09:36 |
| limao_ | vikasc: the initial here means initial available_local_vlans in SegmentationDriver | 09:37 |
| ltomasbo | irenab: I'll think about how to better do it, but please do leave a comment about it on the patch, so that other can also see/comment on it | 09:38 |
| limao_ | vikasc: we can only initial it by call "allocate_segmentation_id" right now, but if you call it, you will also allocate one vlan. | 09:38 |
| vikasc | limao_, its not the case | 09:38 |
| irenab | ltomasbo: sure | 09:39 |
| vikasc | limao_, just by "rom kuryr.lib import segmentation_type_drivers as seg_driver" initialisation is done. | 09:40 |
| vikasc | limao_, no need to call "allocate_segmentation_id" to initializee vlan ids | 09:40 |
| limao_ | vikasc: but at that time the vlan id in segmentation_type_drivers may be not right | 09:41 |
| vikasc | limao_, or you meant something else? | 09:41 |
| vikasc | limao_, why/when vlan id will not be right? | 09:42 |
| limao_ | vikasc: the right allocated_ids is passed into segmentation_type_drivers at the first time when you call "allocate_segmentation_id", right? | 09:42 |
| * vikasc rading | 09:43 | |
| vikasc | s/reading | 09:43 |
| limao_ | vikasc: "def allocate_segmentation_id(self, allocated_ids=set()):" | 09:44 |
| vikasc | limao_, yes | 09:44 |
| vikasc | limao_, coe should determine already allocated ids before calling allocate_segmentation_id | 09:45 |
| limao_ | vikasc: currently it is done in "ipam_release_address" in https://review.openstack.org/#/c/402462/ | 09:45 |
| limao_ | vikasc: yes, coe should decide it, but what if user restart the kuryr-libnetwork, then user just do the delete container(at this time you never called allocate_segmentation_id) | 09:47 |
| limao_ | vikasc: ltomasbo mentioned, he already latest data in port_vlan_dic , but available_local_vlans in SegmentationDriver is out of date at that time. | 09:49 |
| vikasc | limao_, let us try to understand with an example | 09:50 |
| vikasc | :) | 09:50 |
| limao_ | vikasc: OK, if you have an container on the vm which use vlan 100. | 09:51 |
| vikasc | limao_, when coe started, allocated_vlan_id = "1-100"(assume) | 09:51 |
| limao_ | vikasc: OK | 09:51 |
| vikasc | limao_, now after this container is using 100 | 09:51 |
| vikasc | limao_, available_vlan_ids = 1-99 | 09:52 |
| limao_ | vikasc: yes | 09:52 |
| vikasc | limao_, container is running and using 100 | 09:52 |
| vikasc | limao_, now what happens? | 09:52 |
| limao_ | vikasc: if we restart kuryr-libnetwork | 09:52 |
| vikasc | limao_, let me tell | 09:53 |
| vikasc | limao_, wait | 09:53 |
| limao_ | vikasc: OK | 09:53 |
| vikasc | limao_, on coming up , first of all seg_driver initializes available_ids_to 1-100 | 09:54 |
| limao_ | vikasc:yes | 09:54 |
| vikasc | limao_, then coe should read trunk ports and init already_allocated={100} | 09:54 |
| vikasc | limao_, now ? | 09:55 |
| vikasc | limao_, next what event happens, where it goes wrong | 09:55 |
| limao_ | vikasc: in coe, the already_allocated={100}, in seg_driver it is still 1-100 now | 09:56 |
| vikasc | limao_, which use case will get affected by this? | 09:56 |
| vikasc | limao_, now let say one more container is launched, coe will pass "100" and so seg_driver allocates 99 | 09:57 |
| limao_ | vikasc: at this time, if you delete the container | 09:58 |
| vikasc | limao_, ok let say the one using 99, ok? | 09:58 |
| limao_ | vikasc: ok | 09:58 |
| vikasc | limao_, so on deletion, seg_driver will all 99 to available making it back to "1-100" | 09:59 |
| vikasc | limao_, and coe has allocated_ids=100, which is being used by alredy runnning container | 10:00 |
| vikasc | limao_, all looks good to me so far :) | 10:00 |
| limao_ | vikasc: Yeah, if you never started a new container | 10:01 |
| vikasc | limao_, :O | 10:02 |
| limao_ | vikasc: the available_ids will be 1-100, and you will re-add 100 into it . (it is set, it should be ok, just a little bit strange for me, free a vlan already in available_ids) | 10:02 |
| limao_ | vikasc :( if you never started a new container , just delete an old one which is using vlan 100) | 10:03 |
| *** yedongcan1 has joined #openstack-kuryr | 10:03 | |
| ltomasbo | related to that, I just realize I forgot to call release_segmentation_id in the controller! | 10:03 |
| ltomasbo | going to update it! | 10:03 |
| vikasc | ltomasbo, you were reading the story :D | 10:04 |
| vikasc | limao_, functionality wise it seems fine. | 10:04 |
| ltomasbo | was in a call, but I think it should work either way | 10:04 |
| ltomasbo | but perhaps it is more intuitive the way limao_ is proposing | 10:04 |
| limao_ | vikasc: yes, functionality wise it is fine:) | 10:05 |
| vikasc | limao_,:) | 10:05 |
| ltomasbo | although the controller.py will get the allocated ids at reboot time, so the allocation should be working anyway | 10:05 |
| *** yedongcan has quit IRC | 10:05 | |
| limao_ | ltomasbo: vikasc: yes, well , each of way ok for me now, thanks to let me more clear :) | 10:06 |
| vikasc | thanks limao_ :) | 10:06 |
| ltomasbo | thanks limao_, I discover the missing call to release_id just by thinking about your example! | 10:09 |
| ltomasbo | :D | 10:09 |
| limao_ | ltomasbo: :D | 10:10 |
| irenab | vikasc: ltomasbo limao_ , looks like white screen design :-) | 10:11 |
| vikasc | :P | 10:11 |
| limao_ | ;-) | 10:12 |
| openstackgerrit | Luis Tomas Bolivar proposed openstack/kuryr-libnetwork: Nested-Containers: trunk subports management https://review.openstack.org/402462 | 10:16 |
| *** limao_ has quit IRC | 10:20 | |
| *** yedongcan1 has left #openstack-kuryr | 10:34 | |
| *** neiljerram has joined #openstack-kuryr | 10:41 | |
| *** pcaruana has joined #openstack-kuryr | 10:50 | |
| *** irenab has quit IRC | 11:11 | |
| *** irenab has joined #openstack-kuryr | 11:12 | |
| openstackgerrit | dengshaolin proposed openstack/fuxi: Retrieve volumes from cinder with matched metadata https://review.openstack.org/390448 | 11:16 |
| *** oanson has quit IRC | 11:30 | |
| *** oanson has joined #openstack-kuryr | 11:31 | |
| *** irenab has quit IRC | 11:34 | |
| *** irenab has joined #openstack-kuryr | 11:37 | |
| *** rock has joined #openstack-kuryr | 11:40 | |
| *** irenab has quit IRC | 11:42 | |
| *** irenab has joined #openstack-kuryr | 11:42 | |
| *** irenab has quit IRC | 11:47 | |
| rock | Hi. I am new to Kuryr. So I want to know the 1)kuryr usecases . 2)Who is using kuryr mostly. 3)How can we use make kolla, magnum and kuryr all together. | 11:49 |
| rock | Could you please provide me answers for questions. | 11:49 |
| *** janki has quit IRC | 11:50 | |
| apuimedo | rock: sure | 11:50 |
| apuimedo | the use case is to use Neutron and Cinder from Docker | 11:50 |
| apuimedo | that is, the networking that the containers get is provided by Neutron ports | 11:51 |
| apuimedo | rock: we have contributors from quite a few companies (in no particular order): Huawei, Cisco, Nec, Intel, Mirantis, Red Hat, AT&T | 11:52 |
| apuimedo | kolla can deploy kuryr-libnetwork so that docker containers will be able to use Neutron networks | 11:52 |
| apuimedo | there is a PoC from portdirect that uses kubernetes to deploy openstack on Neutron networks https://github.com/portdirect/harbor | 11:53 |
| apuimedo | so kolla-kubernetes could do the same with a bit of work | 11:53 |
| apuimedo | and we are now finishing support for Neutron subports in kuryr | 11:54 |
| *** irenab has joined #openstack-kuryr | 11:54 | |
| apuimedo | so that Magnum clusters will be able to use them | 11:54 |
| apuimedo | in that way, you'll get one Neutron subport per container in the nova instances that magnum uses for its deployments | 11:55 |
| rock | apuimedo : Thank you. I also new to kolla and magnum. Just I have a look on https://www.openstack.org/videos/barcelona-2016/containers-and-openstack-mapping-the-landscape. I came to know some information about kolla,magnum and kuryr. But I have some questions yet. Can I ask them now? | 11:57 |
| apuimedo | rock: I'm the one on the right! | 11:58 |
| apuimedo | rock: sure, go ahead. I'll try to answer them as quickly as I can, but I'm preparing some presentation and lunch time is coming in 5 minutes | 11:58 |
| rock | apuimedo: Hmmm. thank you very much. Can you please give the main use cases of kolla and magnum. | 12:01 |
| apuimedo | :-) | 12:01 |
| apuimedo | kolla deploys Openstack with each of the OpenStack services (Neutron, Nova, etc) running inside containers. It can do it with Docker and Ansible or with Kubernetes | 12:02 |
| *** irenab has quit IRC | 12:02 | |
| apuimedo | Magnum is one of the services that Kolla can deploy | 12:02 |
| apuimedo | and what it does is create Docker swarm or Kubernetes clusters running on Nova created VMs | 12:03 |
| *** janki has joined #openstack-kuryr | 12:03 | |
| *** limao has joined #openstack-kuryr | 12:03 | |
| rock | apuimedo: Kolla, magnum and kuryr , among these three which techonology used by industries mostly? | 12:05 |
| apuimedo | well, they are quite new, I suppose Magnum and kolla, since they are older, are more common | 12:06 |
| apuimedo | rackspace uses Magnum and I think kolla too, for example | 12:06 |
| apuimedo | but I don't really have industry usage data | 12:06 |
| apuimedo | :-) | 12:06 |
| rock | What was scope and focus of kolla, magnum and kuryr respectively. | 12:06 |
| apuimedo | Magnum: Container clusters as a service | 12:07 |
| *** limao_ has joined #openstack-kuryr | 12:07 | |
| apuimedo | Kolla: Openstack deployed inside containers | 12:07 |
| apuimedo | Kuryr: Containers using Openstack resources (networks and storage) | 12:07 |
| *** irenab has joined #openstack-kuryr | 12:08 | |
| rock | kolla, magnum and kuryr implemented by which language? | 12:09 |
| gsagie | python | 12:10 |
| *** limao has quit IRC | 12:10 | |
| gsagie | like any other OpenStack project (i think) | 12:10 |
| rock | apuimedo: Can I choose like 1) I have this type of requirement so I can use kolla (or) magnum (or) kuryr | 12:11 |
| rock | gsagie : thank you . | 12:11 |
| apuimedo | gsagie: nice to see you | 12:12 |
| gsagie | apuimedo: :) | 12:12 |
| ivc_ | irenab, apuimedo, ping | 12:12 |
| apuimedo | rock: yes, you can use whichever you want | 12:12 |
| apuimedo | and as many as you want | 12:12 |
| apuimedo | ivc_: pong | 12:12 |
| irenab | ivc_: hi | 12:12 |
| gsagie | rock: each one of these projects serve different goal | 12:12 |
| irenab | ivc_: I updated the devref yesterday | 12:12 |
| ivc_ | apuimedo, irenab, FYI some CNI design decisions: https://dl.dropboxusercontent.com/u/12482084/CNI.xmind (note the comments on some nodes) | 12:13 |
| irenab | take a look and if its ok, can convert it inot rst | 12:13 |
| ivc_ | irenab, ok | 12:13 |
| rock | apuimedo/gsagie : Thank you very much. | 12:13 |
| irenab | ivc_: internet does not like me today, seems except for irc nothing is working properly. may take some time to review | 12:13 |
| apuimedo | rock: you're most welcome | 12:14 |
| * apuimedo loves his fiber! | 12:15 | |
| apuimedo | irenab: you get dsl righ? | 12:16 |
| apuimedo | *right | 12:16 |
| irenab | toni, do not even start. I spent 30 mins with the tech support who tried to explain me how I can know if wifi is working …. | 12:16 |
| apuimedo | lol | 12:17 |
| rock | apuimedo/gsagie: Is the following statement is correct ? "Magnum community decided to limit the scope to the management of Container Orchestration Engines and leave the management of containers to a new project which is now called Zun. " | 12:17 |
| apuimedo | irenab: relevant xkcd https://xkcd.com/806/ | 12:18 |
| gsagie | rock: are you writing a book? :) | 12:18 |
| apuimedo | rock: that's right | 12:18 |
| irenab | apuimedo: cannot browse … | 12:18 |
| apuimedo | irenab: cellphone! | 12:18 |
| apuimedo | xD | 12:18 |
| gsagie | irenab: need a proxy ? ;) | 12:18 |
| rock | gsagie : No. Just saw in https://www.openstack.org/videos/barcelona-2016/magnum-is-not-the-openstack-containers-service-how-about-zun | 12:18 |
| apuimedo | irenab: mmm... Maybe you just have DNS screwed then | 12:19 |
| apuimedo | ivc_: nice doc | 12:20 |
| apuimedo | :-) | 12:20 |
| irenab | will try to safe proven method, just reboot everything …. | 12:20 |
| rock | apuimedo : Hmmm. so Magnum is going to deprecate? Zun will come inplace of magnum right with the same and some advanced features right? | 12:20 |
| apuimedo | no, they serve different purposes | 12:21 |
| rock | apuimedo : So what was the main usecase for zun? | 12:22 |
| apuimedo | better ask hongbin | 12:22 |
| apuimedo | :-) | 12:22 |
| apuimedo | irenab: https://drive.google.com/file/d/0B19pY94Ttis4WnN0dENuTnhNdms/view?usp=sharing | 12:22 |
| apuimedo | I put the xmind into a pdf for you | 12:22 |
| apuimedo | maybe you can open with the phone | 12:22 |
| * apuimedo -> lunch | 12:24 | |
| rock | apuimedo : hmmm. thank you. | 12:25 |
| rock | apuimedo: have a nice lunch | 12:25 |
| apuimedo | ivc_: for the ipdb netns stuff, check https://github.com/svinota/pyroute2/issues/290 | 12:26 |
| apuimedo | thanks | 12:26 |
| gsagie | rock: Zun mission is to expose an API to manage containers from OpenStack (regardless of which orchestration engine or container type you might be using), Magnum is focusing on deployment of containers orchestration enviorments inside OpenStack, when the user uses the orchestration engine he picked to manage the containers | 12:26 |
| apuimedo | ivc_: I agree with the decisions | 12:27 |
| apuimedo | but I'll need more explanations on the Handler controls Exit | 12:27 |
| ivc_ | apuimedo, there's no problem with NetNs atm (tho it does not work with pyroute2 from stable/newton) | 12:27 |
| ivc_ | apuimedo, regarding Exit, the idea is that CNI has to block until VIF.active == True and that is how 'exit' (or more specifically unblocking CNI) is a responsibility of Handler | 12:28 |
| *** dimak has quit IRC | 12:28 | |
| *** oanson has quit IRC | 12:29 | |
| ivc_ | apuimedo, so there are several options that i've covered. one option was to call CNI.success (which would print() and exit(0)) directly in Handler, but imo it would be confusing | 12:30 |
| rock | gsagie: Ok. Thank you. Which type of container management ZUN will do? | 12:31 |
| ivc_ | apuimedo, irenab, btw i've tested it with binary (golang) CNI 'bridge' driver with some tweaks and i can confirm that everything works now :) but the binary CNI 'bridge' can not be used outside PoC | 12:32 |
| irenab | apuimedo: thanks, suceeded to open it | 12:32 |
| *** oanson has joined #openstack-kuryr | 12:33 | |
| ivc_ | irenab, apuimedo, thats a screenshot, right? so the comments are not visible | 12:33 |
| rock | gsagie: what are the different container management methods delivered by zun? | 12:33 |
| irenab | ivc_: do you want to add the diagram in the devref? | 12:34 |
| irenab | we can keep discussion there | 12:34 |
| *** dimak has joined #openstack-kuryr | 12:34 | |
| ivc_ | irenab, eventually yes, but not necessary for the first iteration of the devref | 12:35 |
| irenab | I mean for the current discussion for you diagram | 12:35 |
| *** lmdaly has quit IRC | 12:35 | |
| irenab | ivc_: I will try to add you editting permissions | 12:36 |
| irenab | ivc_: done | 12:37 |
| ivc_ | irenab, you mean the pdf on google-drive? | 12:37 |
| irenab | yes | 12:38 |
| ivc_ | irenab, there are some comments i've left in the .xmind (you can see them as 'yellow notes' to the right from the text on nodes) | 12:38 |
| irenab | I cannot load them currently … | 12:39 |
| ivc_ | apuimedo, btw, i recommend you update to XMind 8 :) its UI finally does not look like its from the previous century | 12:39 |
| ivc_ | irenab, yeah you need the original .xmind file and the XMind itself. can you install XMind? i'll try to upload the original file to GoogleDrive | 12:41 |
| irenab | ivc_: I am still trying to download the file you shared, for some reason google drive keeps working for me | 12:42 |
| ivc_ | irenab, https://drive.google.com/file/d/0By4a5Rs0KiTYVldRMUtLQ2VvWTg/view?usp=sharing | 12:43 |
| irenab | now just need to get xmind .. | 12:46 |
| *** yamamoto_ has quit IRC | 12:47 | |
| *** janki has quit IRC | 12:52 | |
| *** tonanhngo has joined #openstack-kuryr | 12:53 | |
| *** tonanhngo has quit IRC | 12:55 | |
| *** lezbar has quit IRC | 13:10 | |
| ivc_ | irenab, i've reviewed the doc. looks good overall, i've left some comments | 13:21 |
| ivc_ | irenab, most importantly the last diagram is the most valuable part of the whole doc. | 13:22 |
| ivc_ | irenab, imo to get the best of it we should show CNI/Controller on the same diagram. also take a look on the CNI PoC (i've added the link to the doc) to get an idea of the watch/plug flow | 13:23 |
| irenab | ivc_: thanks! taking a look now | 13:26 |
| apuimedo | ivc_: there are comments? | 13:33 |
| *** yamamoto has joined #openstack-kuryr | 13:33 | |
| ivc_ | apuimedo, yes :) click on those 'yellow notes' icons | 13:33 |
| apuimedo | cool | 13:34 |
| apuimedo | :-) | 13:34 |
| apuimedo | I use xmind 7.5 | 13:34 |
| apuimedo | no 8.0 in arch linux yet | 13:34 |
| apuimedo | :P | 13:34 |
| ivc_ | :( | 13:34 |
| apuimedo | I'll check if I can update the pkgfile | 13:34 |
| ivc_ | irenab, i've uploaded a sketch for ControllerPipeline diagram | 13:47 |
| ivc_ | apuimedo, btw, what DE do you use on Arch (Xfce? KDE? Gnome? *box?) :) | 13:48 |
| *** tonanhngo has joined #openstack-kuryr | 13:51 | |
| *** tonanhngo has quit IRC | 13:52 | |
| *** gsagie has quit IRC | 13:52 | |
| irenab | ivc_: I sort of like the usage you did for the Bridge CNI | 13:53 |
| openstackgerrit | Luis Tomas Bolivar proposed openstack/kuryr-libnetwork: Nested-Containers: trunk subports management https://review.openstack.org/402462 | 13:54 |
| irenab | ivc_: for resource handlers ist realy ugly that it gets watcher to stop | 13:55 |
| ivc_ | irenab, well i can think of 3 options (check .xmind comments) and this one is the 'least evil' imo | 13:56 |
| irenab | need to get into into special EventHandler , like the Retry, but the opposite :-) | 13:57 |
| *** garyloug has joined #openstack-kuryr | 13:57 | |
| ivc_ | eventually we could maybe add 'unsubscribe' to Handler (similar to RxPy) | 13:57 |
| ivc_ | irenab, that would be ugly too :) using an exception for 'success' i mean:) | 13:58 |
| *** lmdaly has joined #openstack-kuryr | 13:58 | |
| irenab | ivc_: have some issue to download exmind, hope to resolve soon | 13:59 |
| irenab | ivc_: hopw we find more elegant way to solve it, I really do not think resource handler should know about the watcher | 14:01 |
| irenab | it should signal somehow that its job is done and the one who resitered it, can just unregister | 14:02 |
| *** oanson has quit IRC | 14:04 | |
| *** irenab_ has joined #openstack-kuryr | 14:04 | |
| ivc_ | irenab, well the 'best' solution is 'unregister' but it requires some massive (expected) changes, so for now i want to use Watcher.stop, but later we'll add 'unregister' i think | 14:06 |
| *** irenab has quit IRC | 14:06 | |
| ivc_ | thats the plan for now i mean | 14:06 |
| *** irenab_ has quit IRC | 14:08 | |
| *** irenab has joined #openstack-kuryr | 14:12 | |
| *** yamamoto has quit IRC | 14:12 | |
| *** lezbar has joined #openstack-kuryr | 14:18 | |
| openstackgerrit | Merged openstack/kuryr-libnetwork: Show team and repo badges on README https://review.openstack.org/402537 | 14:23 |
| *** hongbin has joined #openstack-kuryr | 14:23 | |
| *** yamamoto has joined #openstack-kuryr | 14:29 | |
| *** yamamoto has quit IRC | 14:31 | |
| openstackgerrit | vikas choudhary proposed openstack/kuryr: Nested-Containers: vlan driver https://review.openstack.org/361993 | 14:52 |
| ivc_ | mchiappero, btw when you go through https://docs.google.com/document/d/1hExm0TNp_OMWY_XMVRYpSvg5G8kFrL5hcrT9M_NDCwo/edit?usp=sharing , do not hesitate to leave comments if you find something confusing/missing :) we really need a 'fresh eye' to look at it now before it gets into gerrit | 14:56 |
| mchiappero | I'll try, even though I'm not familiar with the codebase | 14:57 |
| mchiappero | I'll let you know :) | 14:57 |
| alraddarla_ | apuimedo: is there an existing bug in launchpad for the mox to mock refactor? | 14:58 |
| *** oanson has joined #openstack-kuryr | 14:58 | |
| apuimedo | alraddarla_: there is | 14:58 |
| apuimedo | alraddarla_: there's also some patches started | 14:59 |
| apuimedo | https://review.openstack.org/#/c/395453/ | 14:59 |
| apuimedo | so take the rest of the work | 14:59 |
| janonymous | alraddarla_, apuimedo: some rebases left on those :P https://blueprints.launchpad.net/kuryr-libnetwork/+spec/drop-mox | 14:59 |
| ivc_ | mchiappero, thats the point - to see how helpful our devref is because you are not familiar with the codebase :) | 15:00 |
| apuimedo | janonymous: there is also some unit tests that are not on the patches with merge conflict too, right? | 15:00 |
| janonymous | apuimedo: no, only one left is of test_kuryr which i was waiting for other patches to get merged before submitting to avoid merge conflicts | 15:01 |
| janonymous | apuimedo: i was doing it file wise, last 2 patches i had in my local repo were test_kuryr.py and base.py (removal of several functions) | 15:02 |
| janonymous | https://review.openstack.org/#/q/status:open+project:openstack/kuryr-libnetwork+branch:master+topic:bp/drop-mox | 15:02 |
| *** tonanhngo has joined #openstack-kuryr | 15:03 | |
| *** tonanhngo has quit IRC | 15:04 | |
| apuimedo | janonymous: please, coordinate it with alraddarla_ | 15:04 |
| apuimedo | so you can both split the work and be rid of mox soon :P | 15:04 |
| janonymous | apuimedo: reabases would be very helpful :P | 15:05 |
| apuimedo | janonymous: you mean that alraddarla_ would take over your patches and rebase them? | 15:06 |
| janonymous | apuimedo: ahh..i was thinking of rebasing : https://review.openstack.org/#/q/status:open+project:openstack/kuryr-libnetwork+branch:master+topic:bp/drop-mox these patches and finding if any test is left in them | 15:07 |
| *** yamamoto has joined #openstack-kuryr | 15:10 | |
| janonymous | apuimedo: as per my record only 2 files are remaining test_kuryr.py and base.py... alraddarla_ could take base.py if its fine ? | 15:10 |
| alraddarla_ | janonymous: Would that be the only file I would need to update? Or do you need help with any of the other rebasing? | 15:11 |
| janonymous | alraddarla_: i am fine with both | 15:13 |
| alraddarla_ | janonymous: Okay. Just so I don't accidently mess something up, just let me know exactly which file(s) you would like me to refactor from mox to mock and if I need to rebase any of the old patch sets. | 15:16 |
| alraddarla_ | don't want to accidently work on the same things you are working on and duplicate work :) | 15:17 |
| janonymous | alraddarla_: :) | 15:18 |
| janonymous | alraddarla_: https://review.openstack.org/#/c/395453/ try rebase on this | 15:18 |
| *** hongbin has quit IRC | 15:20 | |
| alraddarla_ | sounds good. thanks janonymous | 15:22 |
| janonymous | alraddarla_: yw! | 15:22 |
| *** yamamoto has quit IRC | 15:47 | |
| *** hongbin has joined #openstack-kuryr | 15:54 | |
| *** fkautz has quit IRC | 16:01 | |
| *** david-lyle has quit IRC | 16:01 | |
| *** HenryG has quit IRC | 16:01 | |
| *** janonymous has quit IRC | 16:01 | |
| *** david-lyle has joined #openstack-kuryr | 16:02 | |
| *** HenryG has joined #openstack-kuryr | 16:02 | |
| *** fkautz has joined #openstack-kuryr | 16:06 | |
| *** janonymous has joined #openstack-kuryr | 16:06 | |
| *** dimak has quit IRC | 16:16 | |
| *** limao_ has quit IRC | 16:24 | |
| *** lezbar has quit IRC | 16:36 | |
| *** lezbar has joined #openstack-kuryr | 16:40 | |
| *** irenab has quit IRC | 16:49 | |
| *** lezbar has quit IRC | 16:50 | |
| *** shashank_hegde has joined #openstack-kuryr | 16:50 | |
| *** irenab has joined #openstack-kuryr | 16:54 | |
| *** lezbar has joined #openstack-kuryr | 16:55 | |
| *** lezbar has quit IRC | 16:59 | |
| *** lezbar has joined #openstack-kuryr | 16:59 | |
| openstackgerrit | Darla Ahlert proposed openstack/kuryr-libnetwork: Unitttests with mock https://review.openstack.org/395453 | 17:02 |
| *** lezbar has quit IRC | 17:04 | |
| alraddarla_ | janonymous, patch set rebased. let me know if i need to fix anything. | 17:06 |
| *** lezbar has joined #openstack-kuryr | 17:07 | |
| *** pcaruana has quit IRC | 17:19 | |
| *** garyloug has quit IRC | 17:32 | |
| *** shashank_hegde has quit IRC | 17:51 | |
| *** tonanhngo has joined #openstack-kuryr | 18:06 | |
| *** lmdaly has quit IRC | 18:09 | |
| *** tonanhngo has quit IRC | 18:30 | |
| *** lezbar has quit IRC | 18:34 | |
| *** tonanhngo has joined #openstack-kuryr | 18:44 | |
| *** tonanhngo has quit IRC | 18:45 | |
| *** shashank_hegde has joined #openstack-kuryr | 18:46 | |
| *** jgriffith is now known as jgriffith_away | 19:02 | |
| *** irenab has quit IRC | 19:05 | |
| *** tonanhngo has joined #openstack-kuryr | 19:30 | |
| *** lezbar has joined #openstack-kuryr | 20:14 | |
| *** lezbar has quit IRC | 20:16 | |
| *** jgriffith_away is now known as jgriffith | 20:18 | |
| *** oanson has quit IRC | 20:36 | |
| openstackgerrit | Hongbin Lu proposed openstack/fuxi: Add .testrepository/ to .gitignore https://review.openstack.org/403919 | 21:51 |
| openstackgerrit | Hongbin Lu proposed openstack/fuxi: Fix incorrect key on formating logging message https://review.openstack.org/403921 | 21:55 |
| openstackgerrit | Hongbin Lu proposed openstack/fuxi: Separate unit tests from fullstack tests https://review.openstack.org/403931 | 22:44 |
| *** pmannidi has joined #openstack-kuryr | 23:21 | |
| openstackgerrit | Hongbin Lu proposed openstack/fuxi: Separate unit tests from fullstack tests https://review.openstack.org/403931 | 23:25 |
| openstackgerrit | Hongbin Lu proposed openstack/fuxi: [WIP] Add volume tests https://review.openstack.org/403941 | 23:58 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!