Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Thierry Carrez]

Erno Kuvaja wrote:
> [...] 
> So this raises a question: If it is integral part of Glare becoming
> part of big tent, does it mean that we as OpenStack Community
> fundamentally agree on that goal? because in that case I would be way
> less supportive. [...]
Approving Glare as an official OpenStack project wouldn't bless it as
Glance NG, it would just be recognizing that Glare is being developed by
members of the OpenStack community, following our open development
principles, and that the scope of the project is helping with the
OpenStack mission.

I think we are mostly comfortable with the first part (the principles
match). We are slightly less comfortable with the second part (the scope
match). If we determined that Glare is actively hurting OpenStack
mission (by adding confusion or gratuitously duplicating effort or
introducing interoperability issues) we would likely have to reject it.

Mike's answers are reassuring, so I'm looking forward to continuing this
discussion on this list and at the Denver PTG, and finally make the call
at the start of the Queens cycle.

-- 
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Erno Kuvaja]

On Thu, Jul 13, 2017 at 4:43 PM, Monty Taylor  wrote:
> On 07/13/2017 08:42 AM, Erno Kuvaja wrote:
>>
>> On Wed, Jul 12, 2017 at 1:21 AM, Monty Taylor 
>> 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 
> 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 

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Monty Taylor]

On 07/12/2017 02:02 AM, Flavio Percoco wrote:

On 11/07/17 19:21 -0500, Monty Taylor 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
 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.


Right! This is the extended version of what I tried to say. :D


\o/

I'm not a huge fan of the Glare team having a Glance v2 API but I think 
it's our
best option forward. FWIW, this WAS tried before but a bit different. 
Remeber

the Glance v3 discussion?

That Glance v3 was Glare living in the Glance's codebase. The main 
difference
now is that it would be Glare providing Glance's v2 and Glare's v3 
rather than

Glance doing yet another major version change.

I still think we should figure out how to migrate a Glance deployment to 
Glare
(database, stores, etc) before the work on this API even starts. I would 
like to

see a good plan forward for this.

Ultimately, the thing I definitely don't want to see happening is any logic
being hard-coded inside client 

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Monty Taylor]

On 07/13/2017 08:42 AM, Erno Kuvaja wrote:

On Wed, Jul 12, 2017 at 1:21 AM, Monty Taylor  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 
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 

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Erno Kuvaja]

On Wed, Jul 12, 2017 at 1:21 AM, Monty Taylor  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 
>>> 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 

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Flavio Percoco]

On 11/07/17 19:21 -0500, Monty Taylor 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
 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.


Right! This is the extended version of what I tried to say. :D

I'm not a huge fan of the Glare team having a Glance v2 API but I think it's our
best option forward. FWIW, this WAS tried before but a bit different. Remeber
the Glance v3 discussion?

That Glance v3 was Glare living in the Glance's codebase. The main difference
now is that it would be Glare providing Glance's v2 and Glare's v3 rather than
Glance doing yet another major version change.

I still think we should figure out how to migrate a Glance deployment to Glare
(database, stores, etc) before the work on this API even starts. I would like to
see a good plan forward for this.

Ultimately, the thing I definitely don't want to see happening is any logic
being hard-coded inside client libraries.

Flavio

--
@flaper87
Flavio Percoco


signature.asc

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Monty Taylor]

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


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"


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 

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Melvin Hillsman]

++ As I was not sure how to word it without sounding too opinionated
without appropriate technical jargon. When most folks hear "mostly the
same" regarding a critical component, and sometimes not so critical ones,
that raises all kinds of red flags. I could not think from purely code
aspect of what that means but from operations it means potentially it could
affect the bottom line and well, that affects everyone generally :)

On Tue, Jul 11, 2017 at 6:45 AM, Davanum Srinivas  wrote:

