Open Stack

On Tue, Jul 11, 2017 at 1:43 AM, Monty Taylor <mordred at inaugust.com> wrote:

> On 07/10/2017 04:31 PM, Mikhail Fedosin wrote:
>
>> Thank you for asking this! It's really very important and interesting, so
>> I'm going to explain those things more detailed.
>>
>> First, when we designed Glare, we kept in mind the compatibility with
>> Glance, and I can tell that Glance data from the database can be ported to
>> Glare with a simple script without any loss.
>>
>> Second, APIs are very similar and map 1:1. The only one big difference is
>> that user has to perform activation manually after image file is uploaded.
>> I created a small table with the most popular API requests. You may notice
>> how similar both APIs are: https://docs.google.com/docume
>> nt/d/18Tqad0NUPyFfHUo1KMr6bDDISpQtzacvZtEQIGhNkf4/edit?usp=sharing
>> Other changes are rather cosmetic. For instance, "queued" image status
>> was renamed to "drafted".
>>
>> Third, all these changes can be hidden in Glare client. So if we try a
>> little, we can achieve 100% compatibility there, and other projects can use
>> Glare client instead of Glance's without even noticing the differences.
>>
>
> I think we should definitely not do this... I think instead, if we decide
> to go down this road, we want to look at adding an endpoint to glare that
> speaks glance v2 API so that users can have a transition period while
> libraries and tools get updated to understand the artifacts API.


This is optional and depends on the project developers. For my part, I can
only offer the most compatible client, so that the Glance module can be
simply copied into the new Glare module.


>
> If projects use Glance without client, it means that some direct API
>> requests will need to be rewritten. But in any case, the number of
>> differences between Glance v1 and Glance v2 was much larger, and we
>> switched pretty smoothly. So I hope everything will be fine here, too.
>>
>
> v1 vs v2 is still a major headache for end users. I don't think it's ok
> for us to do that to our users again if we can help it.
>
> However, as you said, conceptually the calls are very similar so making an
> API controller that can be registered in the catalog as "image" should be
> fairly easy to do, no?
>
Indeed, the interfaces are almost identical. And all the differences were
made on purpose.

For example, deactivating an image in Glance looks like *POST*
/v2/images/{image_id}/actions/deactivate with empty body.
At one time, Chris Dent advised us to avoid such decisions, and simply
change the status of the artifact to 'deactivated' using *PATCH*, which we
did.

>
> Best,
>> Mike Fedosin
>>
>> On Mon, Jul 10, 2017 at 9:55 PM, Joshua Harlow <harlowja at fastmail.com
>> <mailto:harlowja at fastmail.com>> wrote:
>>
>>     Ed Leafe wrote:
>>
>>         On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin <mfedosin at gmail.com
>>         <mailto:mfedosin at gmail.com>
>>         <mailto:mfedosin at gmail.com <mailto:mfedosin at gmail.com>>> wrote:
>>
>>             Given all the advantages and features of Glare, I believe
>>             that it can
>>             become the successful drop-in replacement.
>>
>>
>>         Can you clarify this? Let’s assume I have a decent-sized
>> deployment
>>         running Glance. If I were to remove Glance and replace it with
>>         Glare,
>>         are you saying that nothing would break? Operators, users,
>> scripts,
>>         SDKs, etc., would all work unchanged?
>>
>>
>>     Sounds interesting,
>>
>>     Is there some kind of glance-compat API?
>>
>>
>>         -- Ed Leafe
>>
>>
>>
>>
>>
>>         ____________________________________________________________
>> ______________
>>         OpenStack Development Mailing List (not for usage questions)
>>         Unsubscribe:
>>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>         <http://OpenStack-dev-request@lists.openstack.org?subject:un
>> subscribe>
>>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> <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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>> >
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>     <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:unsubscrib
>> e
>> 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/20170711/7742682c/attachment.html>