| *** hujie has quit IRC | 00:06 | |
| *** rajivk has quit IRC | 00:37 | |
| *** rajivk has joined #openstack-dragonflow | 00:50 | |
| *** gongysh has joined #openstack-dragonflow | 02:35 | |
| *** rajivk has quit IRC | 02:50 | |
| openstackgerrit | Merged openstack/dragonflow: [TrivialFix]File *.rst fix typo error https://review.openstack.org/409621 | 02:58 |
|---|---|---|
| *** rajivk has joined #openstack-dragonflow | 03:02 | |
| openstackgerrit | rajiv proposed openstack/dragonflow: Correction in df-db dump command https://review.openstack.org/409537 | 03:03 |
| openstackgerrit | Hong Hui Xiao proposed openstack/dragonflow: Support qos in network https://review.openstack.org/403577 | 03:07 |
| openstackgerrit | Merged openstack/dragonflow: Add close function on publishers https://review.openstack.org/407541 | 03:29 |
| *** gongysh has quit IRC | 03:39 | |
| openstackgerrit | hujie proposed openstack/dragonflow: uniform resource method name in df_local_controller https://review.openstack.org/409450 | 03:43 |
| *** gongysh has joined #openstack-dragonflow | 03:54 | |
| openstackgerrit | hujie proposed openstack/dragonflow: refactor db consistent and object refresher(step1) https://review.openstack.org/408591 | 04:18 |
| openstackgerrit | hujie proposed openstack/dragonflow: refactor db consistent and object refresher(step1) https://review.openstack.org/408591 | 04:19 |
| *** rajivk has quit IRC | 05:07 | |
| *** rajivk has joined #openstack-dragonflow | 05:20 | |
| *** rajivk has quit IRC | 05:29 | |
| *** irenab_ has joined #openstack-dragonflow | 05:38 | |
| *** rajivk has joined #openstack-dragonflow | 05:42 | |
| *** rajivk has quit IRC | 05:49 | |
| *** rajivk has joined #openstack-dragonflow | 06:01 | |
| *** rajivk has quit IRC | 06:27 | |
| *** rajivk has joined #openstack-dragonflow | 06:39 | |
| *** saggi has joined #openstack-dragonflow | 06:53 | |
| *** saggi has quit IRC | 07:17 | |
| *** zenoway has joined #openstack-dragonflow | 07:34 | |
| *** yamamoto has quit IRC | 07:55 | |
| *** yuval has joined #openstack-dragonflow | 08:05 | |
| *** yuval has quit IRC | 08:11 | |
| *** oanson has joined #openstack-dragonflow | 08:11 | |
| *** duankebo has joined #openstack-dragonflow | 08:15 | |
| oanson | duankebo, hi | 08:15 |
| oanson | The deployement patch is here: https://review.openstack.org/#/c/391524/ | 08:16 |
| oanson | You can test it either by cloning openstack-ansible-os_neutron to a VM, and running 'tox -e dragonflow', | 08:16 |
| oanson | Or by using openstack ansible overlay, spacifically this branch: https://github.com/Logan2211/openstack-ansible-overlay/tree/dragonflow | 08:17 |
| oanson | The overlay project has usage documentation | 08:17 |
| duankebo | OK | 08:18 |
| duankebo | does it include the deployment of redis cluster? | 08:19 |
| oanson | Currently no. Only etcd. | 08:19 |
| oanson | If redis is already deployed, it can be linked via configuration | 08:19 |
| oanson | But deploying the actual Redis cluster is not yet covered | 08:19 |
| duankebo | are you planing to do some PoC also? | 08:21 |
| oanson | Depends on your meaning of PoC. There is a tox environment, and there is the overlay project configuration | 08:22 |
| oanson | Does that qualify, or did you mean something else? | 08:22 |
| duankebo | we are looking for appropriate projects to put dragonflow into practice. | 08:22 |
| *** dimak has joined #openstack-dragonflow | 08:23 | |
| oanson | That's great! | 08:23 |
| *** saggi has joined #openstack-dragonflow | 08:23 | |
| duankebo | no only deployment. I means testing the entire networking function together with customer. | 08:24 |
| saggi | dinak, dragnflow is 🐲+🙋 | 08:24 |
| saggi | dimak ^^ | 08:24 |
| oanson | duankebo, what did you have in mind? | 08:25 |
| duankebo | Hi gal! | 08:25 |
| oanson | duankebo, that's saggi, the Karbor PTL | 08:25 |
| duankebo | oh, sorry! looks so similar to gal's name! | 08:26 |
| duankebo | Hi saggi! | 08:26 |
| oanson | Yeah. Caused a lot of confusion in the past :) | 08:28 |
| duankebo | In fact, there are many PoC projects, but we need to find out one fitting for dragonflow. | 08:28 |
| oanson | Obviously, I'd be happy to assist in any way I can | 08:28 |
| duankebo | ^o^, thank you! | 08:29 |
| oanson | np | 08:31 |
| *** yamamoto has joined #openstack-dragonflow | 08:32 | |
| *** yamamoto_ has joined #openstack-dragonflow | 08:33 | |
| duankebo | This website is unreachable! | 08:34 |
| duankebo | https://logan.protiumit.com/2016/07/31/openstack-ansible-overlay.html | 08:34 |
| duankebo | Can you? | 08:34 |
| *** yamamoto has quit IRC | 08:37 | |
| *** lihi has joined #openstack-dragonflow | 08:40 | |
| *** yuval has joined #openstack-dragonflow | 08:40 | |
| dimak | #join ✈ | 08:41 |
| openstackgerrit | Hong Hui Xiao proposed openstack/dragonflow: Refactor test case for ml2 mech driver(qos) https://review.openstack.org/393750 | 08:54 |
| oanson | duankebo, sorry I only saw this now. I found the source : https://github.com/Logan2211/logan2211.github.io/blob/master/_posts/2016-07-31-openstack-ansible-overlay.markdown | 09:12 |
| oanson | which should be accessible | 09:13 |
| duankebo | Yes, it's accessible! | 09:27 |
| openstackgerrit | Merged openstack/dragonflow: Refactor DHCP app for code reusage https://review.openstack.org/274528 | 09:29 |
| *** gongysh has quit IRC | 09:36 | |
| oanson | dimak, ping | 09:40 |
| *** rajivk has quit IRC | 09:40 | |
| dimak | oanson, hey | 09:40 |
| oanson | I commented on patch 2 | 09:41 |
| oanson | Added to the discussion with xiaohhui | 09:41 |
| oanson | I think I have a compromise for what I don't like about the change in 1 | 09:41 |
| dimak | oanson, thanks, reading | 09:45 |
| *** xiaohhui has joined #openstack-dragonflow | 09:45 | |
| oanson | xiaohhui, hi | 09:46 |
| xiaohhui | hello | 09:46 |
| oanson | dimak, xiaohhui, maybe we'll continue the discussion here? | 09:46 |
| *** yamamoto_ has quit IRC | 09:46 | |
| xiaohhui | yeah, let me check your comment first | 09:46 |
| dimak | oanson, xiaohhui hey | 09:46 |
| oanson | np | 09:46 |
| dimak | oanson, did you get to read the comments on line 971? | 09:47 |
| oanson | No. 1 sec | 09:47 |
| *** yamamoto has joined #openstack-dragonflow | 09:47 | |
| oanson | Yes I see | 09:49 |
| oanson | I think of it more as Mixins than tool classes. You have a mixin to support unique keys. And a mixin to support CRUD | 09:49 |
| oanson | And later mixins to support other things (if that ever comes up) | 09:49 |
| oanson | Like maybe subelements (subnets, router ports) | 09:50 |
| dimak | I wouldn't call it a mixin though | 09:50 |
| xiaohhui | What about change from nb_api.create_lport to nb_api.create(models.Lport), instead of nb_api.lport.create. It is more nature to semantic. | 09:50 |
| xiaohhui | https://thepasteb.in/p/xGhmn9mL642fM | 09:51 |
| xiaohhui | and the method in nb_api can be organized this way | 09:51 |
| dimak | xiaohhui, I don't think passing around table_name is better than passing the model itself | 09:52 |
| xiaohhui | It just feel strange to me to change the initialize method everytime we add a resource to nb db | 09:53 |
| *** rajivk has joined #openstack-dragonflow | 09:53 | |
| oanson | xiaohhui, I agree. Maybe as a next step we can have resources automatically register themselves? | 09:53 |
| irenab_ | xiaohhui, dimak , just add model registration method, so every new model will add itself | 09:53 |
| xiaohhui | Why you need model, only the table_name will be used | 09:53 |
| dimak | I think its convenient | 09:53 |
| oanson | Actually, if you have the model, you can get more info from it | 09:54 |
| oanson | e.g. which CRUDHelper to use. Which features are supported. | 09:54 |
| dimak | xiaohhui, model is more useful, e.g. in nb_api.get(table_name, id) | 09:54 |
| oanson | In an implementation where models register themselves, you don't have this info in advance | 09:54 |
| dimak | with model you can just model(db_driver.get_key(model.table_name, key)) | 09:54 |
| xiaohhui | You can put model in crudhelper, but the user of nb_api don't need to know the model, right? | 09:55 |
| dimak | but for table_name I still have to through the model: | 09:56 |
| dimak | models.Lport.table_name | 09:56 |
| openstackgerrit | WangJian proposed openstack/dragonflow: Refactor port-status-update NB API https://review.openstack.org/396915 | 09:56 |
| xiaohhui | it is just a const to me, when I added them | 09:56 |
| dimak | unless I get it from the db update, then we can add a lookup in models module | 09:57 |
| oanson | or in the module registration mechanism | 09:58 |
| dimak | irenab_, I can add model registration | 09:58 |
| dimak | But NB api will have to know which crud helper to use with it | 09:58 |
| oanson | dimak, that can be provided during registration (e.g. by the model itself) | 09:59 |
| irenab_ | oanson, +1 | 09:59 |
| xiaohhui | or we can just hide the attributes of nb_api(like chassis, lswitch in current patch), and just manage them under the hood. | 09:59 |
| xiaohhui | we added them staticly, not expose every handler to user | 10:00 |
| xiaohhui | just let user to tell which resource he/she wants to create/update/delete/get | 10:00 |
| xiaohhui | which resource name | 10:00 |
| xiaohhui | and nb_api itself chose the handler under the hood | 10:01 |
| xiaohhui | and do the job | 10:01 |
| irenab_ | I think that who ever uses nB api should get REST like experience | 10:01 |
| irenab_ | NB API will dispach the request to the proper resource Handler | 10:02 |
| xiaohhui | yeah, that is my point, | 10:02 |
| xiaohhui | so nb_api will only to provide CRUD methods all the time | 10:02 |
| xiaohhui | There is a similar change here, https://review.openstack.org/#/c/409669/2/dragonflow/db/db_store.py | 10:04 |
| xiaohhui | which I think we should also prevent it. | 10:05 |
| dimak | I think parameter is less convenient than binding it internally and providing a method | 10:05 |
| xiaohhui | If we write code this way, we are losing the convenience of const. | 10:05 |
| dimak | What do you mean? | 10:05 |
| xiaohhui | User has to know which handler/attribute is mapped to the actual resource | 10:06 |
| dimak | the member we we don't even have to import models module | 10:06 |
| *** rajivk has quit IRC | 10:06 | |
| xiaohhui | Import could be less, but as I said, I think the table_name is a const. The const module is nature to be imported everywhere. | 10:07 |
| oanson | We could allow both APIs, but I suspect that would be too cumbersome | 10:07 |
| oanson | dimak, in your solution, how do you solve automatic registration? | 10:08 |
| oanson | In xiaohhui | 10:08 |
| oanson | In xiaohhui 's solution, this is handled almost automatically | 10:08 |
| dimak | oanson, no but I will try to add it | 10:09 |
| oanson | So far this is a great advantage to xiaohhui 's solution, and the only major difference I see | 10:09 |
| dimak | We're going for lunch I'll try to see if I can add autoregistration | 10:09 |
| dimak | I agree | 10:09 |
| oanson | Since I don't mind if we get the model using a a getter or a property | 10:09 |
| oanson | xiaohhui, you're willing to wait to see what dimak comes up with, and take it from there (tomorrow, if it's too late for you?) | 10:10 |
| xiaohhui | In my mind, I think the user(just the developer ourself), only need to know which resource to operate, and which module(db_store, nb_api) to use. And just tell the db_store or nb_api, which action he/she want to perform on which resource. | 10:11 |
| xiaohhui | he/she may not want to know the details of db_store and nb_api, they just needs to do their own job | 10:11 |
| oanson | xiaohhui, yes. But if the resource name is an attribute on nbapi/dbstore, or retrieved using a getter, I don't think it makes a lot of difference | 10:12 |
| oanson | Except maybe namespace pollution on nb_api | 10:12 |
| oanson | (which is also an issue with dimak's solution, as we saw in patch 1) | 10:13 |
| xiaohhui | So, if it is me, I don't want to checkout which handler in nb_api I should pick. I don't even want to open the file of nb_api. | 10:13 |
| *** yamamoto has quit IRC | 10:14 | |
| xiaohhui | I want just call nb_api.create(resource_name) | 10:14 |
| oanson | I see. Using your solution, this is trivial. Using dimak 's solution, we have to manually maintain some form of convention | 10:14 |
| oanson | xiaohhui, or nb_api.get(resource_name).create(...) | 10:15 |
| oanson | ('get' may need to be a better name) | 10:15 |
| *** yamamoto has joined #openstack-dragonflow | 10:15 | |
| oanson | create/update/delete/get can be syntactic sugars in this case. e.g. create(<resoiurce>, ...) calls get_resource(<resource>).create(...) | 10:15 |
| oanson | Since we may want to allow other methods for specific resources, and we may want the resource to provide them, without changing nb_api | 10:16 |
| oanson | (dynamic registration scenario, REST API) | 10:16 |
| *** lihi has quit IRC | 10:17 | |
| xiaohhui | That is ok, too. I think we can do dynamic registration work latter. But this convenience is what I want to see | 10:17 |
| xiaohhui | For that scenario, your proposal is better than mine | 10:17 |
| oanson | I just want to make sure we see the whole picture, so we won't have to revisit this decision | 10:18 |
| *** rajivk has joined #openstack-dragonflow | 10:18 | |
| oanson | I'll pick up the discussion with dimak. I feel his solution is too syntax-friendly, and not extensible enough | 10:19 |
| oanson | (As a result of this discussion) | 10:19 |
| oanson | xiaohhui, thanks for your help | 10:20 |
| xiaohhui | OK, we may not have a perfect solution here, but discussion is always good | 10:20 |
| xiaohhui | np | 10:20 |
| oanson | agreed | 10:21 |
| oanson | rajivk, ping | 10:23 |
| rajivk | oanson, hi | 10:24 |
| oanson | Hi. Do you still have a free hand? | 10:24 |
| xiaohhui | have a good lunch oanson, bye | 10:24 |
| oanson | I am looking for a carrier for data-plane performance tests, e.g. browbeat and its modules | 10:24 |
| oanson | xiaohhui, thanks. Have a good dinner. | 10:24 |
| oanson | rajivk, are you interested? | 10:25 |
| *** yamamoto has quit IRC | 10:26 | |
| *** yamamoto has joined #openstack-dragonflow | 10:27 | |
| *** rajivk has quit IRC | 10:28 | |
| *** dimak has quit IRC | 10:32 | |
| *** rajivk has joined #openstack-dragonflow | 10:40 | |
| *** yamamoto has quit IRC | 10:41 | |
| *** dimak has joined #openstack-dragonflow | 10:45 | |
| openstackgerrit | Yuli proposed openstack/dragonflow: Fix lock timeout issue Closes-bug: #1649548 https://review.openstack.org/410160 | 10:45 |
| openstack | bug 1649548 in DragonFlow "High delay in create_network" [High,New] https://launchpad.net/bugs/1649548 - Assigned to Yuli (stremovsky) | 10:45 |
| openstackgerrit | Yuli proposed openstack/dragonflow: Fix lock timeout issue https://review.openstack.org/410160 | 10:45 |
| *** yamamoto has joined #openstack-dragonflow | 10:46 | |
| *** rajivk has quit IRC | 11:06 | |
| *** yamamoto has quit IRC | 11:08 | |
| *** rajivk has joined #openstack-dragonflow | 11:18 | |
| *** yamamoto has joined #openstack-dragonflow | 11:21 | |
| *** yamamoto has quit IRC | 11:22 | |
| *** rajivk has quit IRC | 11:24 | |
| *** zenoway has quit IRC | 11:25 | |
| *** yamamoto has joined #openstack-dragonflow | 11:26 | |
| *** zenoway has joined #openstack-dragonflow | 11:26 | |
| *** zenoway has quit IRC | 11:30 | |
| *** rajivk has joined #openstack-dragonflow | 11:36 | |
| *** dimak has quit IRC | 11:37 | |
| *** dimak has joined #openstack-dragonflow | 11:50 | |
| *** lihi has joined #openstack-dragonflow | 12:01 | |
| openstackgerrit | WangJian proposed openstack/dragonflow: Refactor port-status-update NB API https://review.openstack.org/396915 | 12:10 |
| *** hujie has joined #openstack-dragonflow | 12:12 | |
| oanson | hujie, hi | 12:16 |
| hujie | Hi | 12:16 |
| oanson | The discussion was fairly long, but mostly dimak wanted to add an attribute per model to nb api, and have the crud methods on the returned object | 12:17 |
| oanson | xiaohhui wanted this to be done in the same manner as in db store | 12:17 |
| hujie | add crud class into db store? | 12:18 |
| oanson | I think the direction we'll take in the end is: {nb_api|db_store}.get_resource(<resource>).<action>(...) | 12:18 |
| oanson | We will want to make the two classes uniform | 12:18 |
| oanson | in the API level, at least | 12:18 |
| dimak | oanson, hujie hey, I'm taking a look at db_store patch for a minute | 12:19 |
| oanson | This way, registering a new model would be easiest. | 12:19 |
| oanson | In future, we'll want to add a dynamic/automatic model registration and REST (like) API support | 12:20 |
| hujie | yes, many methods in db store just have one line of code and they could be uniform | 12:20 |
| hujie | but have some exceptions | 12:21 |
| hujie | for example, set_port and delete_port | 12:21 |
| hujie | it will manipulate two dif tables | 12:21 |
| dimak | yes,not all models behave the same | 12:21 |
| hujie | and also we got the similar method, for example: get_ports_by_chassis | 12:22 |
| hujie | the method is different from other methods | 12:22 |
| oanson | Yes. We would want to support methods like that, preferably without needing to know about them in advance | 12:23 |
| dimak | also db_store handles things that are not models, like local_port | 12:23 |
| oanson | e.g. get_ports_by_chassis is provided by lport upon registration | 12:23 |
| oanson | dimak, that is on the same level as get_ports_by_chassis | 12:24 |
| oanson | lport has a distinction between local and remote ports, and provides functionality to take advantage of that distinction | 12:24 |
| dimak | I think this autoregistration overcomplicates things | 12:24 |
| oanson | dimak, but it will be needed | 12:24 |
| oanson | If we want the NB api to be updated with new features (e.g. fwaas, tapaas, vpnaas, or anything that adds new models), this will be the best solution in the long run | 12:25 |
| dimak | One of the issues with registration is that code is less navigatable | 12:25 |
| oanson | Changes should be as modular as possible. If for every feature NB api, db store, and df controller have to be modified, we need to find a way to simplify that | 12:25 |
| hujie | yes that's our aim | 12:26 |
| oanson | dimak, that can be mitigated with correct code structure and documentation | 12:26 |
| oanson | Not the best solution, I agree | 12:26 |
| oanson | But you can't have your kayak and heat it | 12:26 |
| oanson | I mean you can't have your cake and eat it | 12:27 |
| dimak | 🎂🔥 | 12:27 |
| oanson | Of course, if you have an idea that answers all the requirements, I'd be more than happy to hear it :) | 12:27 |
| dimak | I just wonder what should be the relation between a model, nb_api, and the code that handles model over nb api (crud helper) | 12:28 |
| oanson | Let's see... nb api should manage writing to the database. But should be model oriented. A model registers itself at the nb api, possibly with additional functions | 12:30 |
| oanson | The client developer takes the model and nb api, and calls the relevant operations. | 12:30 |
| oanson | The same is true with db store, but similar, not identical | 12:31 |
| oanson | Since db store is a cache, additional features may be wanted, e.g. searching or indexing according specific fields (topic, chassis, local/remote) | 12:31 |
| hujie | maybe I need more thinking to uniform all the methods which have different structure :) | 12:32 |
| *** lihi has quit IRC | 12:32 | |
| oanson | I think we all do | 12:32 |
| oanson | It's not as easy as it looked yesterday :) | 12:32 |
| *** yamamoto has quit IRC | 12:33 | |
| hujie | yes :) | 12:33 |
| oanson | Why don't I try writing a spec and pour my initial thoughts into it. That way we have a general idea of what we are trying to achieve, including requirements, and a possible solution | 12:33 |
| oanson | I'll take our discussions today into account | 12:34 |
| dimak | oanson, hujie I agree. Maybe if we start using the models in a more uniform way, we use same code for all models | 12:34 |
| oanson | Note the different alternatives, with their pros and cons | 12:34 |
| oanson | I think that's the plan. Then we just register the model, and everything else should be automatic for the common case | 12:34 |
| hujie | ok, we could record the solution into spec | 12:35 |
| dimak | I think we should take extra care in avoiding uncommon cases | 12:35 |
| dimak | if we have just one "crud-helper" code per dbstore / apinb, and no need to specialize them | 12:37 |
| hujie | ok, let's have more thinking about the issue. | 12:39 |
| *** yamamoto has joined #openstack-dragonflow | 12:54 | |
| *** yamamoto has quit IRC | 13:10 | |
| *** yamamoto has joined #openstack-dragonflow | 13:11 | |
| *** lihi has joined #openstack-dragonflow | 13:13 | |
| *** yamamoto has quit IRC | 13:16 | |
| *** gongysh has joined #openstack-dragonflow | 13:33 | |
| *** gongysh has quit IRC | 13:36 | |
| *** rajivk has quit IRC | 13:53 | |
| *** rajivk has joined #openstack-dragonflow | 14:05 | |
| *** yamamoto has joined #openstack-dragonflow | 14:14 | |
| *** rajivk has quit IRC | 14:15 | |
| *** yamamoto has quit IRC | 14:26 | |
| *** irenab_ has quit IRC | 14:35 | |
| *** gsagie has joined #openstack-dragonflow | 14:48 | |
| *** saggi1 has joined #openstack-dragonflow | 15:01 | |
| *** saggi has quit IRC | 15:01 | |
| *** saggi1 is now known as saggi | 15:01 | |
| *** saggi1 has joined #openstack-dragonflow | 15:02 | |
| *** gsagie has quit IRC | 15:03 | |
| *** yuval has quit IRC | 15:34 | |
| *** saggi has quit IRC | 15:37 | |
| *** lihi has quit IRC | 15:39 | |
| *** dimak has quit IRC | 15:39 | |
| openstackgerrit | Omer Anson proposed openstack/dragonflow: North Bound Code Refactor https://review.openstack.org/410298 | 16:24 |
| oanson | xiaohhui, hujie, dimak, irenab ^^^^^ | 16:28 |
| *** saggi1 has quit IRC | 19:01 | |
| openstackgerrit | Steve Kipp proposed openstack/dragonflow: Add unit tests to dhcp_app https://review.openstack.org/409844 | 21:27 |
| *** yamamoto has joined #openstack-dragonflow | 22:28 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!