> On Tue, Jul 11, 2017 at 7:33 AM, Chris Dent 
> wrote:
> > On Tue, 11 Jul 2017, Mikhail Fedosin wrote:
> >
> >> 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.
> >
> >
> > Indeed I did. The point of that was to avoid "actions" style URLs on
> > resources that already have that information in their
> > representations so that the interface is more RESTful and doesn't
> > have a profusion of verby URLs. The other option is to PUT a full
> > representation with the status changed.
> >
> > But that's not the point here. The issue is that in order for Glare
> > to provide a seamless compatibility layer with Glance it needs to be
> > able to present a facade which is _identical_ to Glance. Not mostly
> > the same but with improvement, but identical with all the same
> > warts.
>
> Big +1 to "Not mostly the same but with improvement, but identical
> with all the same warts.". Anything else is a deal breaker IMHO.
>
> Thanks,
> Dims
>
> >
> > This provides a critical part in a smooth migration plan. As people
> > become aware of glare being there, they can start taking advantage
> > of the new features in their new code or code that they are ready to
> > update, without having to update old stuff.
> >
> > If Glare has fairly good separation between the code that handles
> > URLs and processes bodies (in and out) and the code that does stuff
> > with those bodies[1], it ought to be somewhat straightforward to
> > create such a facade.
> >
> > [1] Not gonna use model, view, controller here; those terms have
> > never been accurate for web-based APIs.
> >
> >
> >
> > --
> > Chris Dent  ┬──┬◡ﾉ(° -°ﾉ)   https://anticdent.org/
> > freenode: cdent tw: @anticdent
> >
> > 
> __
> > 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
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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
>



-- 
-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646

Learner | Ideation | Belief | Responsibility | Command
__
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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Flavio Percoco]

On 11/07/17 14:20 +0300, Mikhail Fedosin wrote:

On Tue, Jul 11, 2017 at 1:43 AM, Monty Taylor  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".


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.


Despite this not being my preferred option, I definitely prefer it over the
"compatible" client library.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Davanum Srinivas]

On Tue, Jul 11, 2017 at 7:33 AM, Chris Dent  wrote:
> On Tue, 11 Jul 2017, Mikhail Fedosin wrote:
>
>> 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.
>
>
> Indeed I did. The point of that was to avoid "actions" style URLs on
> resources that already have that information in their
> representations so that the interface is more RESTful and doesn't
> have a profusion of verby URLs. The other option is to PUT a full
> representation with the status changed.
>
> But that's not the point here. The issue is that in order for Glare
> to provide a seamless compatibility layer with Glance it needs to be
> able to present a facade which is _identical_ to Glance. Not mostly
> the same but with improvement, but identical with all the same
> warts.

Big +1 to "Not mostly the same but with improvement, but identical
with all the same warts.". Anything else is a deal breaker IMHO.

Thanks,
Dims

>
> This provides a critical part in a smooth migration plan. As people
> become aware of glare being there, they can start taking advantage
> of the new features in their new code or code that they are ready to
> update, without having to update old stuff.
>
> If Glare has fairly good separation between the code that handles
> URLs and processes bodies (in and out) and the code that does stuff
> with those bodies[1], it ought to be somewhat straightforward to
> create such a facade.
>
> [1] Not gonna use model, view, controller here; those terms have
> never been accurate for web-based APIs.
>
>
>
> --
> Chris Dent  ┬──┬◡ﾉ(° -°ﾉ)   https://anticdent.org/
> freenode: cdent tw: @anticdent
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Chris Dent]

On Tue, 11 Jul 2017, Mikhail Fedosin wrote:


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.


Indeed I did. The point of that was to avoid "actions" style URLs on
resources that already have that information in their
representations so that the interface is more RESTful and doesn't
have a profusion of verby URLs. The other option is to PUT a full
representation with the status changed.

But that's not the point here. The issue is that in order for Glare
to provide a seamless compatibility layer with Glance it needs to be
able to present a facade which is _identical_ to Glance. Not mostly
the same but with improvement, but identical with all the same
warts.

This provides a critical part in a smooth migration plan. As people
become aware of glare being there, they can start taking advantage
of the new features in their new code or code that they are ready to
update, without having to update old stuff.

If Glare has fairly good separation between the code that handles
URLs and processes bodies (in and out) and the code that does stuff
with those bodies[1], it ought to be somewhat straightforward to
create such a facade.

[1] Not gonna use model, view, controller here; those terms have
never been accurate for web-based APIs.


--
Chris Dent  ┬──┬◡ﾉ(° -°ﾉ)   https://anticdent.org/
freenode: cdent tw: @anticdent__
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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Mikhail Fedosin]

