| *** yamamoto has joined #openstack-dragonflow | 04:57 | |
| *** yamamoto has quit IRC | 05:07 | |
| *** yamamoto has joined #openstack-dragonflow | 05:08 | |
| *** yamamoto has quit IRC | 05:27 | |
| *** yamamoto has joined #openstack-dragonflow | 05:30 | |
| *** yamamoto has quit IRC | 05:36 | |
| *** CrayZee has joined #openstack-dragonflow | 06:28 | |
| *** yamamoto has joined #openstack-dragonflow | 06:35 | |
| *** yamamoto has quit IRC | 06:41 | |
| *** yamamoto has joined #openstack-dragonflow | 07:45 | |
| oanson | Morning | 07:56 |
|---|---|---|
| oanson | snapiri, CrayZee, ping | 08:04 |
| oanson | Well, when you see this: Patch https://review.openstack.org/#/c/528539 requires upgrade code. I don't mind pushing it through as is, but I want to get an ack before I do so | 08:16 |
| CrayZee | pong | 08:28 |
| CrayZee | hmm... I would need some mentoring (or example) with it | 08:29 |
| CrayZee | oanson: ^^ | 08:44 |
| oanson | CrayZee, No worries. | 08:45 |
| oanson | I mostly wanted you to know it's expected. Since the upgrade is still in design stages, a simple placeholder is enough. | 08:45 |
| oanson | There are 2-3 patches, let me hunt them down. | 08:45 |
| oanson | Base implementation: https://review.openstack.org/#/c/401210/ , example one (DHCP) https://review.openstack.org/#/c/527716/ example 2 (Subnet, which I believe is most relevant) https://review.openstack.org/#/c/527717/ | 08:46 |
| oanson | There's also a spec: https://review.openstack.org/#/c/500647/ | 08:47 |
| *** natanbro has joined #openstack-dragonflow | 08:51 | |
| CrayZee | So AFAIU I should pop the name field and re-set the objects? | 09:23 |
| CrayZee | oanson: use https://review.openstack.org/#/c/401210/ as a parent? | 09:29 |
| oanson | CrayZee, Yes, that sounds about right. Lemme check re: the parent | 09:30 |
| oanson | That or https://review.openstack.org/#/c/527717/. Up to you. | 09:30 |
| oanson | Worse comes, we'll rebase it if needed. | 09:30 |
| openstackgerrit | Shachar Snapiri proposed openstack/dragonflow master: Added Migration code for floatingip field removal https://review.openstack.org/529012 | 09:42 |
| CrayZee | oanson: done: https://review.openstack.org/529012/ | 09:43 |
| oanson | CrayZee, looks good. | 09:44 |
| oanson | Pushed the parent | 09:44 |
| openstackgerrit | Dima Kuznetsov proposed openstack/dragonflow master: Datapath abstraction spec https://review.openstack.org/503538 | 09:50 |
| dimak | oanson, ^^^ | 09:51 |
| oanson | dimak, thanks. Looking now | 09:51 |
| oanson | dimak, looks good. | 09:56 |
| oanson | Do you plan to update the spec with the low-level design? Add that to a dev-ref? Or just go ahead and implement it once the spec is approved? | 09:57 |
| dimak | oanson, I think of adding some extra stuff to graph wiring config | 09:58 |
| dimak | i.e. how to instantiate the apps | 09:58 |
| oanson | I see | 09:58 |
| oanson | This can also give us automatic registration to packet-in event. | 09:59 |
| dimak | though it breaks up a bit, because apps != datapath elements | 09:59 |
| dimak | I think app list should go out | 09:59 |
| dimak | and be parametrizable | 09:59 |
| oanson | Definitely. Apps should be defined by the graph. | 10:00 |
| dimak | no! | 10:00 |
| oanson | No? | 10:00 |
| dimak | Graph is composed of elements | 10:00 |
| dimak | Apps define elements | 10:00 |
| dimak | one or many or none at all | 10:00 |
| oanson | So you need an app list - you need to know which apps to load, to know what elements you have | 10:00 |
| dimak | I want to somehow unify it | 10:01 |
| oanson | We should avoid loading apps which the deployer doesn't want. | 10:01 |
| dimak | for me, each app is an instance | 10:01 |
| dimak | it will have its type | 10:01 |
| dimak | (e.g. stevedore entrypoint) | 10:01 |
| dimak | and its init params | 10:01 |
| dimak | then each app will have elements | 10:01 |
| dimak | and each element will have exits/entrypoints | 10:02 |
| dimak | so you're basically define nodes, that are app instances | 10:02 |
| dimak | just like there are ports in DOT | 10:02 |
| dimak | We can used app_instance:element:entrypoint:entrypoint_name | 10:03 |
| dimak | A bit long notation, but I think it makes it very clear | 10:03 |
| oanson | If it's too long, I think we can remove the ':entrypoint:' element. It should be clear from the syntax | 10:03 |
| dimak | Kind of | 10:04 |
| dimak | because exits got to entries | 10:04 |
| oanson | So how do you tell Dragonflow what apps to load, and what are their init params? | 10:04 |
| dimak | A moment :) | 10:04 |
| oanson | It will be: app_instance:element:exitpoint_name -> app_instance_2:element2:entrypoint_name; , or something similar, right? | 10:05 |
| dimak | yes | 10:06 |
| dimak | maybe allow omitting element name if there's only one | 10:06 |
| dimak | which is most apps | 10:06 |
| dimak | dunno yet | 10:06 |
| oanson | That makes sense. | 10:07 |
| oanson | If you have only one element, and one entry or exit point, there's no need to be explicit. And it will probably be more readable in this particular case. | 10:07 |
| dimak | https://etherpad.openstack.org/p/df-graph | 10:08 |
| dimak | I think explicitness can add readability | 10:08 |
| oanson | I was referring to the case when there's only one element or entrypoint/exitpoint. Otherwise, I agree that it should be explicit | 10:10 |
| dimak | We can decide to do that later | 10:10 |
| dimak | oanson, lets get back to IRC | 10:13 |
| oanson | Each app that has to be loaded, will have a stevedore name | 10:13 |
| dimak | yes, it has one right now | 10:13 |
| oanson | Stevedore loads this class. | 10:13 |
| dimak | Yes | 10:13 |
| oanson | This class will contain the necessary params | 10:14 |
| dimak | What do you refer to as params? | 10:14 |
| oanson | These params will be elements, entrypoints, exitpoints, init params, etc., right? | 10:14 |
| dimak | No | 10:14 |
| dimak | Those are fixed for a specific version of code | 10:14 |
| oanson | Yes. | 10:14 |
| oanson | This is not a configuration option. When stevedore loads the class, this information has to be made available. | 10:15 |
| dimak | I was aiming at application level config | 10:15 |
| dimak | for instance, enabled seg types for trunk app | 10:15 |
| dimak | i.e. do macvlan or not | 10:15 |
| oanson | These are the init params, right? | 10:16 |
| dimak | yes | 10:16 |
| oanson | But the application has to define (at code level) elements, entrypoints, and exit points. Isn't that what we agreed? | 10:16 |
| dimak | maybe you want to have 2 instances of trunk app, add different locations | 10:16 |
| dimak | one doing macvlan and one doing vlans | 10:16 |
| dimak | yes | 10:16 |
| oanson | I see. This explains why a config file isn't good enough | 10:16 |
| oanson | So at code level, when the class is loaded, it should make the following information public: elements, entrypoints, exitpoints, init params, and a constructor to initialise the actual application (to prepare it to start receiving events) | 10:18 |
| oanson | If that's wrong, then I'm missing something big... | 10:18 |
| dimak | yes | 10:18 |
| oanson | All right. So we're on the same page. | 10:18 |
| dimak | I think that's pretty much it | 10:18 |
| oanson | Cool! | 10:19 |
| dimak | I think params are can be pretty much opaque | 10:19 |
| dimak | just throw the dictionary inside as kwargs | 10:19 |
| oanson | If it's not opaque, we can verify it first. Like configuration options | 10:19 |
| oanson | e.g. make sure an int is an int, a bool is a bool, and a list is a list. | 10:20 |
| dimak | This can come later, I think it's less interesting in the scope of this change | 10:20 |
| oanson | Sure | 10:20 |
| dimak | I mean, it can be great, just does not aid in decoupling apps :) | 10:21 |
| oanson | True. | 10:21 |
| oanson | Sounds like we have a plan! | 10:22 |
| dimak | Oh, and most importantly, with this approach we can start porting apps and we don't have to change all that much ode | 10:23 |
| oanson | Yes | 10:24 |
| oanson | How do you pass table names and goto commands to the apps? | 10:24 |
| oanson | I mean table numbers | 10:24 |
| oanson | And the commands the apps need to use to pass the packet to the next item in the pipeline | 10:24 |
| dimak | I don't pass names | 10:28 |
| dimak | I'll construct the element objects on initialization | 10:29 |
| dimak | then it will contain IDs | 10:29 |
| dimak | element.states.STAT_NAME | 10:29 |
| dimak | also, IDs are allocated in the same order they were listed | 10:29 |
| oanson | I see. And the STATE_NAME of the exit point will actually be the entrypoint of the next element in the pipeline? | 10:30 |
| dimak | so Gotos/Resubmits won't have to change | 10:30 |
| dimak | oanson, no | 10:30 |
| dimak | It's an intermediate table | 10:30 |
| dimak | I'll have to move registers around there | 10:30 |
| dimak | In my approach the app will dictate what registers it uses, and how | 10:31 |
| oanson | Ah | 10:31 |
| dimak | If we optimize the in-tree code, it won't have to copy at all | 10:31 |
| dimak | but I can't force that | 10:31 |
| oanson | All right. | 10:31 |
| dimak | It also simplifies the SetField actions a lot | 10:32 |
| oanson | I would prefer the registrar solution (like for cookies) we discussed in the past. But we should take it step-by-step | 10:32 |
| oanson | Yes. I figured that's one of the reasons | 10:32 |
| dimak | I think its so much work its not even worth it | 10:33 |
| dimak | We can just offer optimization tool | 10:33 |
| oanson | Probably. | 10:33 |
| dimak | that can give hints what registers should be used | 10:33 |
| dimak | to avoid copies | 10:33 |
| oanson | It's also very OpenFlow specific. Which is also a good reason to avoid working hard for it :). | 10:33 |
| dimak | Yes | 10:34 |
| dimak | I'll add the config part to the spec, and I think we can more forward quite fast from there | 10:35 |
| oanson | Sure. Sounds good | 10:35 |
| dimak | The code snippet there is non binding, I haven't figured it out in all details | 10:36 |
| oanson | Makes sense. | 10:36 |
| dimak | But its good enough as concept for now | 10:36 |
| oanson | Please also include what we discussed re registers (naming and moving around), STATE_NAME + intermediary tables, etc. | 10:36 |
| oanson | Yes, definitely! | 10:36 |
| dimak | Ok | 10:37 |
| oanson | Thanks! | 10:37 |
| *** yamamoto has quit IRC | 10:55 | |
| *** yamamoto has joined #openstack-dragonflow | 10:55 | |
| *** yamamoto has quit IRC | 10:56 | |
| *** yamamoto has joined #openstack-dragonflow | 10:56 | |
| *** yamamoto has quit IRC | 11:09 | |
| *** yamamoto has joined #openstack-dragonflow | 11:13 | |
| *** yamamoto has quit IRC | 11:18 | |
| openstackgerrit | Dima Kuznetsov proposed openstack/dragonflow master: Datapath abstraction spec https://review.openstack.org/503538 | 11:30 |
| openstackgerrit | Merged openstack/dragonflow master: Remove the 'name' attribute from FloatingIP https://review.openstack.org/528539 | 11:30 |
| *** yamamoto has joined #openstack-dragonflow | 12:06 | |
| *** yamamoto has quit IRC | 12:10 | |
| *** mlavalle has joined #openstack-dragonflow | 12:28 | |
| openstackgerrit | Omer Anson proposed openstack/dragonflow master: Fix calling convention in lockedobjects_db.py https://review.openstack.org/529051 | 12:32 |
| openstackgerrit | Shachar Snapiri proposed openstack/dragonflow master: [WIP][DNM]Test various debug patches https://review.openstack.org/499523 | 12:35 |
| CrayZee | It seems that my fix at https://review.openstack.org/#/c/527625/ indeed does not solve the issue. | 12:38 |
| *** yamamoto has joined #openstack-dragonflow | 12:38 | |
| CrayZee | when zuul is vary busy it still fails. I am still investigating | 12:38 |
| *** yamamoto has quit IRC | 12:39 | |
| oanson | CrayZee, maybe there's something we can wait on to know when OVSDB and DF reconnect? | 12:53 |
| openstackgerrit | Omer Anson proposed openstack/dragonflow master: Fix calling convention in lockedobjects_db.py https://review.openstack.org/529051 | 12:57 |
| CrayZee | I am not sure they are not reconnected. Added some debug prints to try and figure out | 13:07 |
| CrayZee | oanson: ^^ | 13:07 |
| *** yamamoto has joined #openstack-dragonflow | 13:40 | |
| *** yamamoto has quit IRC | 13:48 | |
| openstackgerrit | Shachar Snapiri proposed openstack/dragonflow master: [WIP][DNM]Test various debug patches https://review.openstack.org/499523 | 14:49 |
| openstackgerrit | Shachar Snapiri proposed openstack/dragonflow master: [WIP][DNM]Test various debug patches https://review.openstack.org/499523 | 15:56 |
| *** natanbro has quit IRC | 16:35 | |
| openstackgerrit | Shachar Snapiri proposed openstack/dragonflow master: [WIP][DNM]Test various debug patches https://review.openstack.org/499523 | 19:18 |
| *** openstack has joined #openstack-dragonflow | 19:44 | |
| *** ChanServ sets mode: +o openstack | 19:44 | |
| openstackgerrit | Shachar Snapiri proposed openstack/dragonflow master: [WIP][DNM]Test various debug patches https://review.openstack.org/499523 | 20:26 |
| openstackgerrit | Shachar Snapiri proposed openstack/dragonflow master: [WIP][DNM]Test various debug patches https://review.openstack.org/499523 | 20:56 |
| *** CrayZee has quit IRC | 21:02 | |
| openstackgerrit | Shachar Snapiri proposed openstack/dragonflow master: [WIP][DNM]Test various debug patches https://review.openstack.org/499523 | 21:15 |
| openstackgerrit | Shachar Snapiri proposed openstack/dragonflow master: [WIP][DNM]Test various debug patches https://review.openstack.org/499523 | 22:44 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!