Re: [openstack-dev] 答复: [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force
Original message bounced and I didn't notice. thanks,manish - Subject: Re: [openstack-dev] 答复: [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force Thanks Rossella. I'll take a look this week. My name is also on the etherpad already and can help with this. Somehow missed this thread earlier. regards, On Friday, November 28, 2014 7:42 AM, Rossella Sblendido rsblend...@suse.com wrote: On 11/27/2014 12:21 PM, marios wrote: Hi, so far we have this going https://etherpad.openstack.org/p/restructure-l2-agent I finally pushed a design spec based on the etherpad above, https://review.openstack.org/#/c/137808/ . Anybody interested please comment on the review. cheers, Rossella ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][TripleO] Clear all flows when ovs agent start? why and how avoid?
Clearing all flows upon agent restart is a major issue, imho. We should really look at this with higher priority than the modular L2 agent as the timeline of the refactor isn't clear for the modular layer 2 agent. Whatever the issue was, I think we ought to be able to find a better solution that doesn't disrupt the network. I agree that reconciling data after a restart is not straight-forward in all scenarios but there should be an option to just do basic sanity and not interrupt existing flows. I'd like to help out on this (if needed) - there is a blueprint [1] that was suggested but I'm not sure who the owner is and what the status is. If anyone is working on this and is at the summit this week, please let me know. We can meet one of the days here at the summit. thanks, manish [1] Adding an option of Soft Restart in neutron agent along with o... : Blueprints : neutron | | | | | | | | | | | Adding an option of Soft Restart in neutron agent alon...While the blueprint of ovs-firewall-driver is being developed, a new concern comes up. When an ovs agent (or an ml2 agent with ovs) restarts, if it cleans up all ... | | | | View on blueprints.launchpad.net | Preview by Yahoo | | | | | On Friday, October 31, 2014 7:32 AM, Ben Nemec openst...@nemebean.com wrote: On 10/29/2014 10:17 AM, Kyle Mestery wrote: On Wed, Oct 29, 2014 at 7:25 AM, Hly henry4...@gmail.com wrote: Sent from my iPad On 2014-10-29, at 下午8:01, Robert van Leeuwen robert.vanleeu...@spilgames.com wrote: I find our current design is remove all flows then add flow by entry, this will cause every network node will break off all tunnels between other network node and all compute node. Perhaps a way around this would be to add a flag on agent startup which would have it skip reprogramming flows. This could be used for the upgrade case. I hit the same issue last week and filed a bug here: https://bugs.launchpad.net/neutron/+bug/1383674 From an operators perspective this is VERY annoying since you also cannot push any config changes that requires/triggers a restart of the agent. e.g. something simple like changing a log setting becomes a hassle. I would prefer the default behaviour to be to not clear the flows or at the least an config option to disable it. +1, we also suffered from this even when a very little patch is done I'd really like to get some input from the tripleo folks, because they were the ones who filed the original bug here and were hit by the agent NOT reprogramming flows on agent restart. It does seem fairly obvious that adding an option around this would be a good way forward, however. Since nobody else has commented, I'll put in my two cents (though I might be overcharging you ;-). I've also added the TripleO tag to the subject, although with Summit coming up I don't know if that will help. Anyway, if the bug you're referring to is the one I think, then our issue was just with the flows not existing. I don't think we care whether they get reprogrammed on agent restart or not as long as they somehow come into existence at some point. It's possible I'm wrong about that, and probably the best person to talk to would be Robert Collins since I think he's the one who actually tracked down the problem in the first place. -Ben ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] Networking API Create network missing Request parameters
Provider network is an extension. The API details should be at [1] To get this to work your plugin should support the 'provider' extension. ML2 supports it [2]. More details can be found at [3] There is also multi-segment provider networks support. Details for that is at [4] as mentioned by Mathieu [1] http://developer.openstack.org/api-ref-networking-v2.html#network_provider- ext [2] https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/plugin .py#L102 [3] http://docs.openstack.org/api/openstack-network/2.0/content/provider_ext.ht ml [4] http://developer.openstack.org/api-ref-networking-v2.html#network_multi_pro vider-ext On 10/23/14, 4:12 PM, Mathieu Gagné mga...@iweb.com wrote: On 2014-10-23 7:00 PM, Danny Choi (dannchoi) wrote: In neutron, user with ³admin² role can specify the provider network parameters when creating a network. ‹provider:network_type ‹provider:physical_network ‹provider:segmentation_id localadmin@qa4:~/devstack$ neutron net-create test-network --provider:network_type vlan --provider:physical_network physnet1 --provider:segmentation_id 400 However, the Networking API v2.0 (http://developer.openstack.org/api-ref-networking-v2.html) ³Create network² does not list them as Request parameters. Is this a print error? I see them under the Networks multiple provider extension (networks) section. [1] Open the detail for Create network with multiple segment mappings to see them. Is this what you were looking for? [1] http://developer.openstack.org/api-ref-networking-v2.html#network_multi_pr ovider-ext -- Mathieu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Pod-area meetup to discuss proposal to allow HV-based network selection
Hey folks, I have met several folks at the summit who have come up with their own solutions for large clouds to allow network scaling. Several of the solutions seem to be based on network selection given certain constraints. I would like to discuss some use-cases and some solutions. We could meet at 3:30/Thu (today) in the pod area, if interested. Thanks, manish ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Design Summit Sessions
Sounds like a good idea to me. Is the pod area for neutron-specific discussions? Thanks, manish On 4/28/14 12:08 PM, Kyle Mestery mest...@noironetworks.com wrote: On Mon, Apr 28, 2014 at 1:38 PM, Carl Baldwin c...@ecbaldwin.net wrote: Kyle, Could you point to any information about the pod area? I would like to do something with the DNS discussion. Will this area be schedulable or first-come-first-served? The pod area is more free-form, no schedule necessary now. If there is enough interest in the Pod area, we could certainly look to make it a resource to schedule time at. I think the idea in general was to make it more open and possibly to use it for continuing discussions which overflowed their time. What do others think? Thanks, Kyle Carl On Fri, Apr 25, 2014 at 7:17 AM, Kyle Mestery mest...@noironetworks.com wrote: Hi everyone: I've pushed out the Neutron Design Summit Schedule to sched.org [1]. Like the other projects, it was tough to fit everything in. If your proposal didn't make it, there will still be opportunities to talk about it at the Summit in the project Pod area. Also, I encourage you to still file a BP using the new Neutron BP process [2]. I expect some slight juggling of the schedule may occur as the entire Summit schedule is set, but this should be approximately where things land. Thanks! Kyle [1] http://junodesignsummit.sched.org/overview/type/neutron [2] https://wiki.openstack.org/wiki/Blueprints#Neutron ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