On Tue, Jul 11, 2017 at 1:43 AM, Monty Taylor  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 > > wrote:
>>
>> Ed Leafe wrote:
>>
>> On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin > 
>> >> 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
>> > subscribe>
>> 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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for 

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Mikhail Fedosin]

On Tue, Jul 11, 2017 at 12:31 AM, Monty Taylor  wrote:

> On 07/10/2017 01:21 PM, Ed Leafe wrote:
>
>> On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin  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?
>>
>
> I also have this question. The glance API is one of the most fundamental
> and basic APIs. You pretty much can't do anything useful on a cloud without
> touching it.
>
> That said - it's not like glare couldn't also do those things - but I'd
> need to understand some real specifics about what a cloud switching from
> glance to glare looks like to the end user.
>
> Also, we have a new upload API designed for glance that took a LARGE
> amount of wrangling to get consensus on. I'd also want to know what this
> situation looks like in glare, if image upload in glare supports all of the
> use-cases that we figured out image upload in glance needed to support. AND
> - there are folks who want import-from which was removed between glance v1
> and v2. Does glare support something in this area?


I think you ask about "copy-from". Then yes, it's planned to implement this
week.


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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Mikhail Fedosin]

On Tue, Jul 11, 2017 at 12:54 AM, Monty Taylor  wrote:

> On 07/10/2017 04:31 PM, Monty Taylor wrote:
>
>> On 07/10/2017 01:21 PM, Ed Leafe wrote:
>>
>>> On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin >> > 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?
>>>
>>
>> I also have this question. The glance API is one of the most fundamental
>> and basic APIs. You pretty much can't do anything useful on a cloud without
>> touching it.
>>
>
> Actually - as an easy first-step - set up a gate job with a devstack that
> has glare and no glance and run shade's functional tests against it. We're
> pretty darned lenient - if you can pass our functional tests then talking
> about stricter things like tempest is worthwhile. If you can't - hopefully
> there will be some clear areas to work on.

Yes again - creating a set of tempest gates in jenkins is our highest
priority. If everything is fine, I'll propose related patches today.


>
>
> That said - it's not like glare couldn't also do those things - but I'd
>> need to understand some real specifics about what a cloud switching from
>> glance to glare looks like to the end user.
>>
>> Also, we have a new upload API designed for glance that took a LARGE
>> amount of wrangling to get consensus on. I'd also want to know what this
>> situation looks like in glare, if image upload in glare supports all of the
>> use-cases that we figured out image upload in glance needed to support. AND
>> - there are folks who want import-from which was removed between glance v1
>> and v2. Does glare support something in this area?
>>
>
>
>
> __
> 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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Chris Dent]

On Mon, 10 Jul 2017, Monty Taylor wrote:

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?


In general I think we should always keep this strategy in mind when
we are considering leapfrogging technologies for some reason. And we
should consider leapfrogging more often.

(Note that I'm using "consider" and not "choose" very much on
purpose.)

--
Chris Dent  ┬──┬◡ﾉ(° -°ﾉ)   https://anticdent.org/
freenode: cdent tw: @anticdent__
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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Monty Taylor]

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


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?



Best,
Mike Fedosin

On Mon, Jul 10, 2017 at 9:55 PM, Joshua Harlow > wrote:


Ed Leafe wrote:

On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin 
>> 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://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




__
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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Monty Taylor]

On 07/10/2017 04:31 PM, Monty Taylor wrote:

On 07/10/2017 01:21 PM, Ed Leafe wrote:
On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin > 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?


I also have this question. The glance API is one of the most fundamental 
and basic APIs. You pretty much can't do anything useful on a cloud 
without touching it.


Actually - as an easy first-step - set up a gate job with a devstack 
that has glare and no glance and run shade's functional tests against 
it. We're pretty darned lenient - if you can pass our functional tests 
then talking about stricter things like tempest is worthwhile. If you 
can't - hopefully there will be some clear areas to work on.


That said - it's not like glare couldn't also do those things - but I'd 
need to understand some real specifics about what a cloud switching from 
glance to glare looks like to the end user.


Also, we have a new upload API designed for glance that took a LARGE 
amount of wrangling to get consensus on. I'd also want to know what this 
situation looks like in glare, if image upload in glare supports all of 
the use-cases that we figured out image upload in glance needed to 
support. AND - there are folks who want import-from which was removed 
between glance v1 and v2. Does glare support something in this area?




