| bgorski | Is there a better way than getting router port list and choosing the one from external network? | 00:01 |
|---|---|---|
| bgorski | What the IP address is not present in gateway_info inside router show command? | 00:02 |
| openstackgerrit | Jon Grimm proposed a change to openstack/neutron: Fix ml2 plugin for allowedaddresspairs tests https://review.openstack.org/58896 | 00:03 |
| openstackgerrit | dekehn proposed a change to openstack/neutron: extra_dhcp_opt add checks for empty strings https://review.openstack.org/59858 | 00:05 |
| *** openstackgerrit has quit IRC | 00:06 | |
| *** openstackgerrit has joined #openstack-neutron | 00:06 | |
| *** aymenfrikha has quit IRC | 00:07 | |
| *** aymenfrikha has joined #openstack-neutron | 00:07 | |
| *** alexpilotti has joined #openstack-neutron | 00:07 | |
| *** pete5 has quit IRC | 00:18 | |
| *** mlavalle has quit IRC | 00:19 | |
| *** matsuhashi has joined #openstack-neutron | 00:21 | |
| *** yfujioka has joined #openstack-neutron | 00:24 | |
| *** jp_at_hp has quit IRC | 00:26 | |
| *** SumitNaiksatam has joined #openstack-neutron | 00:27 | |
| *** alexpilotti has quit IRC | 00:28 | |
| *** layer427expert has joined #openstack-neutron | 00:36 | |
| layer427expert | does anyone have 5 minutes to answer a question on filter? | 00:38 |
| layer427expert | I need to get the list of members that have the same address from a given tenant | 00:38 |
| layer427expert | from looking at the code it is just a k,v list of field:value is this correct? | 00:39 |
| layer427expert | filter_foo = {"tenant_id":pool['tenant_id'], "address":"10.0.0.3"} | 00:40 |
| layer427expert | debug(self.plugin.get_members(self, context, fil, fields=None)) | 00:40 |
| layer427expert | example: debug(self.plugin.get_members(self, context, filter_foo, fields=None)) | 00:41 |
| *** dims has joined #openstack-neutron | 00:44 | |
| *** dims has quit IRC | 00:45 | |
| *** jgrimm has quit IRC | 00:55 | |
| *** Abhishe__ has quit IRC | 01:07 | |
| *** matsuhashi has quit IRC | 01:31 | |
| *** matsuhas_ has joined #openstack-neutron | 01:33 | |
| *** dims has joined #openstack-neutron | 01:39 | |
| *** Jianyong has joined #openstack-neutron | 01:46 | |
| *** dzyu has joined #openstack-neutron | 01:53 | |
| openstackgerrit | Aaron Rosen proposed a change to openstack/python-neutronclient: Fix neutron port-create --no-security-groups https://review.openstack.org/59836 | 01:56 |
| *** netavenger-jr has joined #openstack-neutron | 01:58 | |
| *** yuyangbj has joined #openstack-neutron | 01:58 | |
| yuyangbj | Hi sc68cal, are you there? | 01:59 |
| *** carl_baldwin has quit IRC | 01:59 | |
| *** yuyangbj has quit IRC | 02:03 | |
| *** aymenfrikha has quit IRC | 02:08 | |
| openstackgerrit | Shiv Haris proposed a change to openstack/neutron: Implementaion of Mechanism driver for Brocade VDX cluster of switches. https://review.openstack.org/60129 | 02:13 |
| *** yuyangbj has joined #openstack-neutron | 02:16 | |
| *** openstack has joined #openstack-neutron | 02:17 | |
| *** openstackgerrit has quit IRC | 02:24 | |
| *** openstackgerrit has joined #openstack-neutron | 02:24 | |
| openstackgerrit | Xiang Hui proposed a change to openstack/neutron: Sync dhcp_agent.ini with the codes https://review.openstack.org/59118 | 02:25 |
| *** bgorski has quit IRC | 02:33 | |
| *** mengxd has joined #openstack-neutron | 02:33 | |
| *** aymenfrikha has joined #openstack-neutron | 02:33 | |
| *** matsuhas_ has quit IRC | 02:35 | |
| *** dims has quit IRC | 02:37 | |
| *** banix has joined #openstack-neutron | 02:46 | |
| *** xdmeng has joined #openstack-neutron | 02:47 | |
| *** mengxd has quit IRC | 02:49 | |
| *** aymenfrikha has quit IRC | 02:59 | |
| *** Jianyong has quit IRC | 03:04 | |
| *** aveiga has joined #openstack-neutron | 03:11 | |
| *** HenryG has quit IRC | 03:11 | |
| *** chandankumar has joined #openstack-neutron | 03:17 | |
| *** Jianyong has joined #openstack-neutron | 03:17 | |
| *** Jianyong has quit IRC | 03:23 | |
| *** alagalah_ has joined #openstack-neutron | 03:32 | |
| *** alagalah_ has left #openstack-neutron | 03:33 | |
| *** banix has quit IRC | 03:33 | |
| openstackgerrit | Brian Haley proposed a change to openstack/neutron: Change l3-agent to periodically check children are running https://review.openstack.org/59997 | 03:35 |
| *** Jianyong has joined #openstack-neutron | 03:35 | |
| *** suresh12 has quit IRC | 03:36 | |
| *** suresh12 has joined #openstack-neutron | 03:37 | |
| *** banix has joined #openstack-neutron | 03:37 | |
| *** suresh12 has quit IRC | 03:41 | |
| *** suresh12 has joined #openstack-neutron | 03:42 | |
| *** shashank_ has quit IRC | 03:43 | |
| *** Jianyong has quit IRC | 03:44 | |
| *** suresh12 has quit IRC | 03:45 | |
| *** Jianyong has joined #openstack-neutron | 03:56 | |
| *** suresh12 has joined #openstack-neutron | 03:56 | |
| *** suresh12 has quit IRC | 04:00 | |
| *** Jianyong has quit IRC | 04:01 | |
| *** x86brandon has joined #openstack-neutron | 04:02 | |
| *** aveiga has quit IRC | 04:07 | |
| *** networkstatic has joined #openstack-neutron | 04:11 | |
| openstackgerrit | Aaron Rosen proposed a change to openstack/neutron: Bump api_workers from 0 to 4 https://review.openstack.org/59787 | 04:13 |
| *** matsuhashi has joined #openstack-neutron | 04:14 | |
| *** banix has quit IRC | 04:26 | |
| *** otherwiseguy has quit IRC | 04:40 | |
| *** Jianyong has joined #openstack-neutron | 04:43 | |
| *** otherwiseguy has joined #openstack-neutron | 04:52 | |
| *** amotoki has joined #openstack-neutron | 04:53 | |
| *** suresh12 has joined #openstack-neutron | 04:55 | |
| openstackgerrit | berlin proposed a change to openstack/neutron: Add Error Handling to NVP advanced LBaaS/FWaaS https://review.openstack.org/59625 | 04:57 |
| *** suresh12 has quit IRC | 05:01 | |
| *** marun has joined #openstack-neutron | 05:03 | |
| openstackgerrit | Brian Haley proposed a change to openstack/neutron: Change l3-agent to periodically check children are running https://review.openstack.org/59997 | 05:14 |
| *** yfried has quit IRC | 05:14 | |
| *** layer427expert has quit IRC | 05:14 | |
| *** Jianyong has quit IRC | 05:20 | |
| *** changbl has joined #openstack-neutron | 05:25 | |
| *** netavenger-jr has quit IRC | 05:31 | |
| *** garyk has quit IRC | 05:44 | |
| *** yamahata_ has quit IRC | 05:55 | |
| *** yfried has joined #openstack-neutron | 06:03 | |
| *** Jianyong has joined #openstack-neutron | 06:07 | |
| *** matsuhashi has quit IRC | 06:14 | |
| *** matsuhashi has joined #openstack-neutron | 06:14 | |
| openstackgerrit | A change was merged to openstack/python-neutronclient: Fix neutron port-create --no-security-groups https://review.openstack.org/59836 | 06:14 |
| openstackgerrit | Isaku Yamahata proposed a change to openstack/python-neutronclient: setup logger name of NeutronCommand automatically https://review.openstack.org/59310 | 06:30 |
| openstackgerrit | Jenkins proposed a change to openstack/neutron: Imported Translations from Transifex https://review.openstack.org/60156 | 06:31 |
| *** gdubreui has quit IRC | 06:32 | |
| *** alex_klimov has joined #openstack-neutron | 06:33 | |
| *** Abhishek has joined #openstack-neutron | 06:34 | |
| *** alex_klimov has quit IRC | 06:41 | |
| openstackgerrit | Xiang Hui proposed a change to openstack/neutron: Sync dhcp_agent.ini with the codes https://review.openstack.org/59118 | 06:42 |
| *** amritanshu_RnD has joined #openstack-neutron | 06:45 | |
| *** x86brandon has quit IRC | 06:48 | |
| *** Abhishek has quit IRC | 06:56 | |
| *** jpich has joined #openstack-neutron | 07:00 | |
| *** alex_klimov has joined #openstack-neutron | 07:06 | |
| openstackgerrit | A change was merged to openstack/neutron: Fix misspells https://review.openstack.org/59809 | 07:08 |
| *** alex_klimov has quit IRC | 07:08 | |
| *** alex_klimov has joined #openstack-neutron | 07:08 | |
| *** alex_klimov has quit IRC | 07:09 | |
| *** alex_klimov1 has joined #openstack-neutron | 07:10 | |
| *** dzyu has quit IRC | 07:14 | |
| *** matsuhashi has quit IRC | 07:17 | |
| *** jlibosva has joined #openstack-neutron | 07:18 | |
| *** nati_ueno has quit IRC | 07:24 | |
| *** jpich has quit IRC | 07:56 | |
| *** xdmeng has quit IRC | 07:57 | |
| *** mengxd has joined #openstack-neutron | 07:57 | |
| openstackgerrit | Akihiro Motoki proposed a change to openstack/neutron: Return request-id in API response https://review.openstack.org/58270 | 07:58 |
| *** harlowja has quit IRC | 08:08 | |
| *** nati_ueno has joined #openstack-neutron | 08:15 | |
| *** yuyangbj has left #openstack-neutron | 08:28 | |
| *** fouxm has joined #openstack-neutron | 08:32 | |
| *** salv-orlando has joined #openstack-neutron | 08:34 | |
| *** fouxm has quit IRC | 08:35 | |
| *** networkstatic has quit IRC | 08:36 | |
| *** fouxm has joined #openstack-neutron | 08:41 | |
| *** networkstatic has joined #openstack-neutron | 08:42 | |
| *** jp_at_hp has joined #openstack-neutron | 08:46 | |
| marun | amotoki: ping | 08:49 |
| amotoki | marun: pong | 08:49 |
| marun | amotoki: I have mixed feelings about the change to the request id patch. Given that it's something we're always going to want, why does it need to be a separate wsgi app? | 08:50 |
| marun | amotoki: I'm not sure swift is a good example. framkly. | 08:50 |
| marun | frankly | 08:50 |
| amotoki | marun: in my first implementation request-id is added in several places. I think it is better request-id is added in a single place in the pipeline. | 08:51 |
| marun | hmmm | 08:52 |
| marun | amotoki: I guess if that's the way to do it. | 08:53 |
| marun | amotoki: I'm going to suggest breaking the patch apart, though. | 08:53 |
| marun | amotoki: I think adding the faultwrap middleware should be one patch, and then a second patch can add request id support. | 08:54 |
| amotoki | marun: wsgi.Router is another poiint to add request-id. | 08:54 |
| marun | amotoki: If you think that the best way to do it is via middleware, I think that's ok. I simply think that adding the middleware should be added separately. It seems that it's primary value is actually in error handling, and then becomes a convenient place to add request id. | 08:56 |
| amotoki | marun: agree. | 08:56 |
| marun | amotoki: Is there a bug or otherwise a perceived need for the faultwrap middleware? i.e. are we leaking errors? | 08:56 |
| amotoki | marun: AFAIK no bug. | 08:57 |
| marun | amotoki: do you think it makes sense to add one? Or should it simply be tagged with Related-Bug? | 08:57 |
| amotoki | marun: when I add a code to raise exception in keystone context middleware, i see it in the response. | 08:57 |
| *** nati_ueno has quit IRC | 08:57 | |
| amotoki | marun: it is worht filed as a separate bug though it is a potential bug. | 08:58 |
| marun | amotoki: ah. and looking at the pipeline it looks like any global error handling in the neutron app wouldn't necessarily cover extensions anyway | 08:58 |
| *** jistr has joined #openstack-neutron | 08:58 | |
| marun | amotoki: +1 on filing a bug then. I think it's a good find. | 08:58 |
| amotoki | marun: will file it. | 08:59 |
| marun | amotoki: One more thing, have you seen the thread that discussed cross-application request id logging? | 08:59 |
| amotoki | marun: is it a part of the thread of request-id? | 09:00 |
| marun | amotoki: yes | 09:00 |
| amotoki | marun: i haven't caught up with the thread yet. | 09:00 |
| marun | amotoki: The part I think is important is that there appears to be consensus on how to handle cross-app request ids. | 09:01 |
| marun | amotoki: Basically, a service like neutron will check for a client-supplied request id and log it with a newly generated request id. | 09:01 |
| marun | amotoki: now that I think about it, though, that seems problematic :( | 09:02 |
| marun | amotoki: nothing stopping a malicious user from passing request ids that they receive back from a given service request and effectively poisoning the logs. | 09:03 |
| marun | amotoki: nevermind. | 09:03 |
| amotoki | marun: another idea is to log a returned request-id in a client side. | 09:04 |
| marun | amotoki: we can certainly do that, but I'm hoping to have the ability to debug nova-neutron integration. | 09:04 |
| marun | amotoki: ideally a call to nova to boot a vm would return a request id that could be used to track all the operations in the log associated with the initial request in both neutron and nova. | 09:05 |
| amotoki | marun: I think both approach will work though there is some difference. | 09:05 |
| marun | amotoki: ah, you mean that nova would log the returned request id… hmmm, I think that's a safer bet. | 09:08 |
| amotoki | marun: yes. | 09:08 |
| marun | amotoki: I'll suggest that on the mailing list | 09:08 |
| amotoki | marun: to do so, neutronclient needs to report request-id. | 09:09 |
| marun | amotoki: It would be more involved, mind you. It would require that every client request to explicitly log the request id when cross-service requests are made. | 09:09 |
| marun | amotoki: won't it be doing so anyway? | 09:09 |
| openstackgerrit | A change was merged to openstack/neutron: Handle exceptions on create_dhcp_port https://review.openstack.org/57812 | 09:10 |
| amotoki | marun: I think so too. it is not a case of nova neutron integration. It is better all clients support it. | 09:12 |
| marun | amotoki: agreed. I'm just using it as an example since it's the important one for neutron. | 09:12 |
| marun | amotoki: ideally this middleware becomes part of oslo and everyone uses the same one. | 09:12 |
| amotoki | marun: agree. the middleware should be a part of oslo. | 09:13 |
| amotoki | marun: if you have a better name of the middleware, please advise me. I think faultwrap is not best.... | 09:16 |
| *** yamahata_ has joined #openstack-neutron | 09:16 | |
| marun | amotoki: what about using the swift name? | 09:16 |
| anteaya | yeah I agree faultwrap is not a good name | 09:18 |
| anteaya | don't ask mordred for name suggestions though | 09:18 |
| anteaya | what is the swift name? | 09:18 |
| amotoki | A name like catch_error or faultwrap seems it focuses on error handling... | 09:18 |
| amotoki | I think the middleware is to do common things for all requests. | 09:19 |
| amotoki | At least i agree catch_error is better than faultwrap. | 09:20 |
| marun | amotoki: well, the primary utility of request id is in debugging faults | 09:20 |
| marun | amotoki: so at least it's peripherally related | 09:20 |
| anteaya | sitting here with dhellman, he doesn't have irc | 09:21 |
| anteaya | he asked for this idea to be posted to the mailing list, when you are ready | 09:21 |
| anteaya | does that sound reasonable? | 09:21 |
| *** nati_ueno has joined #openstack-neutron | 09:22 | |
| marun | amotoki: what idea? | 09:22 |
| marun | oops, anteaya ^ | 09:22 |
| amotoki | ? | 09:22 |
| marun | anteaya: the name? | 09:22 |
| anteaya | that this is a middleware that becomes part of oslo | 09:22 |
| marun | anteaya: right | 09:22 |
| anteaya | or did I mis-understand | 09:22 |
| marun | anteaya: no, I think we're on the same page | 09:23 |
| anteaya | okay | 09:23 |
| marun | anteaya: does doug want it to go into oslo asap or can the neutron patch be the POC? | 09:23 |
| marun | anteaya: we need request id traceability yesterday is all | 09:23 |
| *** jpich has joined #openstack-neutron | 09:24 | |
| anteaya | hi, marun, dhellmann taking over anteaya's keyboard for a sec | 09:24 |
| marun | anteaya: hi :) | 09:25 |
| anteaya | marun: you should probably go ahead and bring it into oslo asap | 09:25 |
| anteaya | marun: is it already used in >1 project? | 09:26 |
| marun | anteaya: I think swift is doing something similar, but I don't know what their attitude towards oslo is | 09:26 |
| marun | anteaya: we'll need this in both neutron and nova though | 09:26 |
| marun | anteaya: …and everywhere, actually. | 09:26 |
| anteaya | marun: ok, the typical path is to pull it into oslo if we know >1 proj wants it, but the api is not stable | 09:27 |
| marun | anteaya: I'd say we have a good case then. | 09:27 |
| anteaya | marun: if we can make the oslo version compatible for swift, great, but if not that is not a blocker | 09:27 |
| marun | amotoki: ^^ | 09:27 |
| anteaya | yep | 09:27 |
| anteaya | marun: any questions on process? | 09:28 |
| marun | amotoki: Sounds like the patch should be retargeted for oslo | 09:28 |
| marun | anteaya: I'm afraid I'm just the reviewer. amotoki has been working on the patch. | 09:28 |
| amotoki | marun: yeah. | 09:28 |
| marun | anteaya, amotoki: I think the patch as is can probably go in. I'd like to see a follow-on that ensures cross-service request id logging, but I think we still need to hash out the best approach on the mailing list. | 09:29 |
| amotoki | marun: swift one is a bit different: it uses X-Trans-Id and swift does not depend on webob. | 09:29 |
| anteaya | amotoki: send email to the -dev list if you have issues/questions and i or someone on the oslo team will help out | 09:29 |
| marun | amotoki: ah, sounds like you'll have to implement it fresh then. | 09:29 |
| anteaya | marun: sure, that might even be separate middleware but we can discuss later | 09:29 |
| marun | anteaya: fyi the subject of the list convo is '[openstack-dev] request-id in API response' | 09:30 |
| anteaya | marun: great, I'll look for that and reply under my own name :-) | 09:30 |
| amotoki | marun: anteaya: is it better to move the patch to oslo soon, or we continue to discuss in neutron? | 09:30 |
| marun | anteaya: cool, and thanks for stepping in. | 09:30 |
| marun | amotoki: I think the consensus was to do it in oslo instead of neutron. | 09:31 |
| amotoki | neutron-nova integration has high priority bugs. | 09:31 |
| amotoki | this is the only reason of my question. | 09:31 |
| anteaya | amotoki, marun: if you want to work it out in neutron first, that's ok too, but you're welcome to work through the oslo repo -- do the most pragmatic thing | 09:32 |
| marun | amotoki: I guess that's a question for anteaya - how fast can we bring a change in from oslo once merged. | 09:32 |
| anteaya | marun: that part should be easy, it's getting the change into oslo in the first place that may cause delay | 09:32 |
| anteaya | we tend to be picky about our apis :-) | 09:32 |
| marun | anteaya: it's not so complicated, at least. I'm guessing nova has already implemented request ids, too, so they probably have an opinion on the version that goes into oslo | 09:33 |
| anteaya | marun: probably want to add some of those devs as reviewers on the changeset, then | 09:34 |
| marun | anteaya: understood | 09:34 |
| marun | amotoki: are you familiar with the nova implementation of request ids? | 09:35 |
| amotoki | marun: to some extent. I read request-id nova code too. | 09:35 |
| anteaya | marun, amotoki: I need to go back to listening to the conference, but if you bring up questions on the -dev ml I will see them later today (use [oslo] in the subject) | 09:35 |
| marun | anteaya: ok, thanks for the help! | 09:36 |
| amotoki | anteaya: marun: thanks. I will reply to -dev list, but it will be after a couple of hours. | 09:37 |
| *** xdmeng has joined #openstack-neutron | 09:38 | |
| *** mengxd has quit IRC | 09:39 | |
| *** xdmeng has quit IRC | 09:39 | |
| *** mengxd has joined #openstack-neutron | 09:39 | |
| anteaya | I'm back as myself now | 09:40 |
| anteaya | glad you were able to get some direction on this | 09:40 |
| *** rossella_s has joined #openstack-neutron | 09:40 | |
| anteaya | speak up if you need more, and like Doug said, post with [oslo] in the subject | 09:40 |
| *** mengxd has quit IRC | 09:41 | |
| anteaya | hey rossella_s | 09:41 |
| rossella_s | hi anteaya | 09:41 |
| anteaya | how is your work with tempest going? | 09:41 |
| rossella_s | thanks for asking. Well I send 2 crs with api tests | 09:41 |
| rossella_s | I am trying now to analyze now the failure of the full tempest test for neutron. It's going pretty slow | 09:42 |
| anteaya | crs? | 09:43 |
| rossella_s | code review | 09:43 |
| rossella_s | patch | 09:44 |
| anteaya | ah | 09:44 |
| *** amuller has joined #openstack-neutron | 09:45 | |
| openstackgerrit | gongysh proposed a change to openstack/neutron: add router binding into firewall https://review.openstack.org/60190 | 09:45 |
| openstackgerrit | A change was merged to openstack/neutron: Imported Translations from Transifex https://review.openstack.org/60156 | 09:46 |
| openstackgerrit | gongysh proposed a change to openstack/neutron: add router binding into firewall https://review.openstack.org/60190 | 09:46 |
| anteaya | rossella_s: can you post the urls for the patches? | 09:46 |
| rossella_s | https://review.openstack.org/#/c/56349/ | 09:47 |
| rossella_s | https://review.openstack.org/#/c/56680/ | 09:47 |
| rossella_s | this is related, I've found a bug in the neutron xml client for tempest https://review.openstack.org/#/c/59029/ | 09:48 |
| anteaya | slow wifi here, I am looking at the status of the patches | 09:49 |
| *** gongysh has joined #openstack-neutron | 09:49 | |
| rossella_s | they are in a good shape | 09:50 |
| rossella_s | only this needs a core reviewer to take a look https://review.openstack.org/#/c/56349/ | 09:50 |
| openstackgerrit | A change was merged to openstack/neutron: atomically setup ovs ports https://review.openstack.org/59612 | 09:52 |
| anteaya | I'm trying to find out how to contact Zhi Kun Liu | 09:52 |
| *** markmcclain has joined #openstack-neutron | 09:54 | |
| anteaya | hedoesn't seem to be a foundation memeber | 09:54 |
| *** gongysh has quit IRC | 09:55 | |
| rossella_s | I don't know him | 09:56 |
| anteaya | Mark found him in the foundation dirctory | 09:57 |
| *** yamahata_ has quit IRC | 09:58 | |
| anteaya | he seems to be a tempest dev | 09:58 |
| *** markmcclain has quit IRC | 09:59 | |
| anteaya | his irc nick is zhikunliu | 09:59 |
| *** nati_ueno has quit IRC | 10:06 | |
| anteaya | rossella_s: 56349 has a new patchset, so you are looking for a neutron core to give a review? | 10:06 |
| rossella_s | anteaya: yes indeed | 10:07 |
| * rossella_s coffee | 10:08 | |
| anteaya | okay | 10:09 |
| *** bvandenh has joined #openstack-neutron | 10:14 | |
| *** Jianyong has left #openstack-neutron | 10:31 | |
| openstackgerrit | Jianing Yang proposed a change to openstack/neutron: Fix utils.str2dict and utils.dict2str's incorrect behavior on certain inputs https://review.openstack.org/60195 | 10:33 |
| openstackgerrit | Isaku Yamahata proposed a change to openstack/neutron: l3-agent-consolidation(WIP): framework for consolidating l3 agents https://review.openstack.org/57627 | 10:45 |
| openstackgerrit | A change was merged to openstack/neutron: Fix metering iptables driver doesn't read root_helper param https://review.openstack.org/59057 | 10:56 |
| *** amuller has quit IRC | 10:58 | |
| *** yfried has quit IRC | 10:58 | |
| openstackgerrit | A change was merged to openstack/neutron: Improve unit test coverage for Cisco plugin base code https://review.openstack.org/58882 | 11:00 |
| openstackgerrit | A change was merged to openstack/neutron: Fix bad call in port_update in linuxbridge agent https://review.openstack.org/59431 | 11:00 |
| openstackgerrit | A change was merged to openstack/neutron: metaplugin: use correct parameter to call neutron client https://review.openstack.org/57383 | 11:00 |
| *** yamahata_ has joined #openstack-neutron | 11:01 | |
| openstackgerrit | Berezovsky Irena proposed a change to openstack/neutron: Change daemon_endpoint default port https://review.openstack.org/60203 | 11:08 |
| *** yfried has joined #openstack-neutron | 11:13 | |
| *** jprovazn has joined #openstack-neutron | 11:15 | |
| *** yamahata_ has quit IRC | 11:15 | |
| fouxm | Hi, I'd like to give a MTU of 9000 in my VM. My physical interface is at 9050 but neutron intitates the tap at 1500. Is there a way to force the MTU with linuxbridge plugin (conf havana RC3, neutron / linuxbridge / vlan). Thx | 11:15 |
| *** yfried has quit IRC | 11:18 | |
| *** yfried has joined #openstack-neutron | 11:30 | |
| openstackgerrit | enikanorov proposed a change to openstack/neutron: Introduce Loadbalancer instance https://review.openstack.org/60207 | 11:31 |
| *** HenryG has joined #openstack-neutron | 11:32 | |
| *** pcm_ has joined #openstack-neutron | 11:37 | |
| *** pcm_ has quit IRC | 11:38 | |
| *** pcm_ has joined #openstack-neutron | 11:39 | |
| *** amuller has joined #openstack-neutron | 11:45 | |
| *** networkstatic is now known as networkstatic_zZ | 11:48 | |
| *** Sreedhar has joined #openstack-neutron | 11:48 | |
| *** lori has left #openstack-neutron | 11:49 | |
| openstackgerrit | Jianing Yang proposed a change to openstack/neutron: Fix str2dict and dict2str's incorrect behavior https://review.openstack.org/60195 | 11:49 |
| *** rkukura has quit IRC | 11:58 | |
| *** amuller has quit IRC | 12:03 | |
| *** amuller_ has joined #openstack-neutron | 12:03 | |
| *** amuller_ has quit IRC | 12:09 | |
| *** bashok has joined #openstack-neutron | 12:10 | |
| *** jojo_ has joined #openstack-neutron | 12:17 | |
| jojo_ | have been stressing add/remove floating-ips (10) between several instances (20) and after a while floating-ip network stops working | 12:19 |
| jojo_ | its an havana/neutron/ovs/gre | 12:19 |
| jojo_ | and if l2 agent is restarted on compute nodes, service is restored | 12:20 |
| *** amuller_ has joined #openstack-neutron | 12:25 | |
| *** yfujioka has quit IRC | 12:27 | |
| Sreedhar | marun, slav-orlando: For the neutron server performance issue during concurrent instance deployment, After merging the changes with multiple neutron-server process patch https://review.openstack.org/#/c/37131/ able to deploy 240 instances in Havana as well. 2 instances out of 240 went to error state, thats due to Too many connections to SQL Database | 12:39 |
| Sreedhar | marun, slav-orlando: But during the instance first boot only 81 instances could get an IP. Network ports are getting created and IP Address are allocating very fast but by the time port is made up its taking close to 153 seconds.. In Grizzly i have tested many times we did not had these issues till 210 instances | 12:41 |
| Sreedhar | marun, slav-orlando:In Grizzly just a reboot of the instance could get the IP Address during boot, but in Havana we need to restart the DHCP agent, dnsmasq process followed by instance reboot. This clearly shows there is a performance regression in Neutron/Horizon compared to Grizzly | 12:42 |
| *** dims has joined #openstack-neutron | 12:51 | |
| HenryG | Sreedhar: great info! | 12:54 |
| *** bashok has quit IRC | 12:54 | |
| HenryG | Sreedhar: how many api_workers did you configure? | 12:54 |
| HenryG | Sreedar: you should report this info to the dev ML. Not everyone catches all the IRC msgs | 12:55 |
| *** ihrachyska has quit IRC | 13:01 | |
| HenryG | Sreedhar: I am looking for the change(s) that caused the need to restart the dhcp agent and dnsmasq process. Do you know the change(s)? | 13:03 |
| Sreedhar | HenryG: My VM has 8cores/16 hyperthreads, so i set api_workers to 8 | 13:04 |
| *** ihrachyska has joined #openstack-neutron | 13:04 | |
| Sreedhar | HenryG: Have updated my findings in this bug - https://bugs.launchpad.net/neutron/+bug/1192381 | 13:05 |
| Sreedhar | HenryG: When doing the tests with Grizzly initially i had the same issues like need to restart DHCP agent/dnsmasq to get IP address. But after tuning the SQL pool parameters, agent_down_time and report_interval, just rebooting the instance would have suffice | 13:06 |
| *** salv-orlando_ has joined #openstack-neutron | 13:06 | |
| *** bvandenh has quit IRC | 13:07 | |
| Sreedhar | HenryG: But in Havana, I have tuned the same values but still having the issue | 13:08 |
| *** salv-orlando has quit IRC | 13:09 | |
| *** salv-orlando_ is now known as salv-orlando | 13:09 | |
| *** amuller_ has quit IRC | 13:09 | |
| HenryG | Sreedhar: Thanks, great info to have! | 13:10 |
| Sreedhar | HenryG: In the bug https://bugs.launchpad.net/neutron/+bug/1192381, issue documented is ports info is not getting updated in dnsmasq host file, But in my case, ports info is getting updated in dnsmasq host file but with a delay of close to 153 seconds | 13:11 |
| HenryG | Sreedhar: so that sounds like the underlying issue is the time taken to bring the ports up? | 13:13 |
| HenryG | Sreedhar: if the time is too long, something times out and the dnsmasq host file never gets updated? | 13:14 |
| Sreedhar | HenryG: In my case dnmasq is getting updated but with a delay | 13:18 |
| Sreedhar | HenryG: I could even ping the IP address of those instances. Due to this delay, tools like cloud-init could not configure due to network not available at that time. But if we reboot the instance (without rebooting dnsmasq) instance not getting the IP and i can't even ping the IP address | 13:19 |
| *** yamahata_ has joined #openstack-neutron | 13:25 | |
| *** yamahata_ has quit IRC | 13:26 | |
| *** yamahata_ has joined #openstack-neutron | 13:26 | |
| marun | Sreedhar: hi | 13:26 |
| Sreedhar | marun: Hi, multiple api workers patch changes helped to create 240 instances in havana as well. Without that patch and single worker thread, i could create only 150 instances with 30 concurrent requests | 13:27 |
| anteaya | HenryG: the channel is logged and the logs are found here: http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/ | 13:28 |
| anteaya | I'm encouraging conversations to take place in the channel and for people to read the logs | 13:28 |
| anteaya | it helps improve the speed of addressing topics | 13:29 |
| anteaya | and mailing list for items that need more input including input from other projects | 13:30 |
| marun | Sreedhar: so, improvement. | 13:30 |
| marun | Sreedhar: I was wondering whether it might make sense to have multiple workers for rpc processing as well | 13:30 |
| *** amuller_ has joined #openstack-neutron | 13:30 | |
| marun | Sreedhar: since the bottleneck now appears to be rpc-related rather than wsgi-related | 13:31 |
| marun | Sreedhar: The other option is to simply profile the code paths associated with booting a VM. There is clearly room for improvement. | 13:31 |
| *** amuller_ is now known as amuller | 13:31 | |
| Sreedhar | marun: multiple rpc processing might help.. Note, these kind of issues we get with high concurrent requests with X number of neutron ports already exists | 13:32 |
| marun | Sreedhar: The load is tiny, though. | 13:32 |
| marun | Sreedhar: Or rather, should be. | 13:32 |
| Sreedhar | marun: I think delay is not in booting the VM paths.. Delay is between port create/ip allocate till port is made up - In the email, i have shared the timing and logs | 13:33 |
| *** matrohon has quit IRC | 13:33 | |
| marun | Sreedhar: I'm afraid I'm not being clear | 13:33 |
| marun | Sreedhar: The delay is related to nova as much as anything else, since creating a port in neutron is only part of the story. | 13:34 |
| marun | Sreedhar: The port allocation on the compute node is triggered by nova-compute. | 13:34 |
| marun | Sreedhar: I'm saying, there needs to be profiling of all the pieces in the chain to find the bottlenecks and speed them up. | 13:35 |
| *** changbl has quit IRC | 13:35 | |
| marun | Sreedhar: recording the total time and taking potshots at what we think might be the problem isn't a very effective strategy. | 13:35 |
| marun | Sreedhar: does that make sense? | 13:37 |
| Sreedhar | marun: During the instance creation, network ports are being created and IP is getting allocated very fast from the logs. In each compute node approximately 2 instances would create in each batch. But the OVS agent in compute nodes are getting many rpc timeout messages for security_group_rules_for_devices | 13:37 |
| Sreedhar | marun: If you can guide me where to profile, i am happy to do that and collect logs | 13:37 |
| marun | Sreedhar: Right, because those rpc requests are all hitting a single process. | 13:38 |
| marun | Sreedhar: I notice from your email that you are using m1.small. Are you aware that devstack actually has an option for m1.nano, consuming only 64gb of ram? | 13:39 |
| Sreedhar | marun: yes, during my tests, i wanted to simulate close to customer environment, so i have used m1.small. | 13:41 |
| marun | Sreedhar: So you're not using cirros images then? | 13:41 |
| Sreedhar | marun: I am using the Ubuntu Cloud Archive | 13:42 |
| marun | Sreedhar: For the purposes of testing the kinds of issues we are seeing, I don't see any advantage to using large VMs | 13:42 |
| marun | Sreedhar: In fact, the large ops gate uses a null virt driver (I think) that doesn't even use real vm's | 13:42 |
| marun | Sreedhar: Narrowing issues related to networking doesn't actually require VM's, just endpoints that can behave as they do. | 13:43 |
| marun | salv-orlando: are there any docs on the large ops gate? I'd like to start using that in the hopes of speeding up iteration around these issues. | 13:44 |
| salv-orlando | marun: I don't there is any documentation. I learned how it works looking at the configuration options for tempest and devstack in devstack-gate.yaml (project openstack-infra/config.git) | 13:46 |
| marun | salv-orlando: gotcha, thanks | 13:46 |
| *** matrohon has joined #openstack-neutron | 13:47 | |
| salv-orlando | marun: https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/devstack-gate.yaml#L374 | 13:47 |
| marun | salv-orlando: hmmm. what do those environment variables configure? | 13:48 |
| marun | salv-orlando: devstack? or some helper script? | 13:48 |
| salv-orlando | They pass parameters into the wrapper script of devstack-gate | 13:49 |
| salv-orlando | openstack-infra/devstack-gate.git | 13:49 |
| marun | ah, ok | 13:49 |
| salv-orlando | if you want to use that for reproducing a similar job locally on a infrastructure which is not the same as the upstream, they're very little useful | 13:50 |
| marun | definitely | 13:51 |
| marun | i feel pretty dumb for having been using real vm's up until now | 13:51 |
| salv-orlando | the bottom line for the large ops is that: | 13:51 |
| salv-orlando | 1) set the number of vm to 150, 2) use the fake_virt driver, 3) run tox -elarge-ops | 13:52 |
| jojo_ | any clue about connection on floating ips being lost after stressing add-remove operations? | 13:52 |
| salv-orlando | jojo_: this is something which we thought has been fixed in havana; notifications where treated in the wrong way on the agent allowing processing messages out of order | 13:53 |
| salv-orlando | If you have a repro script that shows this is happening still, please share it | 13:53 |
| salv-orlando | marun: and btw for testing scalability of nova/neutron the fake virt driver is good, but for many tests you need real vms | 13:54 |
| salv-orlando | because otherwise you won't be stressing the agents, as no VIFs would show up on the integration bridge | 13:54 |
| marun | salv-orlando: hmm, I didn't realize that | 13:55 |
| marun | salv-orlando: I think it's heinous that the lxc support was dropped | 13:55 |
| jojo_ | well, i am able to reproduce it in a small setup, 2 compute nodes, with 20 vms and rotating 5 floating-ips | 13:55 |
| marun | salv-orlando: it would have been perfect for neutron testing | 13:55 |
| jojo_ | connection is restored when l2 agent is restarted on compute nodes | 13:55 |
| salv-orlando | jojo_: the l2 agent? That's interesting. Are you rotating floating IPs or also rebooting instances? | 13:56 |
| jojo_ | its a neutron/ovs/gre setup | 13:56 |
| jojo_ | when neutron-openvswitch-plugin is restarted | 13:57 |
| *** jistr has quit IRC | 13:57 | |
| jojo_ | conenction is working again | 13:57 |
| jojo_ | i am rebooting instances too | 13:57 |
| jojo_ | but when they have no floating-ip attached | 13:58 |
| *** jistr has joined #openstack-neutron | 13:58 | |
| salv-orlando | jojo_: got it. I was asking about the reboot thing because I am trying to understand if this is an issue so far unknown on the l3 agent or one of the issues we already working on the ovs agent and dhcp agent | 13:59 |
| *** jecarey has joined #openstack-neutron | 14:00 | |
| jojo_ | ok | 14:00 |
| salv-orlando | A perfect test for isolating the problem would be to a simple scree with keeps disassociating floating IPs from an instance and association it to another instance | 14:00 |
| salv-orlando | without rebooting any. | 14:00 |
| salv-orlando | Is that a test you could do? If you don't have a test-env I can do it or find somebody to do that, but it might take a while. | 14:01 |
| jojo_ | didnt think rebooting had anything to do | 14:01 |
| jojo_ | i can do it | 14:01 |
| salv-orlando | ok, that would be great; and if you collect the logs that would allows to gain an understanding of what's going on. | 14:01 |
| jojo_ | right now, gonna run a test where floating-ip are rotated continuosly | 14:01 |
| openstackgerrit | Édouard Thuleau proposed a change to openstack/neutron: Add local ARP responder to the OVS agent (WIP) https://review.openstack.org/49227 | 14:12 |
| *** yamahata_ has quit IRC | 14:12 | |
| *** yamahata_ has joined #openstack-neutron | 14:12 | |
| *** julim has joined #openstack-neutron | 14:12 | |
| *** dims has quit IRC | 14:12 | |
| Sreedhar | marun: regarding instance not able to get ip, we see this issue more consistency if we have already some number of neutron ports exists. Does the active number of neutron ports play any role in rpc timeouts. If yes, does tuning more number of nova-conductor process helps anyway | 14:12 |
| marun | Sreedhar: the number of database records is likely a contributor to performance degredation | 14:12 |
| marun | Sreedhar: nova-conductor wouldn't have anything to do with it - that's nova only | 14:12 |
| openstackgerrit | Édouard Thuleau proposed a change to openstack/neutron: Add local ARP responder to the OVS agent https://review.openstack.org/49227 | 14:12 |
| *** dims has joined #openstack-neutron | 14:12 | |
| marun | Sreedhar: oh, wait. the mysql error is nova | 14:12 |
| openstackgerrit | Édouard Thuleau proposed a change to openstack/neutron: Add local ARP responder to the OVS agent https://review.openstack.org/49227 | 14:12 |
| marun | Sreedhar, salv-orlando: The QueuePool settings are db-connection related, so doesn't there need to be coordination between all openstack services to ensure that the mysql connection limit is not reached? | 14:12 |
| Sreedhar | marun: I am using mysql as a database. Does any tuning to database will help (I am planning to increase max_connections). or more number of RabbitMQ servers helps | 14:12 |
| openstackgerrit | A change was merged to openstack/neutron: Midonet to support port association at floating IP creation https://review.openstack.org/55792 | 14:12 |
| marun | Sreedhar: It's a db issue. I seriously doubt that rabbitmq is overloaded in these scenarios. | 14:12 |
| *** heyongli has joined #openstack-neutron | 14:12 | |
| marun | Sreedhar: The problem is that the processing of rpc messages is db-bound in general and cpu bound in the case of the neutron service since it's single process. | 14:12 |
| *** carl_baldwin has joined #openstack-neutron | 14:12 | |
| salv-orlando | marun: if you don't tune those parameters appropriately you risk getting the "mysql has gone away" error for instance, because all the project might use more connection than what mysql-server allows | 14:13 |
| Sreedhar | marun: With carl's patch when i set api_workers to 8, it started 8 neutron-server process. You mean to say these 8 process only serve api requests, but single neutron-server process will use for rpc requests | 14:13 |
| marun | Sreedhar: correct. | 14:14 |
| salv-orlando | but whether the coordination should pertain to openstack, that's a question I'm not able to answer. I see it as a configuration management problem, but I am far from being an expert on the matter. | 14:14 |
| marun | salv-orlando: funny how development and operations bleed together.... | 14:15 |
| salv-orlando | Sreedhar: yeah, that was the part we made sure of during review. There's always only one worker handling AMQP messages. | 14:15 |
| jojo_ | salv-orlando: the test is already running for 15 minutes and connection is up for all 8 floating-ips | 14:15 |
| jojo_ | salv-orlando: gonna let it run for 15-20 more mins | 14:15 |
| salv-orlando | jojo_: let's play the waiting game then... | 14:15 |
| marun | salv-orlando, Sreedhar: I've asked carl_baldwin on the mailing list whether it would be possible to add multiple workers for RPC. | 14:15 |
| jojo_ | ;) | 14:15 |
| marun | salv-orlando: is there any overriding reason not to? i.e. not safe for concurrency? | 14:16 |
| salv-orlando | jojo_: neutron is more "eventually fallible" than "eventually consistent" | 14:16 |
| salv-orlando | Meaning that if you keep it running, it will eventually fail :) | 14:16 |
| marun | lol | 14:16 |
| jojo_ | :| | 14:17 |
| salv-orlando | marun: we discussed this with markmclain. Do not remember the reason on top of my head, but we were worried about the fact this might have increased the occurrence of mysql/eventlet deadlocks | 14:18 |
| marun | *sigh* | 14:18 |
| marun | I'll have to censor myself at this point.' | 14:18 |
| salv-orlando | or you can move to a non-logged channel if you are looking for venting some frustration | 14:19 |
| marun | Although, throwing eventlet under a bus doesn't seem like such a bad idea. | 14:19 |
| marun | good old process-based concurrency is looking pretty good right about now. all the problems one has to worry about are up-front and not hidden, and I think that's a bette approach. | 14:19 |
| *** afazekas has quit IRC | 14:20 | |
| salv-orlando | the other reason was that with multiple consumers/producers on the AMQP bus, there was a chance of out-of-order message processing and repeated notifications | 14:21 |
| *** peristeri has joined #openstack-neutron | 14:21 | |
| marun | salv-orlando: that sounds like a problem somebody in the universe might have already given some thought to, no? | 14:22 |
| *** Ken has joined #openstack-neutron | 14:22 | |
| *** Ken is now known as Guest84874 | 14:23 | |
| marun | salv-orlando: sorry :( | 14:24 |
| *** jojo_ is now known as wolf | 14:24 | |
| *** wolf is now known as jojo_ | 14:24 | |
| *** clev has joined #openstack-neutron | 14:27 | |
| salv-orlando | marun: of course I would not dare to say the problem can't be solved. Perhaps I won't be able to solve it, but this is another story ;) I was just saying that it was a risk we did not want to take in the last days of the last milestone | 14:28 |
| marun | salv-orlando: yeah, that's why I was apologizing. We're gated by non-technical concerns as much as anything at this point. | 14:28 |
| salv-orlando | pretty much the same reason for which we decided not to default to ovsdbmonitor polling manager for havana | 14:29 |
| marun | salv-orlando: don't you mean 'decided not to merge polling minimization for havana?' ;) | 14:30 |
| salv-orlando | no we merged it I think - in rc phase? | 14:30 |
| salv-orlando | we decided not to make it the default approach | 14:31 |
| *** otherwiseguy has quit IRC | 14:31 | |
| *** Guest84874 has quit IRC | 14:31 | |
| *** otherwiseguy has joined #openstack-neutron | 14:31 | |
| marun | salv-orlando: hmmm, maybe my patch was just half-assed. that sounds more likely. good thing it wasn't made the default! | 14:32 |
| *** markmcclain has joined #openstack-neutron | 14:32 | |
| marun | salv-orlando: nope, I was right the first time. It didn't make it into havana at all. | 14:32 |
| marun | salv-orlando: we still have to backport it. | 14:32 |
| salv-orlando | marun: sorry about that I thought we merged it by RC-2 | 14:33 |
| marun | salv-orlando: hoping to lean on otherwiseguy for that | 14:33 |
| salv-orlando | I am happy to support the back port even if the patches are rather large | 14:33 |
| salv-orlando | though I don't have +2 power on stable patches | 14:33 |
| marun | salv-orlando: who does? I think we're going to need more manpower on that this month | 14:33 |
| carl_baldwin | marun: Just found your question in the mailing list. Will respond. | 14:34 |
| salv-orlando | marun from our team I think it's arosen and markmcclain | 14:34 |
| salv-orlando | and garyk | 14:34 |
| marun | carl_baldwin: appreciated. though I think salv-orlando might have answered it in the channel (order-of-operations and mysql/eventlet deadlocks) | 14:34 |
| *** carl_baldwin has quit IRC | 14:34 | |
| *** rkukura has joined #openstack-neutron | 14:35 | |
| anteaya | marun: did you want to be a stable patch approver? | 14:35 |
| anteaya | I agree it would be great to have more | 14:35 |
| markmcclain | we've have 3 stable reviewers on our team | 14:36 |
| markmcclain | arosen, garyk, and me | 14:36 |
| markmcclain | if you propose the backports we'll review them | 14:36 |
| marun | markmcclain: is there a need for more? | 14:36 |
| jojo_ | salv-orlando: well, i am pretty sure there's no problem now, 35 minutes of test | 14:36 |
| marun | markmcclain: or is the current team sufficient? | 14:36 |
| markmcclain | we could use a few more, but teh stable team looks for a consistent record of reviewing stable patches | 14:37 |
| anteaya | how's your review record of stable patches, marun? | 14:37 |
| markmcclain | stable core is also cross project | 14:37 |
| marun | anteaya: middling: http://russellbryant.net/openstack-stats/neutron-reviewers-30.txt | 14:37 |
| markmcclain | so it requires proposal and lazy consensus | 14:38 |
| marun | anteaya: scratch that, non-existent. I have only been reviewing master. | 14:38 |
| salv-orlando | jojo_: perhaps the reboots have a role then. This might explain why you need to restart the l2 agent. I would look at port occasionally not being rewired or being rewired very late | 14:38 |
| salv-orlando | I need to switch off for 2.5 hours now. Will back later. | 14:38 |
| anteaya | marun: ah okay, so I encourage stable approval if that is something that you want | 14:39 |
| salv-orlando | * Will be back | 14:39 |
| jojo_ | hummmm | 14:39 |
| anteaya | marun: sounds like you have an idea of the path to get there, yeah? | 14:39 |
| jojo_ | will try to get more info | 14:39 |
| openstackgerrit | A change was merged to openstack/neutron: Improve unit test coverage for Cisco plugin nexus code https://review.openstack.org/57100 | 14:39 |
| marun | anteaya: yes | 14:39 |
| jojo_ | this sounds like a big drawback | 14:39 |
| marun | markmcclain: so, dumb question. | 14:39 |
| anteaya | marun: go you \o/ | 14:39 |
| jojo_ | if no tunning/tweaking possible to fix it | 14:39 |
| markmcclain | marun: no dumb questions | 14:40 |
| marun | markmcclain: I see an awful lot of patches being proposed that don't seem to apply to 1) stability or 2) parity | 14:40 |
| marun | markmcclain: wasn't the goal to minimize the review load while we are in crisis mode? Or are some people just not getting the memo? | 14:40 |
| markmcclain | the goal was focus on stability and parity | 14:40 |
| * anteaya thinks marun is asking a great question | 14:40 | |
| markmcclain | for the most part we've done it | 14:41 |
| markmcclain | there are also some bug fixes for existing code | 14:41 |
| markmcclain | which are generally acceptable | 14:41 |
| marun | How does a reviewer know whether a patch is valid or not? | 14:41 |
| marun | people can keep churning on 'bug fixes' ad infinitum, though. there are tons of things to 'fix' that aren't necessarily important | 14:41 |
| markmcclain | it's the bug severity is critical/high | 14:41 |
| marun | ah, ok. | 14:42 |
| markmcclain | then that is acceptable | 14:42 |
| markmcclain | if there are low priority items | 14:42 |
| anteaya | perhaps I need to create a list somewhere to help reviewers? | 14:42 |
| markmcclain | it is really up to the reviewer if they want to review | 14:42 |
| anteaya | would that help? | 14:42 |
| anteaya | similar to the gate blocking bug roundup on the meeting agenda | 14:42 |
| markmcclain | if the severity of the bug is unknown feel free to ping the channel | 14:42 |
| marun | markmcclain: That sounds alot like 'anything goes' though. so long as reviewers are willing. | 14:43 |
| markmcclain | well low priority items are always on a has time available basis | 14:43 |
| anteaya | I'm in agreement with marun, it would be great to have some sort of system to assist with reviewer focus | 14:43 |
| markmcclain | if you've reviewed all of the urgent items | 14:43 |
| *** mjbright_ has joined #openstack-neutron | 14:43 | |
| markmcclain | then it is still helpful to review the items with lesser priority | 14:43 |
| marun | markmcclain: I think my question is as much about the patches people are pushing as the cost of reviewing them, tough. | 14:44 |
| markmcclain | some of hte bug fixes actually improve the stability of certain plugins | 14:44 |
| *** amotoki_ has joined #openstack-neutron | 14:44 | |
| marun | markmcclain: Why are people allowed to push low priority patches when we have urgent issues that need addressing? | 14:44 |
| markmcclain | and once more entities implement 3rd party testing I expect there will more of those type bugs | 14:44 |
| markmcclain | we are an open community, so anyone can propose anything | 14:45 |
| *** carl_baldwin has joined #openstack-neutron | 14:45 | |
| marun | markmcclain: …with predictable results, frankly. | 14:45 |
| markmcclain | but as a community we can decide the priority that we review the proposals | 14:45 |
| anteaya | great | 14:45 |
| anteaya | so if I were to create an etherpad with links to reviews | 14:46 |
| anteaya | perhaps as a group we can discuss the priority? | 14:46 |
| anteaya | with bug fix priority referenced for the patch url | 14:46 |
| anteaya | I'll do that and then let's see how that gets used | 14:46 |
| marun | anteaya: I think mark might have been referring to the priority in launchpad | 14:46 |
| markmcclain | you can just use this link: https://bugs.launchpad.net/neutron/+bugs?search=Search&field.importance=Critical&field.importance=High&field.status=New&field.status=Confirmed&field.status=Triaged&field.status=In+Progress | 14:47 |
| mestery | so, along those lines, I see a lot of reviews proposed with the bug priority set to unknown ... | 14:47 |
| mestery | In cases like that, I usually set the bug to low priority, but it's somewhat bothered me that people submit patches for bugs without a priority. | 14:47 |
| markmcclain | well not everyone can set priority | 14:48 |
| mestery | Ah, got it. Thanks markmcclain, didn't know that. | 14:48 |
| markmcclain | someone with triage rights has to set it | 14:48 |
| mestery | OK, so I guess I'm actually doing my job by setting priority then :) | 14:48 |
| marun | it kind of bothers me when people submit patches without talking to anybody about it, frankly. | 14:48 |
| anteaya | markmcclain: who has triage rights currently? | 14:49 |
| markmcclain | the priority of a bug is wrong or unknown feel free to ping the room | 14:49 |
| markmcclain | the core team should have it | 14:49 |
| mestery | got it, thanks | 14:49 |
| markmcclain | if you don't PM me | 14:49 |
| * mestery nods | 14:49 | |
| * markmcclain steps away from keyboard for a bit | 14:49 | |
| *** markmcclain has quit IRC | 14:49 | |
| *** mjbright_ has quit IRC | 14:49 | |
| carl_baldwin | marun: Mysql/eventlet blocking seems to be the deeper problem. Scaling out workers was meant to be a stop-gap to alleviate it. | 14:53 |
| *** jojo_ is now known as _jj_ | 14:53 | |
| HenryG | Does gerrit have a way of ordering the review queue by priority of the bug(s) they reference? | 14:53 |
| marun | carl_baldwin: so I guess the short-term solution for rpc will be profiling and optimizing the hot paths | 14:53 |
| marun | HenryG: I don't believe so, but you should be able to work some magic with one of the gerrit cli tools. | 14:54 |
| anteaya | marun: thanks for bringing up the conversation | 14:55 |
| anteaya | I agree that patch submission/review should be following our stated focus for the project | 14:55 |
| anteaya | and outliers to that focus should be discussed | 14:55 |
| carl_baldwin | HenryG: This isn't exactly what you asked for but this page is an attempt at ordering reviews by priority: http://status.openstack.org/reviews/. It would be nicer if gerrit could do this. it would need to get the priority from launchpad. I'm not sure if it can do that. | 14:56 |
| marun | anteaya: :\ a bit too agro. Even knowing what to expect with opensource I still find it frustrating that we can't coordinate on priorities more effectively. But as Mark suggests, participants can't be ordered about. | 14:57 |
| carl_baldwin | marun: Multiple RPC workers could also alleviate it in the short term. Is there a case where the RPC process is still CPU bound after separating out the API worker processes? (Sorry if I missed some context up in the channel) | 14:58 |
| *** s3wong has joined #openstack-neutron | 14:59 | |
| marun | carl_baldwin: when we use multiple wsgi workers, rpc requests from the agents become the bottleneck | 15:00 |
| carl_baldwin | marun: I see | 15:01 |
| *** networkstatic_zZ is now known as networkstatic | 15:01 | |
| marun | carl_baldwin: but according to markmcclain and salv-orlando, it isn't possible to trivially use multiple workers for rpc because processing rpc requests out of sequence can be dangerous | 15:02 |
| *** networkstatic has quit IRC | 15:02 | |
| *** Mr_W has joined #openstack-neutron | 15:02 | |
| *** networkstatic has joined #openstack-neutron | 15:03 | |
| enikanorov_ | marun: I'd like to comment on your question | 15:03 |
| marun | carl_baldwin: i was talking to salv-orlando yesteray about this and I think we came to agree that rate limiting and optimizing hot spots might be the best short-term solution, short of rearchitecture | 15:03 |
| marun | enikanorov_: do tell | 15:03 |
| enikanorov_ | I think we should not prohibit patches which introduce new features. Or otherwise we will distract a part of community | 15:04 |
| enikanorov_ | that are expecting them and working on them | 15:04 |
| enikanorov_ | poeople are aware of what core team focus is right now | 15:04 |
| marun | enikanorov_: you don't have to worry. It's only me that thinks its stupid to continue business as usual. | 15:04 |
| carl_baldwin | marun: was that discussion in the channel? I could go read the logs. | 15:04 |
| marun | carl_baldwin: yes, it was in the channel | 15:04 |
| *** alagalah has joined #openstack-neutron | 15:05 | |
| openstackgerrit | A change was merged to openstack/neutron: Fix MeteringLabel model to not clear router's tenant id on deletion https://review.openstack.org/56041 | 15:05 |
| enikanorov_ | the 'business' is actually core's which prioritize their time. and lots of other folks may be not so deeply involved in neutron to help with quite complex problems that gate tests has uncovered | 15:05 |
| *** alagalah has left #openstack-neutron | 15:06 | |
| marun | enikanorov_: I think feature development is completely broken, at present. | 15:06 |
| marun | enikanorov_: people are free to merge patches without real tests. | 15:06 |
| marun | enikanorov_: unit tests prove nothing | 15:06 |
| enikanorov_ | marun: I think Icehouse has a new policy for that | 15:06 |
| marun | enikanorov_: so 'feature' additions are as likely to make stability worse. | 15:06 |
| enikanorov_ | to address this exact issue | 15:07 |
| enikanorov_ | in our process | 15:07 |
| marun | enikanorov_: how is it being enforced exactly? | 15:07 |
| marun | enikanorov_: people merge patches | 15:07 |
| *** Vijay__ has joined #openstack-neutron | 15:07 | |
| marun | enikanorov_: eventually (hopefully) tempest or functional patches merge | 15:07 |
| enikanorov_ | well, it is enforced as usual | 15:07 |
| marun | enikanorov_: if they don't, how do do we remove those patches? | 15:07 |
| marun | enikanorov_: i.e. it is not enforced. | 15:07 |
| *** mjbright_ has joined #openstack-neutron | 15:07 | |
| enikanorov_ | you go and put -2 until you see a patch passing specific tempest tests | 15:07 |
| *** heyongli has quit IRC | 15:07 | |
| marun | enikanorov_: that means absolutely nothing without good tempest coverage | 15:08 |
| enikanorov_ | which are not present | 15:08 |
| enikanorov_ | so you -2 until tempest has test | 15:08 |
| marun | enikanorov_: except that we can't merge a tempest test until the feature exists | 15:08 |
| marun | enikanorov_: --> broken | 15:08 |
| enikanorov_ | well, there could be such cases as well | 15:08 |
| carl_baldwin | marun: I will read up on it in the log. I think it is already possible to run more than one RPC message processor. If the neutron server process is run on multiple hosts in active/active I think you end up getting multiple independent RPC processing threads unless I'm missing something. | 15:09 |
| marun | enikanorov_: so this policy, does it require that a given feature have an integration test in review before merge? | 15:09 |
| marun | enikanorov_: I haven't seen evidence of this, but I might simply be ignorant. | 15:09 |
| marun | carl_baldwin: is active/active an option? | 15:10 |
| enikanorov_ | marun: that is how I understand the policy. just like you said. | 15:12 |
| *** _jj_ has quit IRC | 15:12 | |
| marun | enikanorov_: Is there documentation you can point me to? | 15:12 |
| openstackgerrit | dekehn proposed a change to openstack/neutron: extra_dhcp_opt add checks for empty strings https://review.openstack.org/59858 | 15:12 |
| carl_baldwin | marun: I think so but I will confirm that is the case. I'm running neutron server on multiple hosts and I think that the RPC processor is active on both. I'm certain that the API server is active on both. | 15:12 |
| marun | enikanorov_: It sounds like I am simply ignorant. | 15:12 |
| enikanorov_ | marun: no, i based by understanding on the summit session | 15:12 |
| *** _jj_ has joined #openstack-neutron | 15:12 | |
| enikanorov_ | where it was discussed | 15:12 |
| marun | enikanorov_: fair enough. I worry that this detail is getting lost in the shuffle. | 15:13 |
| enikanorov_ | it was primarily about vendor-specific stuff, but obviously as we targeting stability, the same should be applied to core functionality as well | 15:13 |
| marun | enikanorov_: I would tend to agree. | 15:13 |
| marun | carl_baldwin: Hmm… I'd be interested in hearing what you find out. My expectation would be that active/active would have the potential to process RPC messages out of sequence and introduce consistency problems. | 15:16 |
| carl_baldwin | marun: I'll be sure to let you know what I find. | 15:16 |
| *** yamahata_ has quit IRC | 15:17 | |
| *** yamahata_ has joined #openstack-neutron | 15:17 | |
| *** yfried has quit IRC | 15:18 | |
| *** _jj_ has quit IRC | 15:20 | |
| *** carl_baldwin has quit IRC | 15:22 | |
| marun | 017387 | 15:23 |
| *** marun has quit IRC | 15:23 | |
| *** devlaps has joined #openstack-neutron | 15:26 | |
| *** bvandenh has joined #openstack-neutron | 15:30 | |
| *** jgrimm has joined #openstack-neutron | 15:31 | |
| *** amritanshu_RnD has quit IRC | 15:32 | |
| *** banix has joined #openstack-neutron | 15:36 | |
| openstackgerrit | Jianing Yang proposed a change to openstack/neutron: Fix str2dict and dict2str's incorrect behavior https://review.openstack.org/60195 | 15:37 |
| anteaya | marun: that is true | 15:39 |
| anteaya | but we can work towards focus regarding reviews and that can help | 15:39 |
| anteaya | marios_: I have a question, what do you mean by agro? | 15:40 |
| anteaya | I need to spend some time with the gerrit ssh commands and will report any useful findings I trip over | 15:41 |
| anteaya | marun: the question I gave to marios_ was meant for you | 15:44 |
| anteaya | and I think that we need to have more discussion so that everyone can see how our new policy is being enforced | 15:44 |
| anteaya | if you can't see it and point to it, they there are others who have no reference for its enforcement as well | 15:45 |
| anteaya | I'm not core, and only cores can approve | 15:45 |
| anteaya | I can support the conversation but my direct actions don't have an effect on enforcement | 15:46 |
| *** Vijay__ has quit IRC | 15:50 | |
| *** jprovazn has quit IRC | 15:58 | |
| *** aymenfrikha has joined #openstack-neutron | 16:00 | |
| *** amuller has quit IRC | 16:04 | |
| *** mlavalle has joined #openstack-neutron | 16:05 | |
| *** yamahata_ has quit IRC | 16:06 | |
| *** carl_baldwin has joined #openstack-neutron | 16:07 | |
| *** rudrarugge has joined #openstack-neutron | 16:09 | |
| anteaya | well one can conduct a query on review.openstack.org targetting the topic: ssh -p 29418 anteaya@review.openstack.org gerrit query --format=JSON status:open project:openstack/tempest topic:^bug.* limit:10 | 16:11 |
| anteaya | so if we developed a culture where the status of the bug is included in the topic | 16:12 |
| *** jprovazn has joined #openstack-neutron | 16:12 | |
| anteaya | for instance topic:^bug/critical/.* | 16:12 |
| anteaya | then the query could return all critical bugs | 16:13 |
| anteaya | be we would need to manifest that internally for it to work | 16:13 |
| anteaya | marun: ^ | 16:13 |
| *** rossella_s has quit IRC | 16:15 | |
| anteaya | mlavalle: hello | 16:15 |
| mlavalle | anteaya: hi | 16:15 |
| *** changbl has joined #openstack-neutron | 16:17 | |
| anteaya | have you taken a look at the addition I made to the api gap anaylsis on the etherpad? | 16:20 |
| mlavalle | anteaya: give me a minute | 16:21 |
| anteaya | k | 16:22 |
| mlavalle | anteaya: do you mean at the top about selecting a topic from the list, put your name, etc...? | 16:23 |
| anteaya | https://etherpad.openstack.org/p/icehouse-summit-qa-neutron | 16:23 |
| anteaya | yes | 16:23 |
| anteaya | does that make sense to you? | 16:23 |
| mlavalle | anteaya: that's perfect | 16:23 |
| *** alex_klimov1 has quit IRC | 16:23 | |
| anteaya | awesome | 16:23 |
| anteaya | please encourage people to create a bug | 16:24 |
| mlavalle | by this coming Monday I will have a wiki page with instructions aimed at new contributors walking them through the process of developing API tests specifically for Neutron | 16:24 |
| anteaya | if you could do one or two as an example that might help seed the direction | 16:25 |
| anteaya | woohoo | 16:25 |
| anteaya | go you | 16:25 |
| anteaya | that will be awesome | 16:25 |
| mlavalle | Once the wiki is up, I will send a message to the whole openstack mail list | 16:26 |
| anteaya | sounds good | 16:26 |
| anteaya | do you want to post in channel first and get some feedback from others in this room? | 16:26 |
| anteaya | just to clear up any instruction bugs | 16:27 |
| anteaya | and then to the ml? | 16:27 |
| mlavalle | perfect, that's a great idea | 16:27 |
| anteaya | great | 16:27 |
| mlavalle | I also made a little change to the Neutron wiki: https://wiki.openstack.org/wiki/Neutron | 16:28 |
| anteaya | how is your current understanding of tempest? | 16:28 |
| mlavalle | Look at the Related Projects section | 16:28 |
| anteaya | do you feel you have enough knowledge to help other -neutron devss? | 16:28 |
| * anteaya clicks | 16:28 | |
| mlavalle | Yes, I have enough understanding to help other Neutron debs with Tempest | 16:28 |
| anteaya | that looks great | 16:29 |
| anteaya | well done | 16:29 |
| anteaya | perfect | 16:29 |
| anteaya | are you able to be available more on irc? | 16:30 |
| mlavalle | I am connected every day | 16:30 |
| anteaya | on more of a daily basis, during your working days? | 16:30 |
| mlavalle | all day long | 16:30 |
| anteaya | hmmmm, I seem to miss you | 16:30 |
| mlavalle | we use it at work also | 16:30 |
| anteaya | okay great | 16:30 |
| anteaya | do you read the logs? http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/ | 16:31 |
| anteaya | what TZ are you in? | 16:31 |
| mlavalle | the other thing you should be aware of is that the gap analysis is not over yet…. I have finished core and l3 level, but over the next few days I will continue doing L4 to L7 | 16:31 |
| anteaya | okay | 16:32 |
| mlavalle | I am not in the habit of reading the logs, but I will try to start doing it | 16:32 |
| mlavalle | I am in Texas, thats CST | 16:32 |
| anteaya | let's see if we can get people to turn the gaps into bugs in what you have covered, while you continue | 16:32 |
| mlavalle | cool | 16:33 |
| anteaya | thanks, yes I tend to just post in the channel as I think of points | 16:33 |
| anteaya | okay CST | 16:33 |
| mlavalle | i belive you are in Toronto, that's EST, right | 16:33 |
| anteaya | I'll probably overlap with you more next week then | 16:33 |
| anteaya | EST when I'm home, yes | 16:34 |
| anteaya | currently GST +1 | 16:34 |
| mlavalle | so you are 1 hour ahead of me | 16:34 |
| anteaya | usually yes | 16:34 |
| mlavalle | ok | 16:34 |
| anteaya | can you connect with rosella_s and see how her tempest understanding is coming along? | 16:35 |
| mlavalle | sure, i'll try to do it this afternoon…. where is she located? do you know? | 16:35 |
| anteaya | she is currently bogged down in her assessment and if you could help unblock her, that would be great | 16:35 |
| anteaya | she is in Spain | 16:35 |
| mlavalle | ah ok, I am originally from Mexico City, so I speak Spanish | 16:36 |
| anteaya | so would have to be morning for you and later for her | 16:36 |
| anteaya | cool | 16:36 |
| anteaya | her English is great, but whatever works for the two of you | 16:36 |
| mlavalle | I'll follow up with her | 16:36 |
| anteaya | thank you | 16:36 |
| *** pete5 has joined #openstack-neutron | 16:43 | |
| *** SumitNaiksatam has quit IRC | 16:43 | |
| anteaya | at a conference, talks are wrapping up, soon going to be offline until tomorrow | 16:45 |
| anteaya | but my server is listening to post questions you have and I will do my best to address them when I am next online | 16:45 |
| anteaya | thanks | 16:45 |
| *** litong has joined #openstack-neutron | 16:46 | |
| anteaya | roaet: oh before I go, that bug https://bugs.launchpad.net/neutron/+bug/1251448 | 16:46 |
| anteaya | roaet: any updates on this bug? | 16:46 |
| roaet | anteaya: not at the moment, we have a meeting friday to discuss it with our nova folk and neutron folk | 16:47 |
| roaet | Since it appears to be a race condition | 16:47 |
| anteaya | okay thanks | 16:47 |
| anteaya | great, can you update the bug report with any comment after that discussion | 16:47 |
| roaet | of course | 16:48 |
| anteaya | even if it is just noting taht the discussion happened | 16:48 |
| anteaya | thanks | 16:48 |
| anteaya | jog0: can you take another look at the logstash for https://bugs.launchpad.net/neutron/+bug/1250168 | 16:50 |
| *** networkstatic has quit IRC | 16:50 | |
| anteaya | I am seeing no hits for it since Dec. 3 | 16:50 |
| anteaya | can you confirm? | 16:51 |
| *** rossella_s has joined #openstack-neutron | 16:52 | |
| anteaya | jog0: can I also get a logstash url in https://bugs.launchpad.net/nova/+bug/1210483? | 16:52 |
| anteaya | sorry if it obvious how to do that, I think I need to up my logstash foo | 16:52 |
| anteaya | okay now I am afk | 16:53 |
| *** x86brandon has joined #openstack-neutron | 16:54 | |
| *** mjbright_ has quit IRC | 16:56 | |
| *** rpodolyaka has left #openstack-neutron | 16:56 | |
| *** _jj_ has joined #openstack-neutron | 16:57 | |
| _jj_ | well, about the issue with floating-ip change and instance reboot | 16:58 |
| _jj_ | have been conducting tests for hours | 16:59 |
| _jj_ | it has something to do for sure with rebooting but i cannot see anything abnormal | 16:59 |
| openstackgerrit | A change was merged to openstack/neutron: Ensure NVP API connection port is always an integer https://review.openstack.org/58751 | 16:59 |
| _jj_ | in my two node setup, right now have all the instances on host A without public connection and all the instance on host B with connection up and runing | 17:00 |
| *** s3wong has quit IRC | 17:01 | |
| _jj_ | any suggestion where to look at? | 17:01 |
| openstackgerrit | Ann Kamyshnikova proposed a change to openstack/neutron: Fix downgrade in migration https://review.openstack.org/53091 | 17:03 |
| *** SumitNaiksatam has joined #openstack-neutron | 17:04 | |
| *** clev_ has joined #openstack-neutron | 17:05 | |
| *** clev has quit IRC | 17:05 | |
| beagles | _jj_, I'd look for changes in the ports and mac addrs | 17:05 |
| beagles | not ports as in IP ports, but neutron ports | 17:06 |
| *** rudrarugge has quit IRC | 17:08 | |
| openstackgerrit | Dirk Mueller proposed a change to openstack/python-neutronclient: Use assertIn where appropriate https://review.openstack.org/59165 | 17:11 |
| *** julim has quit IRC | 17:16 | |
| *** julim has joined #openstack-neutron | 17:17 | |
| _jj_ | beagles: well i have not seen anything weird in neutron ports | 17:22 |
| _jj_ | i keep on testing | 17:22 |
| *** armax has joined #openstack-neutron | 17:24 | |
| *** armax has quit IRC | 17:25 | |
| *** yfried has joined #openstack-neutron | 17:26 | |
| *** chandankumar has quit IRC | 17:26 | |
| *** armax has joined #openstack-neutron | 17:27 | |
| openstackgerrit | Édouard Thuleau proposed a change to openstack/neutron: Add local ARP responder to the OVS agent https://review.openstack.org/49227 | 17:27 |
| *** armax has quit IRC | 17:28 | |
| *** armax has joined #openstack-neutron | 17:28 | |
| *** armax has quit IRC | 17:32 | |
| *** armax has joined #openstack-neutron | 17:34 | |
| *** armax has quit IRC | 17:34 | |
| *** armax has joined #openstack-neutron | 17:34 | |
| *** clev_ has quit IRC | 17:34 | |
| pete5 | arson, could please you comment on why https://launchpad.net/neutron/+bug/1177973 isn't havana backport potential anymore. I see that you removed the tag a couple of weeks ago. Thanks! | 17:40 |
| salv-orlando | _jj_: I am back; after rebooting an instance, it would be good to understand whether it's the floating ip not working for some reason or is networking not ready on the instance. | 17:40 |
| pete5 | arosen (not arson :-) ) could please you comment on why https://launchpad.net/neutron/+bug/1177973 isn't havana backport potential anymore. I see that you removed the tag a couple of weeks ago. Thanks! | 17:40 |
| *** jistr has quit IRC | 17:41 | |
| *** armax has quit IRC | 17:42 | |
| *** armax has joined #openstack-neutron | 17:43 | |
| *** alagalah has joined #openstack-neutron | 17:49 | |
| *** armax has quit IRC | 17:49 | |
| *** armax has joined #openstack-neutron | 17:49 | |
| *** rudrarugge has joined #openstack-neutron | 17:55 | |
| *** mlavalle has quit IRC | 18:02 | |
| *** nati_ueno has joined #openstack-neutron | 18:02 | |
| *** rossella_s has quit IRC | 18:03 | |
| *** mlavalle has joined #openstack-neutron | 18:04 | |
| arosen | pete5: I'll re-add the tag. I just looked at the patch again. Seems fine. Usually adding additional config options in backports isn't really great. | 18:10 |
| salv-orlando | arosen: isn't there also an additional dependency on psutil? Or am I dreaming of it? | 18:12 |
| arosen | salv-orlando: doesn't look like it: https://review.openstack.org/#/c/45678/11 | 18:13 |
| *** harlowja has joined #openstack-neutron | 18:14 | |
| salv-orlando | arosen: cool I can't find it either in that patch nor the dependent ones, but I remember having to re-create the tox env because of psutil while reviewing the patch. But it could have been just me being high on caffeine | 18:16 |
| pete5 | Does anybody know what Kyle Mestery's IRC handle is? | 18:17 |
| *** csd_ has joined #openstack-neutron | 18:18 | |
| mestery | mestery | 18:18 |
| arosen | ha | 18:18 |
| mestery | :) | 18:18 |
| *** csd_ is now known as csd | 18:18 | |
| pete5 | mestery: :-) When you've got a moment, could you comment on the ongoing discussion on https://review.openstack.org/#/c/58854/ | 18:18 |
| mestery | pete5 | 18:19 |
| mestery | pete5: Sure, will do, thanks for pointing this out! | 18:19 |
| *** csd has quit IRC | 18:26 | |
| *** jlibosva has quit IRC | 18:27 | |
| *** jlibosva has joined #openstack-neutron | 18:30 | |
| *** ihrachyska has quit IRC | 18:37 | |
| *** csd has joined #openstack-neutron | 18:38 | |
| *** fouxm has quit IRC | 18:42 | |
| *** rudrarugge has quit IRC | 18:43 | |
| *** clev has joined #openstack-neutron | 18:47 | |
| *** terrylhowe has joined #openstack-neutron | 18:48 | |
| terrylhowe | A subnet and a port can be added to a router. Are there any other likely use cases for interface add? | 18:50 |
| *** suresh12 has joined #openstack-neutron | 18:50 | |
| *** Abhishe__ has joined #openstack-neutron | 18:51 | |
| terrylhowe | I'm working on the unified CLI and I was thinking of making the commands "router add port" and "router add subnet" | 18:53 |
| *** ihrachyska has joined #openstack-neutron | 18:53 | |
| *** mlavalle has quit IRC | 18:55 | |
| openstackgerrit | Ed Bak proposed a change to openstack/neutron: Change to improve dhcp-agent sync_state https://review.openstack.org/59863 | 19:03 |
| *** armax has quit IRC | 19:11 | |
| openstackgerrit | Shree Duth Awasthi proposed a change to openstack/python-neutronclient: Misc typo in neutronclient https://review.openstack.org/60324 | 19:12 |
| *** yfried has quit IRC | 19:13 | |
| *** armax has joined #openstack-neutron | 19:13 | |
| *** armax has quit IRC | 19:14 | |
| *** alagalah has left #openstack-neutron | 19:14 | |
| *** armax has joined #openstack-neutron | 19:16 | |
| jog0 | anteaya: for 1210483? | 19:17 |
| jog0 | anteaya: I need a entry in nova-compute or a neutron service to use as a fingerprint | 19:18 |
| *** ywu has quit IRC | 19:19 | |
| jog0 | and for https://bugs.launchpad.net/neutron/+bug/1250168 your analysis is correct it turns out that was the new hpcloud going online | 19:19 |
| *** armax has quit IRC | 19:19 | |
| jog0 | we were using it in gate and it was slowe. also we dropped the large-ops test down to 100 instances because 150 was too close to a failure case on slower clouds. And although we should make that test work for numbers larger then 150 we have much bigger issues to sort out | 19:20 |
| *** armax has joined #openstack-neutron | 19:20 | |
| *** armax has quit IRC | 19:20 | |
| jog0 | anteaya: https://review.openstack.org/#/c/60000/ | 19:21 |
| *** armax has joined #openstack-neutron | 19:21 | |
| *** clev has quit IRC | 19:30 | |
| *** clev has joined #openstack-neutron | 19:34 | |
| *** Sreedhar has quit IRC | 19:35 | |
| openstackgerrit | Jon Grimm proposed a change to openstack/neutron: Openvswitch update_port should return updated port info https://review.openstack.org/58847 | 19:39 |
| *** jpich has quit IRC | 19:40 | |
| *** aveiga has joined #openstack-neutron | 19:46 | |
| openstackgerrit | Jon Grimm proposed a change to openstack/neutron: Fix ml2 plugin for allowedaddresspairs tests https://review.openstack.org/58896 | 19:51 |
| *** armax has quit IRC | 19:55 | |
| *** armax has joined #openstack-neutron | 19:55 | |
| *** jlibosva has quit IRC | 19:55 | |
| *** SridarK has joined #openstack-neutron | 19:57 | |
| *** ihrachyska has quit IRC | 19:59 | |
| *** terrylhowe has left #openstack-neutron | 20:08 | |
| *** bvandenh has quit IRC | 20:09 | |
| *** julim has quit IRC | 20:16 | |
| *** suresh12 has quit IRC | 20:17 | |
| *** rkukura has quit IRC | 20:17 | |
| *** Abhishe__ has quit IRC | 20:25 | |
| openstackgerrit | Jon Grimm proposed a change to openstack/neutron: Fix ml2 & nec plugins for allowedaddresspairs tests https://review.openstack.org/58896 | 20:26 |
| *** suresh12 has joined #openstack-neutron | 20:28 | |
| *** armax has left #openstack-neutron | 20:32 | |
| *** aymenfrikha has quit IRC | 20:39 | |
| *** aymenfrikha has joined #openstack-neutron | 20:42 | |
| *** jprovazn has quit IRC | 20:50 | |
| *** mlavalle has joined #openstack-neutron | 20:50 | |
| *** ywu has joined #openstack-neutron | 20:50 | |
| *** banix has quit IRC | 20:51 | |
| *** networkstatic has joined #openstack-neutron | 20:55 | |
| *** julim has joined #openstack-neutron | 20:56 | |
| *** sbasam has joined #openstack-neutron | 20:56 | |
| *** Abhishek_ has joined #openstack-neutron | 20:57 | |
| openstackgerrit | Shiv Haris proposed a change to openstack/neutron: Implementaion of Mechanism driver for Brocade VDX cluster of switches https://review.openstack.org/60129 | 20:59 |
| *** pcm_ has quit IRC | 21:03 | |
| *** banix has joined #openstack-neutron | 21:04 | |
| openstackgerrit | Carl Baldwin proposed a change to openstack/neutron: Use information from the dnsmasq hosts file to call dhcp_release https://review.openstack.org/56263 | 21:12 |
| *** banix has quit IRC | 21:14 | |
| *** banix has joined #openstack-neutron | 21:18 | |
| openstackgerrit | Salvatore Orlando proposed a change to openstack/neutron: Test commit for testing parallel job in experimental queue https://review.openstack.org/57420 | 21:25 |
| *** yfried has joined #openstack-neutron | 21:36 | |
| *** yamahata_ has joined #openstack-neutron | 21:37 | |
| *** arosen has quit IRC | 21:43 | |
| *** arosen has joined #openstack-neutron | 21:44 | |
| *** yfried has quit IRC | 21:49 | |
| asadoughi | neutron security-group-show is hard to read on a non-giant display | 21:50 |
| *** banix has quit IRC | 21:50 | |
| *** banix has joined #openstack-neutron | 21:51 | |
| *** networkstatic has quit IRC | 22:01 | |
| *** banix has quit IRC | 22:03 | |
| *** litong has quit IRC | 22:17 | |
| *** jgrimm has quit IRC | 22:18 | |
| openstackgerrit | Dane LeBlanc proposed a change to openstack/neutron: Improve unit test coverage for Cisco plugin common code https://review.openstack.org/60370 | 22:18 |
| *** clev has quit IRC | 22:19 | |
| *** aveiga has quit IRC | 22:24 | |
| *** arosen has quit IRC | 22:32 | |
| *** arosen has joined #openstack-neutron | 22:32 | |
| *** changbl has quit IRC | 22:32 | |
| *** sbasam has left #openstack-neutron | 22:35 | |
| *** banix has joined #openstack-neutron | 22:37 | |
| *** gdubreui has joined #openstack-neutron | 22:41 | |
| *** yamahata_ has quit IRC | 22:45 | |
| *** rkukura has joined #openstack-neutron | 22:46 | |
| *** openstackgerrit has quit IRC | 22:48 | |
| *** openstackgerrit has joined #openstack-neutron | 22:48 | |
| *** rkukura has quit IRC | 23:04 | |
| *** nati_uen_ has joined #openstack-neutron | 23:04 | |
| *** nati_ueno has quit IRC | 23:07 | |
| *** clev has joined #openstack-neutron | 23:13 | |
| *** jecarey has quit IRC | 23:22 | |
| *** nati_uen_ has quit IRC | 23:34 | |
| *** nati_ueno has joined #openstack-neutron | 23:34 | |
| *** clev has quit IRC | 23:36 | |
| openstackgerrit | Edgar Magana proposed a change to openstack/neutron: Implements provider network support in PLUMgrid plugin https://review.openstack.org/60383 | 23:46 |
| *** openstackgerrit has quit IRC | 23:47 | |
| *** openstackgerrit has joined #openstack-neutron | 23:47 | |
| *** peristeri has quit IRC | 23:49 | |
| *** mlavalle has quit IRC | 23:54 | |
| *** carl_baldwin has quit IRC | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!