[openstack-dev] VPC Proposal
Martin, JC
jch.martin at gmail.com
Tue Feb 18 18:03:14 UTC 2014
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 implementing full AWS capabilities and semantic (e.g. Shared network isolation from VPC, or Floating IP scoping to VPC).
- Dependent blueprints are not implemented and have been deferred, resulting in the broken implementation (e.g. https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron)
- this "feature" is only available through EC2 API, which is likely going to result in another implementation for general use.
- users adopting the VPC model proposed through EC2 API will be stuck in an upgrade mess when the proper implementation comes along.
- There are new constructs in work that are better suited for implementing this concept properly (Multi tenant hierarchy and domains).
As you can guess, I'm not really a fan, but it seems that only few individuals are concerned. I would think that this topic would create more interest, specially on the network side. Maybe because of the subject tags. I will therefore copy this email with the Neutron tag.
JC
On Feb 17, 2014, at 10:10 PM, Rudra Rugge <rrugge at juniper.net> wrote:
> 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, "jc Martin" <jch.martin at gmail.com> wrote:
>
>> 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 <rrugge at juniper.net> 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.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 with the next path.
>>> 2. https://review.openstack.org/#/c/53171
>>> This is the active review for tempest
>>> test cases as requested by Joe Gordon.
>>> Currently abandoned until #1 goes through.
>>> 3. https://review.openstack.org/#/c/53171
>>> This review is not active. It was accidentally submitted with a new
>>> change-id.
>>>
>>> Regards,
>>> Rudra
>>>
>>>> On 2/16/14, 9:25 AM, "Martin, JC" <jch.martin at gmail.com> 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.org/#/c/53171
>>>>
>>>> because they are all abandoned.
>>>>
>>>> Could you point me to the code, and update the BP because it seems that
>>>> the links are not correct.
>>>>
>>>> Thanks,
>>>>
>>>> JC
>>>>> On Feb 16, 2014, at 9:04 AM, "Allamaraju, Subbu" <subbu at subbu.org>
>>>>> wrote:
>>>>>
>>>>> 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 that
>>>>>> community
>>>>>> was interested as the blueprint was approved and code review has no
>>>>>> -1(s) for long time now.
>>>>>
>>>>> Makes sense. I would leave it to others on this list to chime in if
>>>>> there is sufficient interest or not.
>>>>>
>>>>>> To clarify, a clear incremental path from an AWS compatible API to an
>>>>>> OpenStack model is not clear.
>>>>>>
>>>>>> In my mind AWS compatible API does not need new openstack model. As
>>>>>> more discussion happen on JC's proposal and implementation becomes
>>>>>> clear we will know how incremental is the path. But at high level
>>>>>> there
>>>>>> two major differences
>>>>>> 1. New first class object will be introduced which effect all
>>>>>> components
>>>>>> 2. more than one project can be supported within VPC.
>>>>>> But it does not change AWS API(s). So even in JC(s) model if you want
>>>>>> AWS API then we will have to keep VPC to project mapping 1:1, since
>>>>>> the
>>>>>> API will not take both VPC ID and project ID.
>>>>>>
>>>>>> As more users want to migrate from AWS or IaaS providers who want
>>>>>> compete with AWS should be interested in this compatibility.
>>>>>
>>>>> IMHO that's a tough sell. Though an AWS compatible API does not need
>>>>> an
>>>>> OpenStack abstraction, we would end up with two independent ways of
>>>>> doing similar things. That would OpenStack repeating itself!
>>>>>
>>>>> Subbu
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list