Re: [openstack-dev] [Neutron] DVR SNAT shortcut

2014-06-25 Thread McCann, Jack
If every compute node is assigned a public ip, is it technically able to improve SNAT packets w/o going through the network node ? It is technically possible to implement default SNAT at the compute node. One approach would be to use a single IP address per compute node as a default SNAT

[openstack-dev] [neutron] status of VPNaaS and FWaaS APIs in Icehouse

2014-04-23 Thread McCann, Jack
Are VPNaaS and FWaaS APIs still considered experimental in Icehouse? For VPNaaS, [1] says This extension is experimental for the Havana release. For FWaaS, [2] says The Firewall-as-a-Service (FWaaS) API is an experimental API... Thanks, - Jack [1]

Re: [openstack-dev] [neutron] status of VPNaaS and FWaaS APIs in Icehouse

2014-04-24 Thread McCann, Jack
: [openstack-dev] [neutron] status of VPNaaS and FWaaS APIs in Icehouse On Apr 23, 2014, at 6:20 PM, McCann, Jack jack.mcc...@hp.com wrote: Are VPNaaS and FWaaS APIs still considered experimental in Icehouse? For VPNaaS, [1] says This extension is experimental for the Havana release

Re: [openstack-dev] [Neutron][Security Groups] Pings to router ip from VM with default security groups

2014-05-20 Thread McCann, Jack
I think this is a combination of two things... 1. When a VM initiates outbound communications, the egress rules allow associated return traffic. So if you allow outbound echo request, the return echo reply will also be allowed. 2. The router interface will respond to ping. - Jack From:

Re: [openstack-dev] [Neutron] reservation of fixed ip

2014-05-23 Thread McCann, Jack
From the original ask: I know that there is possibility to create port with IP and later connect VM to this port. This solution is almost ok for me but problem is when user delete this instance - then port is also deleted and it is not reserved still for the same user and tenant. This

Re: [openstack-dev] [Neutron] reservation of fixed ip

2014-05-23 Thread McCann, Jack
Jack, Do you mean this change by any chance? https://review.openstack.org/#/c/77043/ Salvatore On 23 May 2014 15:10, McCann, Jack jack.mcc...@hp.commailto:jack.mcc...@hp.com wrote: From the original ask: I know that there is possibility to create port with IP and later connect VM to this port

Re: [openstack-dev] About multihost patch review

2013-08-28 Thread McCann, Jack
That said, If there is potential value in offering both, it seems like it should be under the control of the deployer not the user. In other words the deployer should be able to set the default network type and enforce whether setting the type is exposed to the user at all. +1 From my

Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without topping sevices

2015-01-08 Thread McCann, Jack
+1 on need for this feature The way I've thought about this is we need a mode that stops the *automatic* scheduling of routers/dhcp-servers to specific hosts/agents, while allowing manual assignment of routers/dhcp-servers to those hosts/agents, and where any existing routers/dhcp-servers on

Re: [openstack-dev] [Neutron] Issue when upgrading from Juno to Kilo due to agent report_state RPC namespace patch

2015-03-06 Thread McCann, Jack
+1 on avoiding changes that break rolling upgrade. Rolling upgrade has been working so far (at least from my perspective), and as openstack adoption spreads, it will be important for more and more users. How do we make rolling upgrade a supported part of Neutron? - Jack -Original