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 wrote:
> On Tue, 28 Oct 2014 09:07:03 PM Rohit Agarwalla wrote:
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 ch
jects and domains. Thanks for any
> pointers.
>
> Subbu
>
>> On Feb 16, 2014, at 8:01 AM, Harshad Nakil
>> wrote:
>>
>> Yes, [1] can be done without [2] and [3].
>> As you are well aware [2] is now merged with group policy discussions.
>> IMHO all
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,
"VPC"
then what JC is proposing "VOS" 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, Harsha
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, 2014,
er building
blocks in openstack.
I agree with problem 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
> wrote:
>
> > EIP will be allocated from pub
gateways that need to be isolated, I'm not sure that it will provide parity
> anyway with what EC2 provides.
>
>
> Maybe I missed something.
>
>
> JC
>
>> On Feb 14, 2014, at 7:35 PM, Harshad Nakil
>> wrote:
>>
>> Hi JC,
>>
>> You hav
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 towards
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 wrote:
>
> For something to go in devstack, it has
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)"
> wrote:
+1
Regards
-Harshad
> On Nov 6, 2013, at 12:36 AM, Radomir Dopieralski
> 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 we also did revi
Bump in wire service can be within network (intra network) as you suggest
OR between network ( inter network ).
Advantage of bump in wire is one does not need networking config inside the
service.
Inter network bump in wire service is analogous to having service inserted
on link between two router
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 VP
s
control in openstack will support pinning the service VM to a particular
tenant owning a service instance.
Thanks,
Bob
From: Harshad Nakil
Reply-To: OpenStack Development Mailing List <
openstack-dev@lists.openstack.org>
Date: onsdag 9 oktober 2013 18:56
To: OpenStack Development
Admin creating service instance for a tenant could common use case. But
ownership of service can be controlled via already existing access control
mechanism in openstack. If the service instance belonged to a particular
project then other tenants should by definition should not be able to use
this
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" it
17 matches
Mail list logo
