JC,
We have a complete implementation which I had submitted earlier. But since the
code was too large the community decided to move forward in a phased approach.
The plan is to provide close to complete compatibility in a multi-phase manner
as mentioned in the blueprint. Phase 4 (internet gatew
Comments in line.
JC
On Feb 18, 2014, at 5:21 PM, Rudra Rugge wrote:
> Please see inline:
>
> On Feb 18, 2014, at 2:57 PM, Martin, JC wrote:
>
>> Maybe I should explain this one a bit.
>>
>> Shared network: If a user has defined a shared network, and they used your
>> API to create a VPC, t
Please see inline:
On Feb 18, 2014, at 2:57 PM, Martin, JC wrote:
> Maybe I should explain this one a bit.
>
> Shared network: If a user has defined a shared network, and they used your
> API to create a VPC, the instances within the VPC will automatically get an
> interface on the shared net
Maybe I should explain this one a bit.
Shared network: If a user has defined a shared network, and they used your API
to create a VPC, the instances within the VPC will automatically get an
interface on the shared network. I don't think that this is the expected
behavior
FIP in scope of VPC: I
On Tue, Feb 18, 2014 at 1:01 PM, Martin, JC wrote:
> Joe,
>
> See my comments in line.
>
> On Feb 18, 2014, at 12:26 PM, Joe Gordon wrote:
>
>> On Tue, Feb 18, 2014 at 10:03 AM, Martin, JC wrote:
>>> There was a lot of emails on that thread, but I am not seeing the
>>> discussion converging. I
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
Joe,
See my comments in line.
On Feb 18, 2014, at 12:26 PM, Joe Gordon wrote:
> On Tue, Feb 18, 2014 at 10:03 AM, Martin, JC wrote:
>> There was a lot of emails on that thread, but I am not seeing the discussion
>> converging. I would like to reiterate my concerns:
>>
>> - We are trying to
On Tue, Feb 18, 2014 at 10:03 AM, Martin, JC wrote:
> There was a lot of emails on that thread, but I am not seeing the discussion
> converging. I would like to reiterate my concerns:
>
>- We are trying to implement an API on a feature that is not supported by
> openstack
I don't see it tha
There was a lot of emails on that thread, but I am not seeing the discussion
converging. I would like to reiterate my concerns:
- We are trying to implement an API on a feature that is not supported by
openstack
- As a result, the implementation is overloading existing construct without
I am not sure on how to dig out the archives. There were a couple of
emails exchanged with Salvatore on the thread pertaining to the extensions
we were referring to as part of this blueprint.
There are a few notes on the whiteboard of the blueprint as well.
Regards,
Rudra
On 2/17/14, 1:28 PM, "
Thanks,
Do you have the links for the discussions ?
Thanks,
JC
Sent from my iPhone
> On Feb 17, 2014, at 11:29 AM, Rudra Rugge wrote:
>
> JC,
>
> BP has been updated with the correct links. I have removed the abandoned
> review #3.
> Please review #1 and #2.
>
> 1. https://review.openstack
JC,
BP has been updated with the correct links. I have removed the abandoned
review #3.
Please review #1 and #2.
1. https://review.openstack.org/#/c/40071/
This is the active review.
There is one comment by Sean regarding
adding a knob when Neutron is not used.
That will be addressed
IMO, VPC means to have managed set of resources not just limited to
networks but also projects.
I feel its not about incrementally starting with AWS compatibility, But
doing it right with AWS compatibility into consideration.
Thanks,
-Ravi.
On Sun, Feb 16, 2014 at 8:47 AM, Harshad Nakil
wrote:
Harshad,
I tried to find some discussion around this blueprint.
Could you provide us with some notes or threads ?
Also, about the code review you mention. which one are you talking about :
https://review.openstack.org/#/c/40071/
https://review.openstack.org/#/c/49470/
https://review.openstack.or
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,
Harshad,
Thanks for clarifying.
> We started looking at this as some our customers/partners were interested in
> get AWS API compatibility. We have this blueprint and code review pending for
> long time now. We will know based on this thread wether the community is
> interested. But I assumed
Comments Inline
Regards
-Harshad
On Sat, Feb 15, 2014 at 11:39 PM, Allamaraju, Subbu wrote:
> Harshad,
>
> Curious to know if there is a broad interest in an AWS compatible API in
> the community?
We started looking at this as some our customers/partners were interested
in get AWS API compat
Harshad,
Curious to know if there is a broad interest in an AWS compatible API in the
community? To clarify, a clear incremental path from an AWS compatible API to
an OpenStack model is not clear.
Subbu
On Feb 15, 2014, at 10:04 PM, Harshad Nakil wrote:
>
> I agree with problem as defined b
ve-boundary
>>
>>
>> Thanks,
>> Arvind
>> -Original Message-
>> From: Martin, JC [mailto:jch.mar...@gmail.com]
>> Sent: Friday, February 14, 2014 12:09 PM
>> To: OpenStack Development Mailing List
>> Subject: [openstack-dev] VPC Prop
Comments Inline
Regards
-Harshad
On Sat, Feb 15, 2014 at 3:18 PM, Martin, JC wrote:
> Harshad,
>
> Thanks, What happens when I create two VPC ? Beside the project private
> networks, what is isolated ?
>
Since VPC is mapped to project. All the isolation provided by the project
is available.
Harshad,
Thanks, What happens when I create two VPC ? Beside the project private
networks, what is isolated ?
What do you call DC admin ? I know two administrators :
- Cloud administrators
- VPC admnistrator
Are you saying that VPCs cannot have their own external gateways and NAT pools
EIP will be allocated from public pools. So in effect public pools and
shared networks are only DC admin functions. Not available to VPC
users.
There is a implicit external gateway. When one creates NAT instance or
VPN instance, external interfaces of these interfaces come from the
shared network w
Harshad,
I'm not sure to understand what you mean by :
> However many of these concepts are not exposed to a AWS customers and
> the API work well.
So for example in :
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#VPC_EIP_EC2_Differences
When it says :
"When
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
Rudra,
I do not agree that the current proposal provides the semantic of a VPC. If the
goal is to only provide a facade through the EC2 API, it may address this, but
unless you implement the basic features of a VPC, what good is it doing ?
I do believe that the work can be done incrementally if
Hi JC,
We agree with your proposed model of a VPC resource object. Proposal you are
making makes sense to us and we would like to collaborate further on this.
After reading your blueprint two things come to mind.
1. VPC vision for Openstack? (Your blueprint is proposing this vision)
2. Providin
Joe,
I will let others comment, but since I think this BP was proposed much before
the multi-tenant hierarchy BP, I would like to at least have the discussion. I
would suggest a pause until we agree that this is ok to move this forward
independently of the multi tenant hierarchy proposal.
JC
n, JC [mailto:jch.mar...@gmail.com]
> Sent: Friday, February 14, 2014 12:09 PM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] VPC Proposal
>
>
> There is a Blueprint targeted for Icehouse-3 that is aiming to implement the
> AWS VPC api. I don't
On Fri, Feb 14, 2014 at 12:09 PM, Martin, JC wrote:
>
> There is a Blueprint targeted for Icehouse-3 that is aiming to implement the
> AWS VPC api. I don't think that this blueprint is providing the necessary
> constructs to really implement a VPC, and it is not taking into account the
> domain
, February 14, 2014 12:09 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] VPC Proposal
There is a Blueprint targeted for Icehouse-3 that is aiming to implement the
AWS VPC api. I don't think that this blueprint is providing the necessary
constructs to really implement
There is a Blueprint targeted for Icehouse-3 that is aiming to implement the
AWS VPC api. I don't think that this blueprint is providing the necessary
constructs to really implement a VPC, and it is not taking into account the
domains, or proposed multi tenant hierarchy. In addition, I could no
31 matches
Mail list logo
