Open Stack

On Wed, Jul 12, 2017 at 1:21 AM, Monty Taylor <mordred at inaugust.com> wrote:
> On 07/11/2017 06:47 AM, Flavio Percoco wrote:
>>
>> On 11/07/17 14:20 +0300, Mikhail Fedosin wrote:
>>>
>>> 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:
>>>>>
>>>>> 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.
>>
>>
>> Unfortunately, adding this sort of logic to the client is almost never the
>> right
>> choice. To be completely honest, I'm not even convinced having a
>> Glance-like API
>> in Glare is the right thing to do. As soon as that API hits the codebase,
>> you'll
>> have to maintain it.
>>
>> Anything that delays the transition to the new thing is providing a fake
>> bridge
>> to the users. It's a bridge that will be blown-up eventually.
>>
>> To make a hypothetical transition from Glance to Glare works smoothly, we
>> should
>> first figure out how to migrate the database (assuming this has not been
>> done
>> yet), how to migrate the images, etc. Only when these things have been
>> figured
>> out, I'd start worrying about what compatibility layer we want to provide.
>> The
>> answer could also be: "Hey, we're sorry but, the best thing you can do is
>> to
>> migrate your code base as soon as possible".
>
>
> I think this is a deal breaker. The problem is - if glare doesn't provide a
> v2 compat layer, then a deployer is going to have to run glance AND glare at
> the same time and we'll have to make sure both glance and glare can write to
> the same backend.
>
> The reason is that with our major version bumps both versions co-exist for a
> period of time which allows consumers to gracefully start consuming the
> nicer and newer api while not being immediately broken when the old api
> isn't there.
>
> What we'd be looking at is:
>
> * a glare service that runs two endpoints - an /image endpoint and an
> /artifact endpoint - and that registers the /image endpoint with the catalog
> as the 'image' service_type and the /artifact endpoint with the catalog as
> the 'artifact' service_type followed by a deprecation period of the image
> endpoint from the bazillion things that use it and a migration to the
> artifact service.
>
> OR
>
> First - immediately bump the glare api version to 3.0. This is affect some
> glare users, but given the relative numbers of glance v. glare users, it may
> be the right choice.
>
> Run a single set of versioned endpoints - no /v1, /v2 has /image at the root
> and /v3 has /artifact at the root. Register that endpoint with the catalog
> as both artifact and image.
>
> That means service and version discovery will find the /v2 endpoint of the
> glare service if someone says "I want 'image' api 'v2'". It's already fair
> game for a cloud to run without v1 - so that's not a problem. (This, btw, is
> the reason glare has to bump its api to v3 - if it still had a v1 in its
> version discovery document, glance users would potentially find that but it
> would not be a v1 of the image API)
>
> In both cases, /v2/images needs to be the same as glance /v2/images. If both
> are running side-by-side, which is how we normally do major version bumps,
> then client tools and libraries can use the normal version discovery process
> to discover that the cloud has the new /v3 version of the api with
> service-type of 'image', and they can decide if they want to use it or not.
>
>
> Yes - this is going to provide a pile of suck for the glare team, because
> they're going to have to maintain an API mapping layer, and they're going to
> have to maintain it for a full glance v2 api deprecation period. Becaue
> glance v2 is in DefCore, that is longer than a normal deprecation period -
> but that's life.

Just clarify something here. These plans are still not aligned with
current plans in Glance community. So we have no intention to
deprecate the Images API v2 nor stop supporting it. If Glare wants to
maintain functional par with Images API v2 and we get every single
deployment/project consuming Glance to move to Glare, then we can talk
again but the foreseeable future Glance is moving forward with the
Images API v2 maintained and supported (and developed forward within
our resources).

For a while this spring it looked like worst case scenario we need to
put glance to maintenance mode, freezing new development and drop the
project to just take care of bug fixes etc. The situation looks much
brighter at the moment when our call to arms was responded well and
we've seen people stepping in and making sure we stay afloat. For the
majority of the Glance team it has been, as long as I've been part of
it, very clear that Glance is one of the core projects and the utmost
priority is to provide stable and functional image service. Anything
outside of that is almost second class citizen based on the resources
and people we have and at least personally I will keep driving that
being the priority.

So please stop assuming Glance is shutting down just because Glare is
still around.

Back to the actual topic Glare becoming part of big tent. I thought
this was the case already and I'm totally supportive including Glare
there. The project has matured a lot from the times it was incubated
within Glace and I do see the value for artifact repository. I'm also
super happy to hear that the project has gain some full time
developers to drive it forward after Mirantis stopped running it. Bit
cynically if those people want to spend their time trying to be Glance
instead of Glance, that's their call. Personally I won't be part of
those efforts and I think the Artifact Repository could do with some
love focusing on their core delivery rather than chasing up Glance.
That said as it's not my core focus, it''s also not my business to
tell them as community what they should do.

Good luck!

- Erno "jokke" Kuvaja

>
> The other choice is to tell our users "we don't care about you AT ALL and
> just yanked one of the most fundamental pieces of the core IaaS APIs out
> from under you YOLO"

I truly hope this is not what we're planning to do as community. Even
the few necessary changes moving from Images API v1 to Images API v2
showed how much pain it is. And that was well communicated and
documented for years ahead we even defaulted to v2.

>
> There is work here - but it's just work - none of it is impossible. What's
> important is to keep our eyes on the fact that there are a TON of people
> using the glance API and we CANNOT screw them. We have service discovery, we
> have version discovery - they are used by the things that consume openstack
> apis - we can use them for this.
>
>
>>>> 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.
>
>
> Yay - I think it's a great thing to do in the glare api.
>
> For a glance v2 api layer, we just need to have an API controller that
> receives /v2/images/{image_id}/actions/deactivate does the status. That
> should not be terribly hard to code - it can likely just translate the call
> internally and dispatch the patch controller with the right values set.
>
>> Despite this not being my preferred option, I definitely prefer it over
>> the
>> "compatible" client library.
>>
>> Flavio
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>>
>> __________________________________________________________________________
>> 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