+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 those
gt; Subject: Re: [openstack-dev] [neutron] status of VPNaaS and FWaaS APIs in
> Icehouse
>
>
> On Apr 23, 2014, at 6:20 PM, McCann, Jack wrote:
>
> > Are VPNaaS and FWaaS APIs still considered experimental in Icehouse?
> >
> > For VPNaaS, [1] says "This
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: Na
>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
Jack,
Do you mean this change by any chance?
https://review.openstack.org/#/c/77043/
Salvatore
On 23 May 2014 15:10, McCann, Jack
mailto: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 thi
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] http://docs.openstack.org/api/openstack-ne
> >> 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
defaul
> 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
+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 Messag
