L3 routed network can support
1. broadcast/multicast
2. VRRP virtual MAC like technology
For example OpenContrail does support both of these in fully L3 routed
networks.
Regards
-Harshad
On Tue, Oct 28, 2014 at 4:59 PM, Angus Lees g...@inodes.org wrote:
On Tue, 28 Oct 2014 09:07:03 PM Rohit
1. Feature is giving AWS VPC api compatibility with existing openstack
structure
2. It does give full AWS compatibility (except for network ACL which was
differed). Shared networks, FIP within scope of VPC is not some thing AWS
provides. So it is not partial support.
3. IMO it would not be major
Yes, [1] can be done without [2] and [3].
As you are well aware [2] is now merged with group policy discussions.
IMHO all or nothing approach will not get us anywhere.
By the time we line up all our ducks in row. New features/ideas/blueprints
will keep Emerging.
Regards
-Harshad
On Feb 16,
or VDC (virtual openstack or virtual DC)
as all or most of current openstack features are available to user in this
new Abstraction. I actually like this new abstraction.
Subbu
On Feb 15, 2014, at 10:04 PM, Harshad Nakil hna...@contrailsystems.com
wrote:
I agree with problem as defined
IMHO I don't see two implementations. Since right now we have only
one. As a community if we decide to add new abstractions then we will
have to change software in every component where the new abstraction
makes difference. That's normal software development process.
Regards
-Harshad
On Feb 16,
as defined by you and will require more fundamental
changes.
Meanwhile many users will benefit from AWS VPC api compatibility.
JC
On Feb 15, 2014, at 8:47 AM, Harshad Nakil hna...@contrailsystems.com
wrote:
EIP will be allocated from public pools. So in effect public pools and
shared networks
Hi JC,
You have put it aptly. Goal of the blueprint is to present facade for
AWS VPC API as the name suggest.
As per your definition of VPC, shared network will have issues.
However many of these concepts are not exposed to a AWS customers and
the API work well.
While we work incrementally
Sean,
We have diff in three repositories.
Nova, Neutron and devstack. Each review is requiring other to happen first.
Do you have recommendation how do we deal with these dependencies?
Regards
-Harshad
On Nov 16, 2013, at 9:11 AM, Sean Dague s...@dague.net wrote:
For something to go in
Kyle,
These requirement should also be required for existing third plugins.
Will you allow new patches to existing plugins without this requirement?
I hope we don't end up creating multiple classes of citizens.
Regards
-Harshad
On Nov 12, 2013, at 7:08 PM, Kyle Mestery (kmestery)
+1
Regards
-Harshad
On Nov 6, 2013, at 12:36 AM, Radomir Dopieralski openst...@sheep.art.pl
wrote:
Hello,
I'm quite new in the OpenStack project, but I love it already. What is
especially nifty is the automated review system -- I'm really impressed.
I'm coming from a project in which
will support pinning the service VM to a particular
tenant owning a service instance.
Thanks,
Bob
From: Harshad Nakil hna...@contrailsystems.com
Reply-To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Date: onsdag 9 oktober 2013 18:56
To: OpenStack Development Mailing List
Agree,
I like what AWS had done. Have a concept of NAT instance. 90 % use cases
are solved by just specifying
Inside and outside networks for the NAT instance.
If one wants fancier NAT config they can always use NATaas API(s)
To configure this instance.
There is a blueprint for bringing Amazon
Hello Greg,
Blueprint you have put together is very much in line what we have done in
openContrail virtual services implementation.
One thing that we have done is Service instance is a single type of
service provided by virtual appliance.
e.g. firewall or load-balancer etc
Service instance
13 matches
Mail list logo
