Open Stack

Hi Ghanshyam,

Thank you for your sugesstions, and I agree with your opinion that the service outside OpenStack is better. In fact I am considering what API Jacket will offer. It is better to offer the OpenStack API directly. But there will be a question how to modify as little code as possible to keep the same API compatibility with OpenStack after OpenStack updates the API version. I think this will be an interesting question, but we can try to let Jacket offer the OpenStack API.



The reply about other query is below. If there are any questions, please tell me. Thank you again.


Best Regards,
Kevin (Sen Zhang)


At 2016-03-24 11:58:47, "GHANSHYAM MANN" <ghanshyammann at gmail.com> wrote:
>Hi Kevin,
>
>Its always nice idea as jacket has but not sure how feasible and
>valuable it would be. For doing API translation and gateway, there are
>many available and one I remember is Aviator (based on ruby gem) [1],
>not sure how active it is now.
>
>As your idea is more about consuming all differences between different
>cloud, few query-
>
> 1. Different clouds have very much different API model and feature
>they provides, how  worth it is to provide missing/different features
>at jacket layer? its then kind of another layer of cloud layer you
>will end up.
Kevin: We will provide the commonly used functions to let the users manage the different clouds just like one kind of cloud, for example VMs management(create/destroy/start/stop/restart/rebuild...) and volume management(create/delete/backup/snapshot). About network, there is a solution to use neutron to offer network function through the overlay virtual network based on the provider clouds’ virtual network. This will be another project, not in Jacket.
> 2. To support that idea through OpenStack standard API, you need to
>inserting jacket driver all over the components which end up having
>another layer gets inserted there. Maintainability of that is another
>issue for each OpenStack components.
Kevin: I agree with you. Jacket offer OpenStack will be better.
>IMO, outside layer (from OpenStack ) which can do all these would be
>nice something which can redirect API services at top level top and do
>what all conversion, consume difference etc.
>
>[1] https://github.com/aviator/aviator
>
>Regards
>Ghanshyam Mann
>
>
>On Wed, Mar 16, 2016 at 9:58 PM, zs <okay22many at 163.com> wrote:
>> Hi Gordon,
>>
>> Thank you for your suggestion.
>>
>> I think jacket is different from tricircle. Because tricircle focuses on
>> OpenStack deployment across multiple sites, but jacket focuses on how to
>> manage the different clouds just like one cloud.  There are some
>> differences:
>> 1. Account management and API model: Tricircle faces multiply OpenStack
>> instances which can share one Keystone and have the same API model, but
>> jacket will face the different clouds which have the respective service and
>> different API model. For example, VMware vCloud Director has no volume
>> management like OpenStack and AWS, jacket will offer a fake volume
>> management for this kind of cloud.
>> 2. Image management: One image just can run in one cloud, jacket need
>> consider how to solve this problem.
>> 3. Flavor management: Different clouds have different flavors which can not
>> be operated by users. Jacket will face this problem but there will be no
>> this problem in tricircle.
>> 4. Legacy resources adoption: Because of the different API modles, it will
>> be a huge challenge for jacket.
>>
>> I think it is maybe a good solution that jacket works to unify the API model
>> for different clouds, and then using tricircle to offer the management of  a
>> large scale VMs.
>>
>> Best Regards,
>> Kevin (Sen Zhang)
>>
>>
>> At 2016-03-16 19:51:33, "gordon chung" <gord at live.ca> wrote:
>>>
>>>
>>>On 16/03/2016 4:03 AM, zs wrote:
>>>> Hi all,
>>>>
>>>> There is a new project "jacket" to manage multiply clouds. The jacket
>>>> wiki is: https://wiki.openstack.org/wiki/Jacket
>>>>   Please review it and give your comments. Thanks.
>>>>
>>>> Best Regards,
>>>>
>>>> Kevin (Sen Zhang)
>>>>
>>>>
>>>
>>>i don't know exact details of either project, but i suggest you
>>>collaborate with tricircle project[1] because it seems you are
>>>addressing the same user story (and in a very similar fashion). not sure
>>>if it's a user story for OpenStack itself, but no point duplicating
>>> efforts.
>>>
>>>[1] https://wiki.openstack.org/wiki/Tricircle
>>>
>>>cheers,
>>>
>>>--
>>>gord
>>>
>>>__________________________________________________________________________
>>>OpenStack Development Mailing List (not for usage questions)
>>>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160324/8c0ce623/attachment.html>