Open Stack

Kevin,

Quick question.
Does one OpenStack infrastructure have to be dedicated for one Jacket instance?

Cheers,
Shinobu


On Thu, Mar 24, 2016 at 8:24 PM, Kevin.ZhangSen <okay22many at 163.com> wrote:
> 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
>
>
>
>
>
>
> __________________________________________________________________________
> 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
>



-- 
Email:
shinobu at linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource