Re: [openstack-dev] [neutron] What does flavor mean for a network?
Neil, flavor:network is for Metaplugin. It is unrelated to flavor framework. FYI, Metaplugin will be removed in liberty. https://review.openstack.org/#/c/192056/ Thanks. Itsuro Oda (oda-g) On Thu, 16 Jul 2015 10:44:01 +0100 Neil Jerram neil.jer...@metaswitch.com wrote: Thanks everyone for your responses... On 15/07/15 21:01, Doug Wiegley wrote: That begins to looks like nova’s metadata tags and scheduler, which is a valid use case. The underpinnings of flavors could do this, but it’s not in the initial implementation. doug On Jul 15, 2015, at 12:38 PM, Kevin Benton blak...@gmail.com mailto:blak...@gmail.com wrote: Wouldn't it be valid to assign flavors to groups of provider networks? e.g. a tenant wants to attach to a network that is wired up to a 40g router so he/she chooses a network of the fat pipe flavor. Indeed. Otherwise, why does 'flavor:network' exist at all in the current codebase? As the code currently stands, 'flavor:network' appears to be consumed only by agent/linux/interface.py, with the logic that if the interface_driver setting is set to MetaInterfaceDriver, the interface driver class that is actually used for a particular network will be derived by using the network's 'flavor:network' value as a lookup key in the dict specified by the meta_flavor_driver_mappings setting. Is that an intended part of the flavors design? I hope it doesn't sound like I'm just complaining! My reason for asking these questions is that I'm working at https://review.openstack.org/#/c/198439/ on a type of network that works through routing on each compute host instead of bridging, and two of the consequences of that are that (1) there will not be L2 broadcast connectivity between the instances attached to such a network, whereas there would be with all existing Neutron network types (2) the DHCP agent needs some changes to provide DHCP service on unbridged TAP interfaces. Probably best here not to worry too much about the details. But, at a high level: - there is an aspect of the network's behavior that needs to be portrayed in the UI, so that tenants/projects can know when it is appropriate to attach instances to that network - there is an aspect of the network's implementation that the DHCP agent needs to be aware of, so that it can adjust accordingly. I believe the flavor:network 'works', for these purposes, in the senses that it is portrayed in the UI, and that it is available to software components such as the DHCP agent. So I was wondering whether 'flavor:network' would be the correct location in principle for a value identifying this kind of network, according to the intention of the flavors enhancement. On Wed, Jul 15, 2015 at 10:40 AM, Madhusudhan Kandadai madhusudhan.openst...@gmail.com mailto:madhusudhan.openst...@gmail.com wrote: On Wed, Jul 15, 2015 at 9:25 AM, Kyle Mestery mest...@mestery.com mailto:mest...@mestery.com wrote: On Wed, Jul 15, 2015 at 10:54 AM, Neil Jerram neil.jer...@metaswitch.com mailto:neil.jer...@metaswitch.com wrote: I've been reading available docs about the forthcoming Neutron flavors framework, and am not yet sure I understand what it means for a network. In reality, this is envisioned more for service plugins (e.g. flavors of LBaaS, VPNaaS, and FWaaS) than core neutron resources. Yes. Right put. This is for service plugins and its part of extensions than core network resources// Is it a way for an admin to provide a particular kind of network, and then for a tenant to know what they're attaching their VMs to? I'll defer to Madhu who is implementing this, but I don't believe that's the intention at all. Currently, an admin will be able to assign particular flavors, unfortunately, this is not going to be tenant specific flavors. To be clear - I wasn't suggesting or asking for tenant-specific flavors. I only meant that a tenant might choose which network to attach a particular set of VMs to, depending on the flavors of the available networks. (E.g. as in Kevin's example above.) As you might have seen in the review, we are just using tenant_id to bypass the keystone checks implemented in base.py and it is not stored in the db as well. It is something to do in the future and documented the same in the blueprint. How does it differ from provider:network-type? (I guess, because the latter is supposed to be for implementation consumption only - but is that correct?) Flavors are created and curated by operators, and consumed by API users. +1 Many thanks, Neil -- Itsuro ODA o...@valinux.co.jp
Re: [openstack-dev] [Neutron] L3 agent rescheduling issue
Hi, After trying to reproduce this, I'm suspecting that the issue is actually on the server side from failing to drain the agent report state queue in time. I have seen before. I thought the senario at that time as follows. * a lot of create/update resource API issued * rpc_conn_pool_size pool exhausted for sending notify and blocked farther sending side of RPC. * rpc_thread_pool_size pool exhausted by waiting rpc_conn_pool_size pool for replying RPC. * receiving state_report is blocked because rpc_thread_pool_size pool exhausted. Thanks Itsuro Oda On Thu, 4 Jun 2015 14:20:33 -0700 Kevin Benton blak...@gmail.com wrote: After trying to reproduce this, I'm suspecting that the issue is actually on the server side from failing to drain the agent report state queue in time. I set the report_interval to 1 second on the agent and added a logging statement and I see a report every 1 second even when sync_routers is taking a really long time. On Thu, Jun 4, 2015 at 11:52 AM, Carl Baldwin c...@ecbaldwin.net wrote: Ann, Thanks for bringing this up. It has been on the shelf for a while now. Carl On Thu, Jun 4, 2015 at 8:54 AM, Salvatore Orlando sorla...@nicira.com wrote: One reason for not sending the heartbeat from a separate greenthread could be that the agent is already doing it [1]. The current proposed patch addresses the issue blindly - that is to say before declaring an agent dead let's wait for some more time because it could be stuck doing stuff. In that case I would probably make the multiplier (currently 2x) configurable. The reason for which state report does not occur is probably that both it and the resync procedure are periodic tasks. If I got it right they're both executed as eventlet greenthreads but one at a time. Perhaps then adding an initial delay to the full sync task might ensure the first thing an agent does when it comes up is sending a heartbeat to the server? On the other hand, while doing the initial full resync, is the agent able to process updates? If not perhaps it makes sense to have it down until it finishes synchronisation. Yes, it can! The agent prioritizes updates from RPC over full resync activities. I wonder if the agent should check how long it has been since its last state report each time it finishes processing an update for a router. It normally doesn't take very long (relatively) to process an update to a single router. I still would like to know why the thread to report state is being starved. Anyone have any insight on this? I thought that with all the system calls, the greenthreads would yield often. There must be something I don't understand about it. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton -- Itsuro ODA o...@valinux.co.jp __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] FWaaS iptables implementation
Hi, I think Kazuhiro's concern is that if one want to delete an allow rule or change an allow rule to deny rule, it is not work correctly because a conntrack entry made by previous communication is not deleted in the current implementation. Thanks, Itsuto Oda On Wed, 8 Apr 2015 11:37:29 -0700 Rajesh Mohan rajesh.mli...@gmail.com wrote: Hi Miyashita, The second rule is 'accept' on state being 'established' or 'related'. In case of ICMP, if a request has gone out from inside network, then the reply to that will match this rule. A new ICMP message initiated from outside will not match this rule. I hope I understood your question correctly. Let me know if this addresses your concern. Thanks, -Rajesh Mohan On Mon, Mar 30, 2015 at 1:58 AM, Miyashita, Kazuhiro miy...@jp.fujitsu.com wrote: Hi, I want to ask about FWaaS iptables rule implementation. firewall rule are deployed as iptables rules in network node , and ACCEPT target is set at second rule(*). Chain neutron-l3-agent-iv431d7bfbc (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED (*) 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 172.16.2.0/231.2.3.4 tcp spts:1025:65535 dpt:80 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 172.16.6.0/241.2.3.4 tcp spts:1025:65535 dpt:80 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 1.2.3.4 172.16.14.0/24 tcp spts:1025:65535 dpt:11051 0 0 neutron-l3-agent-liA31d7bfbc tcp -- * * 10.3.0.0/24 1.2.3.4 tcp spts:1025:65535 dpt:22 0 0 neutron-l3-agent-liD31d7bfbc all -- * * 0.0.0.0/00.0.0.0/0 Why is ACCEPT rule set at second in iptables rule. Performance reason(ICMP or other protocol such as UDP/TCP)? This causes some wrong scenario for example... [outside openstack cloud] --- Firewall(FWaaS) -- [inside openstack cloud] 1) admin create Firewall and create Filrewall rule accepting ICMP request from outside openstack cloud, and 2) ICMP request packets incoming from outside to inside, and 3) someday, admin detects that ICMP rule is security vulnerability and create Firewall rule blocking ICMP request from outside. but ICMP request packets still incoming due to ACCEPT rule(*), because ICMP connection still hit rule at second(*). Thanks. kazuhiro MIYASHITA __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Itsuro ODA o...@valinux.co.jp __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] request for SFE
Neutron cores, I request SFE for the fix: https://review.openstack.org/147032/ https://bugs.launchpad.net/neutron/+bug/1408488 I believe there is consensus that this change is valuable through the discussion on the thread [1]. This change adds a configuration option to keep backward compatibility. (note that the opinion for the implementation was divided among reviewers. it is latest conclusion.) A string for translation is a help text of the configuration option. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-March/059714.html PS. I am not familiar with SFE procedure. Should I raise this to openstack-i18n mailing-list ? Thanks. -- Itsuro ODA o...@valinux.co.jp __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] FF and our march towards the RC
Kyle and cores, There are some fixes [1] I want to get merged in kilo-rc1. (These fixes stay for a long time on gerrit because they have not gained core's review much.) I'd like to set milestone to kilo-rc1 for these fixes but I can't set milestone field of launchpad. I wish cores are interested in these fix and support to get merged. [1] * https://review.openstack.org/147032/ (see also: http://lists.openstack.org/pipermail/openstack-dev/2015-March/059466.html ) * https://review.openstack.org/161947/ * https://review.openstack.org/150284/ * https://review.openstack.org/149458/ Thanks. Itsuro Oda On Tue, 24 Mar 2015 12:12:58 -0500 Kyle Mestery mest...@mestery.com wrote: Folks: I've gone through the BPs granted an FFE and I have our RC-1 setup now [1]. Please note that the BPs in there all need to merge by the dates specified in the BP in Launchpad. Most are by next Tuesday, March 31. But the LBaaS drivers need to go in by Friday. If these BPs don't land by then, they'll be out of Kilo. We need a solid 2 weeks to work on bugs that crop up as we're testing Neutron Kilo. I'll be working the bug list next. If you feel a bug should be a release candidate, target it to RC1 for now. Core Reviewers: Please be cautious about merging code at this point. When in doubt, find me in #openstack-neutron. Thanks! Kyle [1] https://launchpad.net/neutron/+milestone/kilo-rc1 -- Itsuro ODA o...@valinux.co.jp __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][L3] Stop agent scheduling without stopping sevices
Neutron cores, I have submitted the change [1] which is related to the thread [2] in January. Unfortunately it did not attract the interest of many core reviewers, and only time has passed. Now it is pointed that it may need FFE/SSE, and the opinion of the core is a bit divided about implementation. Sorry for raising this too late. But I believe this is a valuable change. So I would like support for this change to be merged. [1] https://review.openstack.org/#/c/147032/ [2] http://lists.openstack.org/pipermail/openstack-dev/2015-January/053782.html Thanks. -- Itsuro ODA o...@valinux.co.jp __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without stopping sevices
Carl,
Thank you for your comment.
It seems there is no clear opinion about whether bug report or
buleprint is better.
So I submitted a bug report for the moment so that the requirememt
is not forgotten.
https://bugs.launchpad.net/neutron/+bug/1408488
Thanks.
Itsuro Oda
On Tue, 6 Jan 2015 09:05:19 -0700
Carl Baldwin c...@ecbaldwin.net wrote:
Itsuro,
It would be desirable to be able to be hide an agent from scheduling
but no one has stepped up to make this happen. Come to think of it,
I'm not sure that a bug or blueprint has been filed yet to address it
though it is something that I've wanted for a little while now.
Carl
On Mon, Jan 5, 2015 at 4:13 PM, Itsuro ODA o...@valinux.co.jp wrote:
Neutron experts,
I want to stop scheduling to a specific {dhcp|l3}_agent without
stopping router/dhcp services on it.
I expected setting admin_state_up of the agent to False is met
this demand. But this operation stops all services on the agent
in actuality. (Is this behavior intended ? It seems there is no
document for agent API.)
I think admin_state_up of agents should affect only scheduling.
If it is accepted I will submit a bug report and make a fix.
Or should I propose a blueprint for adding function to stop
agent's scheduling without stopping services on it ?
I'd like to hear neutron experts' suggestions.
Thanks.
Itsuro Oda
--
Itsuro ODA o...@valinux.co.jp
___
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
--
Itsuro ODA o...@valinux.co.jp
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without topping sevices
Miguel, Kevin,
Thank you for your comments.
The motivation of this (from our customer) is about
design of network-node reduction procedure.
They prefer stop scheduling for agents on the node
at first then individual services are moved by
*-remove and *-add gradually rather than stopping all
services on the node at once.
As Kevin mentioned, agents must be alive so that
operations for existing services must be continued.
Thanks.
Itsuro Oda
On Wed, 7 Jan 2015 15:52:56 -0800
Kevin Benton blak...@gmail.com wrote:
The problem is that if you just stop the service, it not only removes it
from scheduling, but it stops it from receiving updates to floating IP
changes, interface changes, etc. I think it would be nice to have a way to
explicitly stop it from being scheduled new routers, but still act as a
functioning L3 agent otherwise.
On Wed, Jan 7, 2015 at 3:30 PM, Miguel Angel Ajo majop...@redhat.com
wrote:
You can stop the neutron-dhcp-agent or neutron-l3-agent,
the agents should go not-active after reporting timeout.
The actual network services (routers, dhcp, etc) will stay
active into the node, but unmanaged. In some cases,
if you have automatic rescheduling of the resources
configured, those will be spawned on other hosts.
Depending on your use case this will be enough or not.
It’s intended for upgrades and maintenance. But not
for controlling resources in a node.
Miguel Angel Ajo
On Thursday, 8 de January de 2015 at 00:20, Itsuro ODA wrote:
Carl,
Thank you for your comment.
It seems there is no clear opinion about whether bug report or
buleprint is better.
So I submitted a bug report for the moment so that the requirememt
is not forgotten.
https://bugs.launchpad.net/neutron/+bug/1408488
Thanks.
Itsuro Oda
On Tue, 6 Jan 2015 09:05:19 -0700
Carl Baldwin c...@ecbaldwin.net wrote:
Itsuro,
It would be desirable to be able to be hide an agent from scheduling
but no one has stepped up to make this happen. Come to think of it,
I'm not sure that a bug or blueprint has been filed yet to address it
though it is something that I've wanted for a little while now.
Carl
On Mon, Jan 5, 2015 at 4:13 PM, Itsuro ODA o...@valinux.co.jp wrote:
Neutron experts,
I want to stop scheduling to a specific {dhcp|l3}_agent without
stopping router/dhcp services on it.
I expected setting admin_state_up of the agent to False is met
this demand. But this operation stops all services on the agent
in actuality. (Is this behavior intended ? It seems there is no
document for agent API.)
I think admin_state_up of agents should affect only scheduling.
If it is accepted I will submit a bug report and make a fix.
Or should I propose a blueprint for adding function to stop
agent's scheduling without stopping services on it ?
I'd like to hear neutron experts' suggestions.
Thanks.
Itsuro Oda
--
Itsuro ODA o...@valinux.co.jp
___
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
--
Itsuro ODA o...@valinux.co.jp
___
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
--
Kevin Benton
--
Itsuro ODA o...@valinux.co.jp
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][L3] Stop agent scheduling without stopping sevices
Neutron experts,
I want to stop scheduling to a specific {dhcp|l3}_agent without
stopping router/dhcp services on it.
I expected setting admin_state_up of the agent to False is met
this demand. But this operation stops all services on the agent
in actuality. (Is this behavior intended ? It seems there is no
document for agent API.)
I think admin_state_up of agents should affect only scheduling.
If it is accepted I will submit a bug report and make a fix.
Or should I propose a blueprint for adding function to stop
agent's scheduling without stopping services on it ?
I'd like to hear neutron experts' suggestions.
Thanks.
Itsuro Oda
--
Itsuro ODA o...@valinux.co.jp
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [infra][devstack] CI failed The plugin token_endpoint could not be found
Hi, My third party CI becomes failed from about 21:00 12th UTC in execution of devstack. The error occurs at openstack project create admin -f value -c id --- ERROR: openstack The plugin token_endpoint could not be found --- I found some CIs have same problem. Does anyone give me a hint to solve this problem ? Thanks. -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra][devstack] CI failed The plugin token_endpoint could not be found
Hi, I'm wondering why you are just hitting it now? Does your CI pull the latest python-keystoneclient and python-openstackclient from master? Yes before it began to fail, but now it is No because of this change: https://github.com/openstack-dev/devstack/commit/8f8e2d1fbfa4c51f6b68a6967e330cd478f979ee Now python-*client are installed by pip install instead of git clone. I think this change causes the problem. But I don't understand why there are success CIs and failed CIs (include mine) and how to fix the problem. Thanks. Itsuro Oda On Thu, 13 Nov 2014 00:36:41 -0500 Steve Martinelli steve...@ca.ibm.com wrote: About a month ago, we made changes to python-openstackclient that seem related to the error message you posted. Change is https://review.openstack.org/#/c/127655/3/setup.cfg I'm wondering why you are just hitting it now? Does your CI pull the latest python-keystoneclient and python-openstackclient from master? Thanks, _ Steve Martinelli OpenStack Development - Keystone Core Member Phone: (905) 413-2851 E-Mail: steve...@ca.ibm.com From: Itsuro ODA o...@valinux.co.jp To: openstack-dev@lists.openstack.org Date: 11/12/2014 11:27 PM Subject:[openstack-dev] [infra][devstack] CI failed The plugin token_endpoint could not be found Hi, My third party CI becomes failed from about 21:00 12th UTC in execution of devstack. The error occurs at openstack project create admin -f value -c id --- ERROR: openstack The plugin token_endpoint could not be found --- I found some CIs have same problem. Does anyone give me a hint to solve this problem ? Thanks. -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] LeastNetwork scheduling for DHCP
+1 IMHO, it is enough for [1][3] to fix by issuing a bug report. Thanks Itsuro Oda On Thu, 6 Nov 2014 17:20:57 +0100 ZZelle zze...@gmail.com wrote: Hi, iiuc, It seems [1][3] share exactly the same objective and implementation intention: - define an common abstract dhcp scheduler class - define a dhcp LeastNetworkScheduler [2] proposes to - define a dhcp LeastVmScheduler (networks are scheduled on the dhcp agent supporting the least vms (=ports?)) So i am not sure we need an umbrella spec as [1][3] can be merged in [1] (the older wins?) and [2] can become a daughter spec or can be merged with previous spec? Cedric, ZZelle@IRC [1] https://review.openstack.org/104587 [2] https://review.openstack.org/111210 [3] https://review.openstack.org/130912 On Thu, Nov 6, 2014 at 4:39 PM, Narasimhan, Vivekanandan vivekanandan.narasim...@hp.com wrote: Hi Neutron Stackers, There is an interest among vendors to bring Least Networks scheduling for DHCP into Openstack Neutron. Currently there are the following blueprints lying there, all of them trying to address this issue: https://review.openstack.org/111210 https://review.openstack.org/#/c/130912/ https://review.openstack.org/104587 We are trying to pull together all these BPs as one Umbrella BP, on which we can pour volunteers from every side, to clear out this BP itself as initial step. So we would like to collaborate, to plan BP approval for these. Please respond if you are interested. -- Thanks, Vivek ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][QoS] Weekly IRC Meeting?
Hi, I am interested in the meeting but cannot participate (it's 3:00am). I will check the meeting log later. BTW, where do you begin a discussion ? I thought you countinue work in Icehose. Or do you argue from the beginning of the API definition ? Thanks. Itsuro Oda (oda-g) On Wed, 21 May 2014 14:56:09 + Collins, Sean sean_colli...@cable.comcast.com wrote: Hi, The session that we had on the Quality of Service API extension was well attended - I would like to keep the momentum going by proposing a weekly IRC meeting. How does Tuesdays at 1800 UTC in #openstack-meeting-alt sound? -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] addition to requirement wiki
Hi LBaaS developpers, I added 'Status Indication' to requirement Wiki. It may be independent from object model discussion but I think this is an item which should not be forgotten. Thanks. -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPN] Admin status vs operational status
Hi, With my understanding, it should be: * 'status' is a read only attribute which shows to users whether the service is available or not. So for example, VIP status is ACTIVE but the loadblancing service is not available is not allowed. (Actually our customers want to fix this strongly.) * 'admin_state_up' is an attribute for an administrator to set whether the service is available or not. As a result 'status' of the resource and the associated resources become ACTIVE or DOWN. (If it does not work so, it is a problem of the implementation.) Thanks -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][ha][agents] host= parameter
Hi, I haven't found any documentation about it. As far as I discovered, it's being used to provide Active/Passive replication of agents, as you can manage agent's on different hosts to register with the same ID to neutron (of course, *never* at the same time). Yes. We use the host= parameter for the purpose described above. Thanks. -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Enable to set DHCP port attributes
Hi Neutron developers, I added a detailed specification, https://wiki.openstack.org/wiki/Neutron/enable-to-set-dhcp-port-attributes in order to reply comments for the code (https://review.openstack.org/#/c/61026/). Comments are welcome. I hope anything to advance. Thanks. On Tue, 17 Dec 2013 09:01:24 +0900 Itsuro ODA o...@valinux.co.jp wrote: Hi Neutron developers, I submitted the following blue print. https://blueprints.launchpad.net/neutron/+spec/enable-to-set-dhcp-port-attributes It is a proposal to be enable to control dhcp port attributes (especially ip address) by a user. This is based on a real requirement from our customer. I don't know there is a consensus that dhcp port attributes should not be enable to set by a user. Comments are welcome. Thanks. -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [third-party-testing] Reminder: Meeting tomorrow
Hi, It seems the meeting was not held on 2200 UTC on Wednesday (today). Do you mean 2200 UTC on Thursday ? Thanks. On Thu, 12 Dec 2013 11:43:03 -0600 Kyle Mestery mest...@siliconloons.com wrote: Hi everyone: We had a meeting around Neutron Third-Party testing today on IRC. The logs are available here [1]. We plan to host another meeting next week, and it will be at 2200 UTC on Wednesday in the #openstack-meeting-alt channel on IRC. Please attend and update the etherpad [2] with any items relevant to you before then. Thanks again! Kyle [1] http://eavesdrop.openstack.org/meetings/networking_third_party_testing/2013/ [2] https://etherpad.openstack.org/p/multi-node-neutron-tempest ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev On Wed, 18 Dec 2013 15:10:46 -0600 Kyle Mestery mest...@siliconloons.com wrote: Just a reminder, we'll be meeting at 2200 UTC on #openstack-meeting-alt. We'll be looking at this etherpad [1] again, and continuing discussions from last week. Thanks! Kyle [1] https://etherpad.openstack.org/p/multi-node-neutron-tempest ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Enable to set DHCP port attributes
Hi Neutron developers, I submitted the following blue print. https://blueprints.launchpad.net/neutron/+spec/enable-to-set-dhcp-port-attributes It is a proposal to be enable to control dhcp port attributes (especially ip address) by a user. This is based on a real requirement from our customer. I don't know there is a consensus that dhcp port attributes should not be enable to set by a user. Comments are welcome. Thanks. -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Thursday subteam meeting
Hi Eugene, Iwamoto You are correct. Provider attribute will remain in the pool due to API compatibility reasons. I agree with you. I just wanted to make sure pools in a loadblancer can have different providers or not. (I think it should be same.) Thanks Itsuto Ofa On Mon, 2 Dec 2013 12:48:30 +0400 Eugene Nikanorov enikano...@mirantis.com wrote: Hi Iwamoto, You are correct. Provider attribute will remain in the pool due to API compatibility reasons. Thanks, Eugene. On Mon, Dec 2, 2013 at 9:35 AM, IWAMOTO Toshihiro iwam...@valinux.co.jpwrote: At Fri, 29 Nov 2013 07:25:54 +0900, Itsuro ODA wrote: Hi Eugene, Thank you for the response. I have a comment. I think 'provider' attribute should be added to loadbalance resource and used rather than pool's 'provider' since I think using multiple driver within a loadbalancer does not make sense. There can be a 'provider' attribute in a loadbalancer resource, but, to maintain API, the 'provider' attribute in pools should remain the same. Is there any other attribute planned for the loadbalancer resource? What do you think ? I'm looking forward to your code up ! Thanks. Itsuro Oda On Thu, 28 Nov 2013 16:58:40 +0400 Eugene Nikanorov enikano...@mirantis.com wrote: Hi Itsuro, I've updated the wiki with some examples of cli workflow that illustrate proposed API. Please see the updated page: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance#API_change Thanks, Eugene. -- IWAMOTO Toshihiro ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Thursday subteam meeting
Hi Eugene, Thank you for the response. I have a comment. I think 'provider' attribute should be added to loadbalance resource and used rather than pool's 'provider' since I think using multiple driver within a loadbalancer does not make sense. What do you think ? I'm looking forward to your code up ! Thanks. Itsuro Oda On Thu, 28 Nov 2013 16:58:40 +0400 Eugene Nikanorov enikano...@mirantis.com wrote: Hi Itsuro, I've updated the wiki with some examples of cli workflow that illustrate proposed API. Please see the updated page: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance#API_change Thanks, Eugene. On Thu, Nov 28, 2013 at 3:00 AM, Itsuro ODA o...@valinux.co.jp wrote: Hi, I'd like to review about LoadblancerInstance API specification. Please update wiki page before the meeting. (It is a little bit hard to follow in the IRC for me since I'm not English native. so I'd like to consider for the API beforehand.) Thanks. Itsuro Oda On Wed, 27 Nov 2013 14:07:47 +0400 Eugene Nikanorov enikano...@mirantis.com wrote: Hi Neutron folks, LBaaS subteam meeting will be on Thursday, 27, at 14-00 UTC as usual. We'll discuss current progress and continue with feature design. Thanks, Eugene. -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Thursday subteam meeting
Hi, I can't find the 28th meeting log. (Does not logs automatically generated ?) Thanks. -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Thursday subteam meeting
Hi, I found it in /meeting/nuetron_lbaas. (neutron - nuetron) On Fri, 29 Nov 2013 07:51:56 +0900 Itsuro ODA o...@valinux.co.jp wrote: Hi, I can't find the 28th meeting log. (Does not logs automatically generated ?) Thanks. -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Thursday subteam meeting
Hi, I'd like to review about LoadblancerInstance API specification. Please update wiki page before the meeting. (It is a little bit hard to follow in the IRC for me since I'm not English native. so I'd like to consider for the API beforehand.) Thanks. Itsuro Oda On Wed, 27 Nov 2013 14:07:47 +0400 Eugene Nikanorov enikano...@mirantis.com wrote: Hi Neutron folks, LBaaS subteam meeting will be on Thursday, 27, at 14-00 UTC as usual. We'll discuss current progress and continue with feature design. Thanks, Eugene. -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Loadbalancer instance design.
Hi, 2. Loadbalancer can be used to bind configuration to a provider, device, agent (host), router What's the plan about this ? Is an extension for each (eg. add router_id to a loadblancer resource) necessary ? Thanks. Itsuro Oda On Fri, 15 Nov 2013 17:14:47 +0400 Eugene Nikanorov enikano...@mirantis.com wrote: Hi folks, I've created a brief description of this feature. You can find it here: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstancehttps://blueprints.launchpad.net/neutron/+spec/lbaas-service-instance I would appreciate any comments/ideas about this. Thanks, Eugene. -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Object status and admin_state_up
Hi, I think INACTIVE is right for resources with admin_statu_up False. BTW, there are following requirements: * Change to ACTIVE from PENDING_CREATE/UPDATE when the serives is available actually. (ie. after lbaas_agent done the job.) * Reflect a member is alive or not to the 'status' attribute of member resource. (ie. if a member is not alive, the status is DOWN.) Note that we are planning to implement above requiremants to LVS driver. Thanks, Itsuro Oda On Tue, 29 Oct 2013 13:19:16 +0400 Eugene Nikanorov enikano...@mirantis.com wrote: Hi folks, Currently there are two attributes of vips/pools/members that represent a status: 'status' and 'admin_state_up'. The first one is used to represent deployment status and can be PENDING_CREATE, ACTIVE, PENDING_DELETE, ERROR. We also have admin_state_up which could be True or False. I'd like to know your opinion on how to change 'status' attribute based on admin_state_up changes. For instance. If admin_state_up is updated to be False, how do you think 'status' should change? Also, speaking of reference implementation (HAProxy), changing vip or pool admin_state_up to False effectively destroys the balancer (undeploys it), while the objects remain in ACTIVE state. There are two options to fix this discrepancy: 1) Change status of vip/pool to PENDING_CREATE if admin_state_up changes to False 2) Don't destroy the loadbalancer and use HAProxy capability to disable frontend and backend while leave vip/pool in ACTIVE state Please share your opinion. Thanks, Eugene. -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] LBaaS plans for Icehouse
Hi, We have submitted the following LBaaS related BPs: https://blueprints.launchpad.net/neutron/+spec/lbaas-support-routed-service-insertion https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-driver https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-extra-features I can't attend the meeting but I will check the meeting log later. Thanks. Itsuro Oda On Wed, 23 Oct 2013 21:57:13 +0400 Eugene Nikanorov enikano...@mirantis.com wrote: So currently it moves to 10AM PDT Thanks, Eugene. -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] L3 router service integration with Service Type Framework
Hi, We are going to implement 2-arm type lbaas using LVS, and have submitted the following BPs. https://blueprints.launchpad.net/neutron/+spec/lbaas-support-routed-service-insertion https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-driver https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-extra-features Maybe the first one is same as yours. We are happy if we just concentrate making a provider driver. Thanks. Itsuro Oda On Thu, 24 Oct 2013 11:56:53 -0700 Gary Duan gd...@varmour.com wrote: Hi, I've registered a BP for L3 router service integration with service framework. https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type In general, the implementation will align with how LBaaS is integrated with the framework. One consideration we heard from several team members is to be able to support vendor specific features and extensions in the service plugin. Any comment is welcome. Thanks, Gary -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] L3 router service integration with Service Type Framework
Hi Gray, Thanks for your response. Our plan is as follows: * LVS driver is one of lbaas provider driver. It communicates with l3_agent instead of lbaas_agent. * For l3_agent side, I think the implementation is same as fwaas. L3NATAgent inherits like LVSL3AgentRpcCallback class added which communicates with LVS provider driver. So l3_agent functions already existed are not changed, just added LB function. I think the implementation would change depending on the service chaining discussion. Thanks, Itsuto Oda # note that Toshihiro Iwamoto, a main developer of our BPs # may replay instead of me. He will attend the HK summit. On Thu, 24 Oct 2013 16:03:25 -0700 Gary Duan gd...@varmour.com wrote: Hi, Oda-san, Thanks for your response. L3 agent function should remain the same, as one driver implementation of L3 router plugin. My understanding is your lbaas driver can be running on top of L3 agent and LVS' own routing services. Is my understanding correct? Thanks, Gary On Thu, Oct 24, 2013 at 3:16 PM, Itsuro ODA o...@valinux.co.jp wrote: Hi, We are going to implement 2-arm type lbaas using LVS, and have submitted the following BPs. https://blueprints.launchpad.net/neutron/+spec/lbaas-support-routed-service-insertion https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-driver https://blueprints.launchpad.net/neutron/+spec/lbaas-lvs-extra-features Maybe the first one is same as yours. We are happy if we just concentrate making a provider driver. Thanks. Itsuro Oda On Thu, 24 Oct 2013 11:56:53 -0700 Gary Duan gd...@varmour.com wrote: Hi, I've registered a BP for L3 router service integration with service framework. https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type In general, the implementation will align with how LBaaS is integrated with the framework. One consideration we heard from several team members is to be able to support vendor specific features and extensions in the service plugin. Any comment is welcome. Thanks, Gary -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] QoS API Extension update
Hi, I'd like to support linuxbridge QoS. I submmited the following BP: https://blueprints.launchpad.net/neutron/+spec/ml2-qos-linuxbridge I won't attend the summit but Toshihiro, my co-worker will attend the summit and attend the QoS session. Thanks. Itsuro Oda On Wed, 16 Oct 2013 17:21:36 + Alan Kavanagh alan.kavan...@ericsson.com wrote: Cheers Sean I will take a look at the wiki and update accordingly. I took a look at your BP, its right along the lines of what I feel is also needed and what we are planning to submit (being finalised as I write this email) though we are also adding some additional QoS attributes to be supported based on OVS as one source. I took a look at your API and the BP we are going to submit is very much inline and complementary to yours hence why I think we can actually combine them and do a joint pitch on thisat least that’s my thinking on it! Will send BP as soon as its finalised ;-) BR Alan -Original Message- From: Sean M. Collins [mailto:s...@coreitpro.com] Sent: October-16-13 12:08 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron] QoS API Extension update On Wed, Oct 16, 2013 at 03:45:29PM +, Alan Kavanagh wrote: Will hopefully submit that really soon. Perhaps we can look at combining both of them and discuss this in Hong Kong as I have looked over your BP and I can see some benefit in combining them both. Hi Alan, That sounds great - the objective of my BP was to try and make a QoS API extension that was flexible enough that everyone could make their own implementation. At this point, this is accomplished through storing key/value pairs that are linked back to a QoS object, via the policies attribute (which maps to the qos_policies table), that stores implementation specific behavior/configuration. There is also a wiki page, that has some useful links: https://wiki.openstack.org/wiki/Neutron/QoS -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] VIP for LBaaS on same port?
Hi, Please consider the following use case make abailable too: ip address/subnet of vips are same but protocol_port are diffrent. This is not able either currently. Thanks. On Thu, 5 Sep 2013 10:26:36 +0400 Eugene Nikanorov enikano...@mirantis.com wrote: Hi Stephen, Currently it's not possible. But we're planning to change this in near future. There is a blueprint which supposes change in vip-pool relationship (change it from 1:1 to m:n), as part of it's implementation, unconditional l2 port creation will be removed from loadbalancer_db.py Here's a blueprint: https://blueprints.launchpad.net/neutron/+spec/lbaas-multiple-vips-per-pool Here's a link to review which removes port creation and moves it into the plugin driver instead: https://review.openstack.org/#/c/41396/ Currently the patch is abandoned until Icehouse, but you can experiment with it. Feel free to ask any further questions. Thanks, Eugene. On Thu, Sep 5, 2013 at 10:13 AM, Stephen Gran stephen.g...@theguardian.comwrote: Hi, One of the things I'll be looking at in the near future is writing a driver for the neutron lbaas service to talk to a bit of hardware we have. The normal idiom with this hardware is to have a single interface, with multiple IP addresses attached. It doesn't look like this is currently possible in the lbaas model - loadbalancer_db.py unconditionally creates a port. What I am hoping to be able to do is create instances within openstack based on appliance images, give them a neutron port on the right subnet, and then add secondary IPs as people create loadbalancers. This would also give us the flexibility to attach security groups to that single port more easily, but that's a nice side effect. Does this sound possible? What would be the best way of achieving this, given the way things work currently? Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. --**--**-- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphoneand our iPad edition theguardian.com/iPad Save up to 32% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 --**--** -- __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] LBaaS routed insertion implementation
Hi, I am interested in 5. Routed insertion implementation which is mentioned in the Neutron/LBaaS/HavanaPlan wiki page. What is the current status of this ? Thanks. -- Itsuro ODA o...@valinux.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
