Thank you for your explanation in detail.
On Thu, Mar 17, 2016 at 12:57 PM, zs <okay22m...@163.com> wrote:
> Hi Shinobu,
>
> There are some differences between clouds, the major task of jacket is how
> to shield the differences. So that jacket will not be an API gateway, it has
> the objects management and function processing, for example :
> 1. Unified resource uuid allocation: When users call jacket resource create
> API, jacket will allocate the uuid for the resource according to jacket's
> uuid format, then jacket will associate it with the unique identification in
> provider cloud, because of the different unique identification and the
> different behaviour in clouds.
The Jacket will absorb the difference between clouds, won't it?
> e.g. a) AWS can't support to create a volume from an AMI image and
> boot a virtual machine from a boot volume, so that when users create a
> volume from an image, jacket will just create a volume record in database,
> after the virtual machine is created in AWS, jacket will get the boot
> volume's uuid in AWS and write the relations into the mapping table in
> database.
> b) Creating a volume's snapshot, AWS will return a job id, and
> users will get the snapshot's id after the job startes. Jacket will return
> the snapshot's id in jacket, then jacket will query the snapshot's id in AWS
> and write the relations into the mapping table in database.
>
Then will the Tricircle make use of mapped uuid to manage whatever
created resource, If both components will interact each other?
> 2. Fake volume management: Some clouds have not the complete volume
> management, for example, VMware vCloud Director have no the boot volume
> object, and it can't support volume's backup and snapshot, so that jacket
> will implement these functions for this kind of clouds.
>
Reading your explanation, at the initial stage of the Jacket, it seems
to focus on management of the Cinder resource, but it aims to:
> There will be more differences of clouds' behaviour and function. Jacket's
> target is to shield these differences and let users feel that
they are using
> just one cloud.
Cheers,
Shinobu
> Thanks.
>
> Best Regards,
> Kevin (Sen Zhang)
>
>
> At 2016-03-17 05:47:35, "Shinobu Kinjo" <shinobu...@gmail.com> wrote:
>>On Wed, Mar 16, 2016 at 9:58 PM, zs <okay22m...@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.
>>
>>The Jacket will be kind of API gateway for different cloud systems, won't
>> it?
>>
>>> 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" <g...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>>--
>>Email:
>>shin...@linux.com
>>GitHub:
>>shinobu-x
>>Blog:
>>Life with Distributed Computational System based on OpenSource
>>
>>__________________________________________________________________________
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
