Open Stack

On 07/13/2017 08:42 AM, Erno Kuvaja wrote:
> 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).

AH! Sorry for the confusion generated on my part- let me clarify.

What I'm talking about is the technical work that would be an absolute 
requirement for us to CONSIDER the proposal to merge the efforts or 
replace one with the other. By no means has such a decision been made.

What I'm talking about is that glance is the image service, and the 
image services is one of the most fundamental parts of the stack. 
Changing the codebase that provides it is not a decision that can be 
taken lightly. There are MANY considerations. However - before any of 
the other considerations can be looked at, the technical path must at 
least be POSSIBLE.

(Like, I'm not going ot review your patch if it's still failing pep8 
tests - I'm going to wait until it at least is working code, then we can 
talk about the patch)

> 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.

That's awesome news!

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

I'm not at all - and again I apologize for coming across as if I was 
implying otherwise.

> 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.

Yes. Me too. I'm digging in and responding to the glance/glare piece 
because it was part of what was suggested as part of the message about 
glare becoming official. It is not required in my mind for glare to 
replace glance to become official. However, since that was suggested as 
part of the rationale, it feels like we should take that suggestion 
seriously and talk about what that actually means. If the intent is to 
become official so that glare can replace glance and a long-term 
co-existence would be a problem, I think we should know that up front 
and judge accordingly.

It's also possible that this suggestion ISN'T fundamental to the 
suggestion, in which case we can consider it to be orthogonal.

> 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.

Yah. As a human who deals with the consuming differences - lemme tell 
you - holy hell it's painful. I also keep having to remind people that 
it doesn't matter which version of the API the latest release of 
OpenStack 'supports' - as a client consumer ALL of them must be 
supported, because deployments update when deployments update. That 
means adding a new major version is always ADDING not replacing.

Deprecating/removing is mostly useful as it relates to intra-openstack 
services. When we remove glance v1 it means that Nova doesn't have to 
deal with v1 + v2 - which is good, so doing that is valuable.

>>
>> 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
> 
> __________________________________________________________________________
> 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
>