Open Stack

On Tue, Feb 18, 2014 at 10:03 AM, Martin, JC <jch.martin at gmail.com> 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 that way. I see this BP as converting neutron calls
into AWS VPC calls with a little glue (which can be seen here
https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support). But I am
no networking expert, so take that with a large grain of salt.

>    - 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).

A partial implementation is better then no implementation, that being
said if we want to overhaul OpenStack's VPC capabilities I think the
partial implementation would have to be thrown out.

>    - 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)

That is a requirement for phase 3, and shouldn't matter for phase 1
and 2. And only phase 1 is up for review.

>    - 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.

This point concerns me the most, can you elaborate.

>    - There are new constructs in work that are better suited for implementing this concept properly (Multi tenant hierarchy and domains).


All that being said, it sounds like there are two separate efforts to
get VPC into OpenStack, one by supporting AWS specs, and a second
native OpenStack version.  It sounds like further discussion is needed
between these two efforts, so I am unapproving
https://blueprints.launchpad.net/nova/+spec/aws-vpc-support as it
needs further discussion.  The last thing we want is to merge a
controversial blueprint before all the questions can be resolved.

>
> 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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev