Open Stack

Hi Shinobu,

Thanks for your questions. My reply is behind your questions. :)

Best Regards,
Kevin (Sen Zhang)


At 2016-03-17 12:43:14, "Shinobu Kinjo" <shinobu.kj at gmail.com> wrote:
>Thank you for your explanation in detail.
>
>On Thu, Mar 17, 2016 at 12:57 PM, zs <okay22many at 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?
Kevin: Yes, it will.
>>     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?
Kevin: Sorry, I don't agree with you. Jacket will record the resources' status. For example, in case of creating snapshot in AWS, Jacket will query the job's status periodically, before Jacket get the real snapshot id in AWS. At this time users query the snapshot's status, Jacket will return 'Pending' defined by Jacket. But Tricircle is developed with stateless design, they are conflicting. If we do that like you say, I think there will be a bottleneck for Tricircle to manage a more large scale VMs, and then we still need a stateless layer just like the current Tricircle solution. So my opinion is to simplify each layer's function, let each layer do their job. :)
>> 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:
Kevin: Not exactly. We need solve the account management, unified flavor, unified image and how to take over the legacy resources in the provider clouds. Jacket's wiki has the description about these: https://wiki.openstack.org/wiki/Jacket  :) 
>    > 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.kj at gmail.com> wrote:
>>>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.
>>>
>>>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" <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
>>>>
>>>
>>>
>>>
>>>--
>>>Email:
>>>shinobu at 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-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
>
>__________________________________________________________________________
>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/20160317/11336274/attachment-0001.html>