On Tue, Jul 11, 2017 at 1:43 AM, Monty Taylor <mord...@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 <harlo...@fastmail.com >> <mailto:harlo...@fastmail.com>> wrote: >> >> Ed Leafe wrote: >> >> On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin <mfedo...@gmail.com >> <mailto:mfedo...@gmail.com> >> <mailto:mfedo...@gmail.com <mailto:mfedo...@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-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@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-requ...@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-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