__
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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Mikhail Fedosin]

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

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.

Best,
Mike Fedosin

On Mon, Jul 10, 2017 at 9:55 PM, Joshua Harlow 
wrote:

> Ed Leafe wrote:
>
>> On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin > > 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: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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Monty Taylor]

On 07/10/2017 01:21 PM, Ed Leafe wrote:
On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin > 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?


I also have this question. The glance API is one of the most fundamental 
and basic APIs. You pretty much can't do anything useful on a cloud 
without touching it.


That said - it's not like glare couldn't also do those things - but I'd 
need to understand some real specifics about what a cloud switching from 
glance to glare looks like to the end user.


Also, we have a new upload API designed for glance that took a LARGE 
amount of wrangling to get consensus on. I'd also want to know what this 
situation looks like in glare, if image upload in glare supports all of 
the use-cases that we figured out image upload in glance needed to 
support. AND - there are folks who want import-from which was removed 
between glance v1 and v2. Does glare support something in this area?


__
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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Joshua Harlow]

Ed Leafe wrote:

On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin > 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://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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Ed Leafe]

On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin  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?

-- Ed Leafe





__
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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Kendall Nelson]

Hello Mike :)

WRT the PTG, if you get approved as an official project before the end of
the month, we would love to have you!

The PTG isn't formatted the same as the Forum though. The PTG is more
project focused technical discussions amongst project contributors- think
midcycle rather than design summit or forum presentations. That being said,
we have the space for Glare contributors to meet for Wed- Thurs or
Wed-Friday if you think you can get enough people together to make it worth
while :)

Good luck with the last steps to becoming an official project!

-Kendall Nelson (diablo_rojo)

On Mon, Jul 10, 2017 at 3:10 AM Mikhail Fedosin  wrote:

> Hello!
>
> Recently I applied for inclusion of Glare in the list of official
> OpenStack projects: https://review.openstack.org/#/c/479285/ In this
> regard, I would like to ask the community what other things can be improved
> in the project to meet all the necessary requirements.
>
> Also in this thread I would like to discuss the role of the project in
> OpenStack. Lately opinions have been increasingly expressed that Glance no
> longer meets the current needs of OpenStack and should be replaced in the
> foreseeable future.  And as you know, initially Glare was designed as a new
> improved version of Glance, which works with all types of data, not just
> with virtual machine images. Given all the advantages and features of
> Glare, I believe that it can become the successful drop-in replacement.
> Glare already has parity in terms of features with Glance and can be used
> by Nova as a means for storing images. In addition to this we are
> developing a number of other interesting things that will help many
> projects to store their data in a convenient and reliable way. Therefore, I
> propose to transfer Glance to the status of stable and supported project
> starting from the next cycle, and to declare Glare as a new version in the
> medium term.
>
> In the end I would like to ask about PTG - I would be happy to present
> Glare at one or two sessions in Denver, if I get this opportunity.
>
> Thank you in advance for your comments!
>
> Best,
> Mike Fedosin
> __
> 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

[openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Mikhail Fedosin]

Hello!

Recently I applied for inclusion of Glare in the list of official OpenStack
projects: https://review.openstack.org/#/c/479285/ In this regard, I would
like to ask the community what other things can be improved in the project
to meet all the necessary requirements.

Also in this thread I would like to discuss the role of the project in
OpenStack. Lately opinions have been increasingly expressed that Glance no
longer meets the current needs of OpenStack and should be replaced in the
foreseeable future.  And as you know, initially Glare was designed as a new
improved version of Glance, which works with all types of data, not just
with virtual machine images. Given all the advantages and features of
Glare, I believe that it can become the successful drop-in replacement.
Glare already has parity in terms of features with Glance and can be used
by Nova as a means for storing images. In addition to this we are
developing a number of other interesting things that will help many
projects to store their data in a convenient and reliable way. Therefore, I
propose to transfer Glance to the status of stable and supported project
starting from the next cycle, and to declare Glare as a new version in the
medium term.

In the end I would like to ask about PTG - I would be happy to present
Glare at one or two sessions in Denver, if I get this opportunity.

Thank you in advance for your comments!

Best,
Mike Fedosin
__
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