[all][tc][glance] Glance needs help, it's getting critical

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[all][tc][glance] Glance needs help, it's getting critical

Flavio Percoco-2
(sorry if duplicate, having troubles with email)

Hi Team,

I've been working a bit with the Glance team and trying to help where I can and
I can't but be worried about the critical status of the Glance team.
Unfortunately, the number of participants in the Glance team has been reduced a
lot resulting in the project not being able to keep up with the goals, the
reviews required, etc.[0]

I've always said that Glance is one of those critical projects that not many
people notice until it breaks. It's in every OpenStack cloud sitting in a corner
and allowing for VMs to be booted. So, before things get even worse, I'd
like us to brainstorm a bit on what solutions/options we have now.

I know Glance is not the only project "suffering" from lack of contributors but
I don't want us to get to the point where there won't be contributors left.

How do people feel about adding Glance to the list of "help wanted" areas of
interest?

Would it be possible to get help w/ reviews from folks from teams like
nova/cinder/keystone? Any help is welcomed, of course, but I'm trying to think
about teams that may be familiar with the Glance code/api already.

Cheers,
Flavio


--
@flaper87
Flavio Percoco


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Thierry Carrez
Flavio Percoco wrote:
> I've been working a bit with the Glance team and trying to help where I
> can and I can't but be worried about the critical status of the Glance team.
> Unfortunately, the number of participants in the Glance team has been
> reduced a lot resulting in the project not being able to keep up with the goals, the
> reviews required, etc.[0]

Are there more specific areas where the Glance team struggles ?

> I've always said that Glance is one of those critical projects that not many
> people notice until it breaks. It's in every OpenStack cloud sitting in
> a corner and allowing for VMs to be booted. So, before things get even worse, I'd
> like us to brainstorm a bit on what solutions/options we have now.
>
> I know Glance is not the only project "suffering" from lack of contributors but
> I don't want us to get to the point where there won't be contributors left.
>
> How do people feel about adding Glance to the list of "help wanted" areas of
> interest?

I think that makes sense. Glance (like Keystone, Cinder or Neutron) is a
project that other teams depend on.

> Would it be possible to get help w/ reviews from folks from teams like
> nova/cinder/keystone? Any help is welcomed, of course, but I'm trying to
> think about teams that may be familiar with the Glance code/api already.

I was hoping the VM & BM working group would be the right place to
discuss those priorities and make sure the minimal work is covered.
What's the status of that initiative ?

--
Thierry Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Sean Dague-2
In reply to this post by Flavio Percoco-2
On 06/09/2017 01:07 PM, Flavio Percoco wrote:

> (sorry if duplicate, having troubles with email)
>
> Hi Team,
>
> I've been working a bit with the Glance team and trying to help where I
> can and
> I can't but be worried about the critical status of the Glance team.
> Unfortunately, the number of participants in the Glance team has been
> reduced a
> lot resulting in the project not being able to keep up with the goals, the
> reviews required, etc.[0]
>
> I've always said that Glance is one of those critical projects that not many
> people notice until it breaks. It's in every OpenStack cloud sitting in
> a corner
> and allowing for VMs to be booted. So, before things get even worse, I'd
> like us to brainstorm a bit on what solutions/options we have now.
>
> I know Glance is not the only project "suffering" from lack of
> contributors but
> I don't want us to get to the point where there won't be contributors left.
>
> How do people feel about adding Glance to the list of "help wanted" areas of
> interest?
>
> Would it be possible to get help w/ reviews from folks from teams like
> nova/cinder/keystone? Any help is welcomed, of course, but I'm trying to
> think
> about teams that may be familiar with the Glance code/api already.

I'm happy to help here, I just went through and poked at a few things.
It is going to be tough to make meaningful contributions there without
approve authority, especially given the normal trust building exercise
for core teams takes 3+ months. It might be useful to figure out if
there are a set of folks already in the community that the existing core
team would be happy to provisionally promote to help worth the current
patch backlog and get things flowing.

        -Sean

--
Sean Dague
http://dague.net

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Flavio Percoco-2
On 12/06/17 09:13 -0400, Sean Dague wrote:

>On 06/09/2017 01:07 PM, Flavio Percoco wrote:
>> Would it be possible to get help w/ reviews from folks from teams like
>> nova/cinder/keystone? Any help is welcomed, of course, but I'm trying to
>> think
>> about teams that may be familiar with the Glance code/api already.
>
>I'm happy to help here, I just went through and poked at a few things.
>It is going to be tough to make meaningful contributions there without
>approve authority, especially given the normal trust building exercise
>for core teams takes 3+ months. It might be useful to figure out if
>there are a set of folks already in the community that the existing core
>team would be happy to provisionally promote to help worth the current
>patch backlog and get things flowing.
I think this is fine. I'd be happy to add you and a couple of other folks that
have some time to spend on thi to the core team. This until the core team is
healthier.

Brian has been sending emails with focus reviews/topics every week and I think
that would be useful especially for folks joining the team provisionally. That
sounds like a better way to invest time.

Not sure whether Brian will have time to keep doing this, perhaps Erno can take
this task on? Erno?
Flavio

--
@flaper87
Flavio Percoco

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc (879 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Mikhail Fedosin-2
In reply to this post by Flavio Percoco-2
Hello!

Flavio raised a very difficult and important question, and I think that we, as community members, should decide what to do with Glance next.

I will try to state my subjective opinion. I was involved in the Glance project for almost three years and studied it fairly plank. I believe that the main problem is that the project was designed extremely poorly. Glance does not have many tasks to solve, but nevertheless, there are a lot of Java design patterns used (factory of factories, visitors, proxy and other things that are unnecessary in this case). All this leads to absolutely sad consequences, when in order to add an image tag over 180 objects of different classes are created, the code execution passes through more than 25 locations with a number of callbacks 3 times. So I can say that the code base is artificially over-complicated and incredibly inflated.

The next problem is that over the years the code has grown by a number of workarounds, which make it difficult to implement new changes - any change leads to something breaking down somewhere else. In the long run, we get a lot of pain associated with race conditions, hard-to-recover heisenbugs and other horrors of programmer's life. It is difficult to talk about attracting new developers, because the developing of the code in such conditions is mentally exhausting.

We can continue to deny the obvious, saying that Glance simply needs people and everything will be wonderful. But unfortunately this is not so - we should admit that it is simply not profitable to engage in further development. I suggest thinking about moving the current code base into a support mode and starting to develop an alternative (which I have been doing for the past year and a half).

If you are allergic to the word "artifacts", do not read the following paragraph:

We are actively developing the Glare project, which offers a universal catalog of various binary data along with its metadata - at the moment the catalog supports the storage of images of virtual machines and has feature parity with Glance. The service is used in production by Nokia, and it was thoroughly tested at various settings. Next week we plan to release the first stable version and begin the integration with various projects of OpenStack: Mistral and Vitrage in the first place.

As a solution, I can propose to implement an additional API to Glare, which would correspond to OpenStack Image API v2 and test that OpenStack is able to work on its basis. After that, leave Glance at rest and start developing Glare as a universal catalog of binary data for OpenStack.

Best,
Mike

On Fri, Jun 9, 2017 at 8:07 PM, Flavio Percoco <[hidden email]> wrote:
(sorry if duplicate, having troubles with email)

Hi Team,

I've been working a bit with the Glance team and trying to help where I can and
I can't but be worried about the critical status of the Glance team.
Unfortunately, the number of participants in the Glance team has been reduced a
lot resulting in the project not being able to keep up with the goals, the
reviews required, etc.[0]

I've always said that Glance is one of those critical projects that not many
people notice until it breaks. It's in every OpenStack cloud sitting in a corner
and allowing for VMs to be booted. So, before things get even worse, I'd
like us to brainstorm a bit on what solutions/options we have now.

I know Glance is not the only project "suffering" from lack of contributors but
I don't want us to get to the point where there won't be contributors left.

How do people feel about adding Glance to the list of "help wanted" areas of
interest?

Would it be possible to get help w/ reviews from folks from teams like
nova/cinder/keystone? Any help is welcomed, of course, but I'm trying to think
about teams that may be familiar with the Glance code/api already.

Cheers,
Flavio


--
@flaper87
Flavio Percoco


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Erno Kuvaja
Just quick comment here on my day off. I will get proper reply to the
chain itself tomorrow when I'm back.

While I cannot argue with all Mike's points below, I personally cannot
stand behind his proposals here and just want to indicate that this is
view of one member, not the Glance community by wide.

- Erno "Jokke" Kuvaja

On Mon, Jun 12, 2017 at 2:56 PM, Mikhail Fedosin <[hidden email]> wrote:

> Hello!
>
> Flavio raised a very difficult and important question, and I think that we,
> as community members, should decide what to do with Glance next.
>
> I will try to state my subjective opinion. I was involved in the Glance
> project for almost three years and studied it fairly plank. I believe that
> the main problem is that the project was designed extremely poorly. Glance
> does not have many tasks to solve, but nevertheless, there are a lot of Java
> design patterns used (factory of factories, visitors, proxy and other things
> that are unnecessary in this case). All this leads to absolutely sad
> consequences, when in order to add an image tag over 180 objects of
> different classes are created, the code execution passes through more than
> 25 locations with a number of callbacks 3 times. So I can say that the code
> base is artificially over-complicated and incredibly inflated.
>
> The next problem is that over the years the code has grown by a number of
> workarounds, which make it difficult to implement new changes - any change
> leads to something breaking down somewhere else. In the long run, we get a
> lot of pain associated with race conditions, hard-to-recover heisenbugs and
> other horrors of programmer's life. It is difficult to talk about attracting
> new developers, because the developing of the code in such conditions is
> mentally exhausting.
>
> We can continue to deny the obvious, saying that Glance simply needs people
> and everything will be wonderful. But unfortunately this is not so - we
> should admit that it is simply not profitable to engage in further
> development. I suggest thinking about moving the current code base into a
> support mode and starting to develop an alternative (which I have been doing
> for the past year and a half).
>
> If you are allergic to the word "artifacts", do not read the following
> paragraph:
>
> We are actively developing the Glare project, which offers a universal
> catalog of various binary data along with its metadata - at the moment the
> catalog supports the storage of images of virtual machines and has feature
> parity with Glance. The service is used in production by Nokia, and it was
> thoroughly tested at various settings. Next week we plan to release the
> first stable version and begin the integration with various projects of
> OpenStack: Mistral and Vitrage in the first place.
>
> As a solution, I can propose to implement an additional API to Glare, which
> would correspond to OpenStack Image API v2 and test that OpenStack is able
> to work on its basis. After that, leave Glance at rest and start developing
> Glare as a universal catalog of binary data for OpenStack.
>
> Best,
> Mike
>
> On Fri, Jun 9, 2017 at 8:07 PM, Flavio Percoco <[hidden email]> wrote:
>>
>> (sorry if duplicate, having troubles with email)
>>
>> Hi Team,
>>
>> I've been working a bit with the Glance team and trying to help where I
>> can and
>> I can't but be worried about the critical status of the Glance team.
>> Unfortunately, the number of participants in the Glance team has been
>> reduced a
>> lot resulting in the project not being able to keep up with the goals, the
>> reviews required, etc.[0]
>>
>> I've always said that Glance is one of those critical projects that not
>> many
>> people notice until it breaks. It's in every OpenStack cloud sitting in a
>> corner
>> and allowing for VMs to be booted. So, before things get even worse, I'd
>> like us to brainstorm a bit on what solutions/options we have now.
>>
>> I know Glance is not the only project "suffering" from lack of
>> contributors but
>> I don't want us to get to the point where there won't be contributors
>> left.
>>
>> How do people feel about adding Glance to the list of "help wanted" areas
>> of
>> interest?
>>
>> Would it be possible to get help w/ reviews from folks from teams like
>> nova/cinder/keystone? Any help is welcomed, of course, but I'm trying to
>> think
>> about teams that may be familiar with the Glance code/api already.
>>
>> Cheers,
>> Flavio
>>
>> [0] http://stackalytics.com/?module=glance-group&metric=marks
>> [1] https://review.openstack.org/#/c/466684/
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: [hidden email]?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Flavio Percoco-2
In reply to this post by Mikhail Fedosin-2
On 12/06/17 16:56 +0300, Mikhail Fedosin wrote:
>Hello!
>
>Flavio raised a very difficult and important question, and I think that we,
>as community members, should decide what to do with Glance next.

Hi Mike,


>I will try to state my subjective opinion. I was involved in the Glance
>project for almost three years and studied it fairly plank. I believe that
>the main problem is that the project was designed extremely poorly. Glance
>does not have many tasks to solve, but nevertheless, there are a lot of
>Java design patterns used (factory of factories, visitors, proxy and other
>things that are unnecessary in this case). All this leads to absolutely sad
>consequences, when in order to add an image tag over 180 objects of
>different classes are created, the code execution passes through more than
>25 locations with a number of callbacks 3 times. So I can say that the code
>base is artificially over-complicated and incredibly inflated.
>
>The next problem is that over the years the code has grown by a number of
>workarounds, which make it difficult to implement new changes - any change
>leads to something breaking down somewhere else. In the long run, we get a
>lot of pain associated with race conditions, hard-to-recover heisenbugs and
>other horrors of programmer's life. It is difficult to talk about
>attracting new developers, because the developing of the code in such
>conditions is mentally exhausting.
I don't disagree on this. The code base *is* over-engineered in many areas.
However, I don't think this is a good reason to just throw the entire project
away. With enough time and contributions, the code could be refactored.

>We can continue to deny the obvious, saying that Glance simply needs people
>and everything will be wonderful. But unfortunately this is not so - we
>should admit that it is simply not profitable to engage in further
>development. I suggest thinking about moving the current code base into a
>support mode and starting to develop an alternative (which I have been
>doing for the past year and a half).
>
>If you are allergic to the word "artifacts", do not read the following
>paragraph:
>
>We are actively developing the Glare project, which offers a universal
>catalog of various binary data along with its metadata - at the moment the
>catalog supports the storage of images of virtual machines and has feature
>parity with Glance. The service is used in production by Nokia, and it was
>thoroughly tested at various settings. Next week we plan to release the
>first stable version and begin the integration with various projects of
>OpenStack: Mistral and Vitrage in the first place.
>
>As a solution, I can propose to implement an additional API to Glare, which
>would correspond to OpenStack Image API v2 and test that OpenStack is able
>to work on its basis. After that, leave Glance at rest and start developing
>Glare as a universal catalog of binary data for OpenStack.
Could you please elaborate more on why you think switching code bases is going
to solve the current problem? In your email you talked about Glance's
over-engineered code as being the thing driving people away and while I disagree
with that statement, I'm wondering whether you really think that's the
motivation or there's something else.

Let's not talk about proxy API's or ways we would migrate users. I'd like to
understand why *you* (or others) might think that a complete change of projects
is a good solution to this problem.

Ultimatedly, I believe Glance, in addition to not being the "sexiest" project in
OpenStack, is taking the hit of the recent lay-offs, which it kinda managed to
avoid last year.

Flavio

--
@flaper87
Flavio Percoco

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc (879 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Sean Dague-2
On 06/12/2017 03:20 PM, Flavio Percoco wrote:
<snip>

> Could you please elaborate more on why you think switching code bases is
> going
> to solve the current problem? In your email you talked about Glance's
> over-engineered code as being the thing driving people away and while I
> disagree
> with that statement, I'm wondering whether you really think that's the
> motivation or there's something else.
>
> Let's not talk about proxy API's or ways we would migrate users. I'd
> like to
> understand why *you* (or others) might think that a complete change of
> projects
> is a good solution to this problem.
>
> Ultimatedly, I believe Glance, in addition to not being the "sexiest"
> project in
> OpenStack, is taking the hit of the recent lay-offs, which it kinda
> managed to
> avoid last year.

As someone from the outside the glance team, I'd really like to avoid
the artifacts path. I feel like 2 years ago there was a promise that if
glance headed in that direction it would bring in new people, and
everything would be great. But, it didn't bring in folks solving the
class of issues that current glance users are having. 80+ GB disk images
could be classified as a special case of Artifacts, but it turns
optimizing for their specialness is really important to a well
functioning cloud.

Glance might not be the most exciting project, but what seems to be
asked for is help on the existing stuff. I'd rather focus there.

        -Sean

--
Sean Dague
http://dague.net

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Flavio Percoco-2
On 12/06/17 15:37 -0400, Sean Dague wrote:

>On 06/12/2017 03:20 PM, Flavio Percoco wrote:
><snip>
>> Could you please elaborate more on why you think switching code bases is
>> going
>> to solve the current problem? In your email you talked about Glance's
>> over-engineered code as being the thing driving people away and while I
>> disagree
>> with that statement, I'm wondering whether you really think that's the
>> motivation or there's something else.
>>
>> Let's not talk about proxy API's or ways we would migrate users. I'd
>> like to
>> understand why *you* (or others) might think that a complete change of
>> projects
>> is a good solution to this problem.
>>
>> Ultimatedly, I believe Glance, in addition to not being the "sexiest"
>> project in
>> OpenStack, is taking the hit of the recent lay-offs, which it kinda
>> managed to
>> avoid last year.
>
>As someone from the outside the glance team, I'd really like to avoid
>the artifacts path. I feel like 2 years ago there was a promise that if
>glance headed in that direction it would bring in new people, and
>everything would be great. But, it didn't bring in folks solving the
>class of issues that current glance users are having. 80+ GB disk images
>could be classified as a special case of Artifacts, but it turns
>optimizing for their specialness is really important to a well
>functioning cloud.
>
>Glance might not be the most exciting project, but what seems to be
>asked for is help on the existing stuff. I'd rather focus there.
Just want to make clear that I'm *not* proposing going down any artifacts path.
I actually disagree with this idea but I do want to understand why other folks
think this is going to solve the issue. There might be some insights there that
we can learn from and use to improve Glance (or not).

Glance can be very exciting if one focuses on the interesting bits and it's an
*AWESOME* place where new comers can start contributing, new developers can
learn and practice, etc. That said, I believe that code doesn't have to be
challenging to be exciting. There's also excitment in the simple but interesting
things.

Flavio

--
@flaper87
Flavio Percoco

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc (879 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Mikhail Fedosin-2
In reply to this post by Flavio Percoco-2
Well... My suggestion is to keep Glance maintained and begin experimental adoption of Glare. So this is not an immediate replacement, but the evolution of the Image service. 
My opinion is that Glance stagnates and it's really hard to implement new features there. In two years, only one major improvement was developed (Image Import Refactoring), and no one has tested it in production yet. And this is in the heyday of the community, as you said!

On the other hand OpenStack users have been requesting for new features for a long time: I'm talking about mutistore support, versioning of images, image slicing (like in docker), validation and conversion of uploading data and so on. And I can say that it is impossible to implement them without breaking Glance. But all this stuff is already done in Glare (multistore support is implemented partially, because modifications of glance_store are required). And if we switch OpenStack to Glare users will get these features out of the box.

Then, Glance works with images only, but Glare supports various types of data, like heat and tosca templates. Next week we will add Secrets artifact type to store private data, and Mistral workflows. I mean - we'll have unified catalog of all cloud data with the possibility to combine them in metastructures, when artifact of one type depends on the other.

I will repeat it once again, in order to be understood as much as possible. It takes too much time to develop new features and fix old bugs (years to be exact). If we continue in the same spirit, it certainly will not increase the joy of OpenStack users and they will look for other solutions that meet their desires.

Best,
Mike

On Mon, Jun 12, 2017 at 10:20 PM, Flavio Percoco <[hidden email]> wrote:
On 12/06/17 16:56 +0300, Mikhail Fedosin wrote:
Hello!

Flavio raised a very difficult and important question, and I think that we,
as community members, should decide what to do with Glance next.

Hi Mike,


I will try to state my subjective opinion. I was involved in the Glance
project for almost three years and studied it fairly plank. I believe that
the main problem is that the project was designed extremely poorly. Glance
does not have many tasks to solve, but nevertheless, there are a lot of
Java design patterns used (factory of factories, visitors, proxy and other
things that are unnecessary in this case). All this leads to absolutely sad
consequences, when in order to add an image tag over 180 objects of
different classes are created, the code execution passes through more than
25 locations with a number of callbacks 3 times. So I can say that the code
base is artificially over-complicated and incredibly inflated.

The next problem is that over the years the code has grown by a number of
workarounds, which make it difficult to implement new changes - any change
leads to something breaking down somewhere else. In the long run, we get a
lot of pain associated with race conditions, hard-to-recover heisenbugs and
other horrors of programmer's life. It is difficult to talk about
attracting new developers, because the developing of the code in such
conditions is mentally exhausting.

I don't disagree on this. The code base *is* over-engineered in many areas.
However, I don't think this is a good reason to just throw the entire project
away. With enough time and contributions, the code could be refactored.

We can continue to deny the obvious, saying that Glance simply needs people
and everything will be wonderful. But unfortunately this is not so - we
should admit that it is simply not profitable to engage in further
development. I suggest thinking about moving the current code base into a
support mode and starting to develop an alternative (which I have been
doing for the past year and a half).

If you are allergic to the word "artifacts", do not read the following
paragraph:

We are actively developing the Glare project, which offers a universal
catalog of various binary data along with its metadata - at the moment the
catalog supports the storage of images of virtual machines and has feature
parity with Glance. The service is used in production by Nokia, and it was
thoroughly tested at various settings. Next week we plan to release the
first stable version and begin the integration with various projects of
OpenStack: Mistral and Vitrage in the first place.

As a solution, I can propose to implement an additional API to Glare, which
would correspond to OpenStack Image API v2 and test that OpenStack is able
to work on its basis. After that, leave Glance at rest and start developing
Glare as a universal catalog of binary data for OpenStack.

Could you please elaborate more on why you think switching code bases is going
to solve the current problem? In your email you talked about Glance's
over-engineered code as being the thing driving people away and while I disagree
with that statement, I'm wondering whether you really think that's the
motivation or there's something else.

Let's not talk about proxy API's or ways we would migrate users. I'd like to
understand why *you* (or others) might think that a complete change of projects
is a good solution to this problem.

Ultimatedly, I believe Glance, in addition to not being the "sexiest" project in
OpenStack, is taking the hit of the recent lay-offs, which it kinda managed to
avoid last year.


Flavio

--
@flaper87
Flavio Percoco

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Flavio Percoco-2
On 12/06/17 23:20 +0300, Mikhail Fedosin wrote:
>My opinion is that Glance stagnates and it's really hard to implement new
>features there. In two years, only one major improvement was developed
>(Image Import Refactoring), and no one has tested it in production yet. And
>this is in the heyday of the community, as you said!

You're skipping 2 important things here:

The first one is that focusing on the image import refactor (IIR) was a
community choice. It's fixing a bigger problem that requires more focus. The
design of the feature took a couple of cycles too, not the implementation. The
second thing is that the slow pace may also be caused by the lack of
contributors.

>
>On the other hand OpenStack users have been requesting for new features for
>a long time: I'm talking about mutistore support, versioning of images,
>image slicing (like in docker), validation and conversion of uploading data
>and so on. And I can say that it is impossible to implement them without
>breaking Glance. But all this stuff is already done in Glare (multistore
>support is implemented partially, because modifications of glance_store are
>required). And if we switch OpenStack to Glare users will get these
>features out of the box.

Some of these features could be implemented in Glance. As you mentioned, the
code base is over-engineered but it could be simplified.

>Then, Glance works with images only, but Glare supports various types of
>data, like heat and tosca templates. Next week we will add Secrets artifact
>type to store private data, and Mistral workflows. I mean - we'll have
>unified catalog of all cloud data with the possibility to combine them in
>metastructures, when artifact of one type depends on the other.

Glance working only with images is a design choice and I don't think that's
something bad. I also don't think Glare's support for other artifacts is bad.
Just different choices.

>
>I will repeat it once again, in order to be understood as much as possible.
>It takes too much time to develop new features and fix old bugs (years to
>be exact). If we continue in the same spirit, it certainly will not
>increase the joy of OpenStack users and they will look for other solutions
>that meet their desires.

Mike, I understand that you think that the broader set of features that Glare
provides would be better for users, which is something I disagree with a bit.
More features don't make a service better. What I'm failing to see, though, is
why you believe that replacing Glance with Glare will solve the current problem.

I don't think the current problem is caused by Glance's lack of "exciting"
features and I certainly don't think replacing it with Glare would be of any
help now. It may be something we want to think about in the future (and this is
not the first time I say this) but what you're proposing will be an expensive
distraction from the real problem.

Flavio

--
@flaper87
Flavio Percoco

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc (879 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Mike Perez
On 16:01 Jun 12, Flavio Percoco wrote:

> On 12/06/17 23:20 +0300, Mikhail Fedosin wrote:
> > My opinion is that Glance stagnates and it's really hard to implement new
> > features there. In two years, only one major improvement was developed
> > (Image Import Refactoring), and no one has tested it in production yet. And
> > this is in the heyday of the community, as you said!
>
> You're skipping 2 important things here:
>
> The first one is that focusing on the image import refactor (IIR) was a
> community choice. It's fixing a bigger problem that requires more focus. The
> design of the feature took a couple of cycles too, not the implementation. The
> second thing is that the slow pace may also be caused by the lack of
> contributors.
+1 image import refactor work. That's great that the image import refactor work
is done!

Mikhail,

I'm pretty thorough on reading this list for the dev digest, so even I missed
that news. Which release was that done in? Are people not using it in
production right away because of having to upgrade to a new release?

--
Mike Perez

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Flavio Percoco-2


On Mon, Jun 12, 2017, 19:25 Mike Perez <[hidden email]> wrote:
On 16:01 Jun 12, Flavio Percoco wrote:
> On 12/06/17 23:20 +0300, Mikhail Fedosin wrote:
> > My opinion is that Glance stagnates and it's really hard to implement new
> > features there. In two years, only one major improvement was developed
> > (Image Import Refactoring), and no one has tested it in production yet. And
> > this is in the heyday of the community, as you said!
>
> You're skipping 2 important things here:
>
> The first one is that focusing on the image import refactor (IIR) was a
> community choice. It's fixing a bigger problem that requires more focus. The
> design of the feature took a couple of cycles too, not the implementation. The
> second thing is that the slow pace may also be caused by the lack of
> contributors.

+1 image import refactor work. That's great that the image import refactor work
is done!

Mikhail,

I'm pretty thorough on reading this list for the dev digest, so even I missed
that news. Which release was that done in? Are people not using it in
production right away because of having to upgrade to a new release?


It's actually coming out with Pike. Patches landed last week.

Flavio

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Mikhail Fedosin-2
In reply to this post by Flavio Percoco-2


On Tue, Jun 13, 2017 at 12:01 AM, Flavio Percoco <[hidden email]> wrote:
On 12/06/17 23:20 +0300, Mikhail Fedosin wrote:
My opinion is that Glance stagnates and it's really hard to implement new
features there. In two years, only one major improvement was developed
(Image Import Refactoring), and no one has tested it in production yet. And
this is in the heyday of the community, as you said!

You're skipping 2 important things here:

The first one is that focusing on the image import refactor (IIR) was a
community choice. It's fixing a bigger problem that requires more focus. The
design of the feature took a couple of cycles too, not the implementation. The
second thing is that the slow pace may also be caused by the lack of
contributors.

It's exactly what I'm talking about - implementing medium-size feature (IIR is about 600 lines of code [1][2]) took 1 year of discussions and 1 year for implementation of 5 full-time developers. And most importantly, it took all the community attention. What if we need to implement more serious features? How much time will it take, given that there are not so many developers left?
 



On the other hand OpenStack users have been requesting for new features for
a long time: I'm talking about mutistore support, versioning of images,
image slicing (like in docker), validation and conversion of uploading data
and so on. And I can say that it is impossible to implement them without
breaking Glance. But all this stuff is already done in Glare (multistore
support is implemented partially, because modifications of glance_store are
required). And if we switch OpenStack to Glare users will get these
features out of the box.

Some of these features could be implemented in Glance. As you mentioned, the
code base is over-engineered but it could be simplified.

Everything is possible, I know that. But at what cost?
 


Then, Glance works with images only, but Glare supports various types of
data, like heat and tosca templates. Next week we will add Secrets artifact
type to store private data, and Mistral workflows. I mean - we'll have
unified catalog of all cloud data with the possibility to combine them in
metastructures, when artifact of one type depends on the other.

Glance working only with images is a design choice and I don't think that's
something bad. I also don't think Glare's support for other artifacts is bad.
Just different choices.

The idea behind Glare is to give operators, but not the developers, the opportunity to decide what types they want to use. Specify "enabled_artifact_types=images" in glare.conf and you'll get a service that works with images only (consider it as a feature if you want ;) ) Glance is just a special case of Glare, and it's not a big deal for Glare to behave like Glance in terms of "working only with images".
 



I will repeat it once again, in order to be understood as much as possible.
It takes too much time to develop new features and fix old bugs (years to
be exact). If we continue in the same spirit, it certainly will not
increase the joy of OpenStack users and they will look for other solutions
that meet their desires.

Mike, I understand that you think that the broader set of features that Glare
provides would be better for users, which is something I disagree with a bit.
More features don't make a service better. What I'm failing to see, though, is
why you believe that replacing Glance with Glare will solve the current problem.

I think that features are important, but sometimes stability matters too! There are still a lot of dangerous and nasty bugs, that we can't fix without breaking Glance.
 

I don't think the current problem is caused by Glance's lack of "exciting"
features and I certainly don't think replacing it with Glare would be of any
help now. It may be something we want to think about in the future (and this is
not the first time I say this) but what you're proposing will be an expensive
distraction from the real problem. 

And for the very last time - I don't suggest to replace Glance now or even in a year. At the moment, an email with the title "Glance needs help, it's getting critical" is enough. 
I call to think about the distant future, probably two years or near that. What can prevent Flavio from writing of such emails in T cycle? Bringing people from Nova and Cinder part-time will not work, because, as we discussed above, even medium-size feature requires years of dedicated work, and having their +1 on typo fixes... what's the benefit of that?

And for the very last time - I'm here not to promote Glare. As you know, I will soon be involved in this project extremely mediately. I'm here to decide what to do with Glance next. In the original email Flavio said "So, before things get even worse, I'd like us to brainstorm a bit on what solutions/options we have now". I described in detail my personal feelings about the current situation in Glance for the members of TC, who are unfamiliar with the project.  And also I suggested one possible solution with Glare, maybe not the best one, but I haven't heard any other proposals. Instead of constructive discussion and decision making, I received a bunch of insults in private correspondence, accusations of betrayal and suggestions to drive me out of the community. 

So, should I shut up and pretend that everything is absolutely wonderful? If this is a way to solve problems in OpenStack, then I understand the reason for such email titles.

Best,
Mike


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Flavio Percoco-2


On Mon, Jun 12, 2017, 19:47 Mikhail Fedosin <[hidden email]> wrote:
On Tue, Jun 13, 2017 at 12:01 AM, Flavio Percoco <[hidden email]> wrote:
On 12/06/17 23:20 +0300, Mikhail Fedosin wrote:
My opinion is that Glance stagnates and it's really hard to implement new
features there. In two years, only one major improvement was developed
(Image Import Refactoring), and no one has tested it in production yet. And
this is in the heyday of the community, as you said!

You're skipping 2 important things here:

The first one is that focusing on the image import refactor (IIR) was a
community choice. It's fixing a bigger problem that requires more focus. The
design of the feature took a couple of cycles too, not the implementation. The
second thing is that the slow pace may also be caused by the lack of
contributors.

It's exactly what I'm talking about - implementing medium-size feature (IIR is about 600 lines of code [1][2]) took 1 year of discussions and 1 year for implementation of 5 full-time developers. And most importantly, it took all the community attention. What if we need to implement more serious features? How much time will it take, given that there are not so many developers left?


What I was referring to is that this is not the normal case. The IIR was a special case, which doesn't mean implementing features is easy, as you mentioned.

On the other hand OpenStack users have been requesting for new features for
a long time: I'm talking about mutistore support, versioning of images,
image slicing (like in docker), validation and conversion of uploading data
and so on. And I can say that it is impossible to implement them without
breaking Glance. But all this stuff is already done in Glare (multistore
support is implemented partially, because modifications of glance_store are
required). And if we switch OpenStack to Glare users will get these
features out of the box.

Some of these features could be implemented in Glance. As you mentioned, the
code base is over-engineered but it could be simplified.

Everything is possible, I know that. But at what cost?


Exactly! This is what I'm asking you to help me out with. I'm trying to have a constructive discussion on the cost of this and find a sohort term solution and then a long term one.

I don't think the current problem is caused by Glance's lack of "exciting"
features and I certainly don't think replacing it with Glare would be of any
help now. It may be something we want to think about in the future (and this is
not the first time I say this) but what you're proposing will be an expensive
distraction from the real problem. 

And for the very last time - I don't suggest to replace Glance now or even in a year. At the moment, an email with the title "Glance needs help, it's getting critical" is enough. 
I call to think about the distant future, probably two years or near that. What can prevent Flavio from writing of such emails in T cycle? Bringing people from Nova and Cinder part-time will not work, because, as we discussed above, even medium-size feature requires years of dedicated work, and having their +1 on typo fixes... what's the benefit of that?

Fully agree here. What I think we need is a short term and a long term solution. Would you agree with this?

I mentioned in my previous email that I've never been opposed to a future transition away from Glance as soon as this happens naturally.

I understand that you're not proposing to replace Glance now. What I was trying to understand is why you thought migratinf away from Glance in the future would help us now.

And for the very last time - I'm here not to promote Glare. As you know, I will soon be involved in this project extremely mediately. I'm here to decide what to do with Glance next. In the original email Flavio said "So, before things get even worse, I'd like us to brainstorm a bit on what solutions/options we have now". I described in detail my personal feelings about the current situation in Glance for the members of TC, who are unfamiliar with the project.  And also I suggested one possible solution with Glare, maybe not the best one, but I haven't heard any other proposals.

I know you're not promoting Glare and O hope my emails are not coming through as accusations of any kind. I'm playing the devil's advocate because I would like us to explore the different options we have and you proposed one.

 Instead of constructive discussion and decision making, I received a bunch of insults in private correspondence, accusations of betrayal and suggestions to drive me out of the community. 

As you know, I was cc'd in the thread where this happened and I'm deeply sorry it happened. As I mentioned in my reply to that thread, I know your intentions are goos and I do not want you to go anywhere.

Let's try to solve this conflict the best way possible.


So, should I shut up and pretend that everything is absolutely wonderful? If this is a way to solve problems in OpenStack, then I understand the reason for such email titles.

Absolutely not, don't shut up. I'm sad this discussion has been stressful for you. I hope you understand that this thread is unrelated to that private email and I'm actually interested in hearing more from you. :)

Flavio

P.S: replying from phone, sorry if the format is all wrong. 


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Brian Rosmaita-2
I take a week off and look at what happens ...

Sorry for top-posting, but I just have some general comments.  Mike
raises some good points, but I think it's too late in the cycle to
swap Glance out for Glare and expect everything to work properly.  (I
don't mean to imply anything about the quality of the Glare code base
by this, the concern is whether we can get sufficient testing and code
changes completed so that we could be sure that the substitution of
Glare + Images API would be unnoticed by deployers.  I just don't see
that as realistic given our current personnel situation).  I think for
Pike we need to work within the Glance code base and focus on the
limited set of priorities that we've more or less agreed on [0], and
seriously discuss Mike's proposal at the PTG.

I'm glad Mike brought this up now, because it would be a big change,
and as you can see in the previous messages in this thread, there are
pluses and minuses that need to be carefully considered. So I think
that discussing this issue could be constructive, if our goal is to
have a successful resolution at the next PTG.  However, I personally
don't think it's a good development strategy for the OpenStack Pike
release, which is what we need to concentrate on in the short term.

cheers,
brian

[0] https://review.openstack.org/#/c/468035/



On Mon, Jun 12, 2017 at 9:43 PM, Flavio Percoco <[hidden email]> wrote:

>
>
> On Mon, Jun 12, 2017, 19:47 Mikhail Fedosin <[hidden email]> wrote:
>>
>> On Tue, Jun 13, 2017 at 12:01 AM, Flavio Percoco <[hidden email]>
>> wrote:
>>>
>>> On 12/06/17 23:20 +0300, Mikhail Fedosin wrote:
>>>>
>>>> My opinion is that Glance stagnates and it's really hard to implement
>>>> new
>>>> features there. In two years, only one major improvement was developed
>>>> (Image Import Refactoring), and no one has tested it in production yet.
>>>> And
>>>> this is in the heyday of the community, as you said!
>>>
>>>
>>> You're skipping 2 important things here:
>>>
>>> The first one is that focusing on the image import refactor (IIR) was a
>>> community choice. It's fixing a bigger problem that requires more focus.
>>> The
>>> design of the feature took a couple of cycles too, not the
>>> implementation. The
>>> second thing is that the slow pace may also be caused by the lack of
>>> contributors.
>>
>>
>> It's exactly what I'm talking about - implementing medium-size feature
>> (IIR is about 600 lines of code [1][2]) took 1 year of discussions and 1
>> year for implementation of 5 full-time developers. And most importantly, it
>> took all the community attention. What if we need to implement more serious
>> features? How much time will it take, given that there are not so many
>> developers left?
>
>
>
> What I was referring to is that this is not the normal case. The IIR was a
> special case, which doesn't mean implementing features is easy, as you
> mentioned.
>
>>>> On the other hand OpenStack users have been requesting for new features
>>>> for
>>>> a long time: I'm talking about mutistore support, versioning of images,
>>>> image slicing (like in docker), validation and conversion of uploading
>>>> data
>>>> and so on. And I can say that it is impossible to implement them without
>>>> breaking Glance. But all this stuff is already done in Glare (multistore
>>>> support is implemented partially, because modifications of glance_store
>>>> are
>>>> required). And if we switch OpenStack to Glare users will get these
>>>> features out of the box.
>>>
>>>
>>> Some of these features could be implemented in Glance. As you mentioned,
>>> the
>>> code base is over-engineered but it could be simplified.
>>
>>
>> Everything is possible, I know that. But at what cost?
>
>
>
> Exactly! This is what I'm asking you to help me out with. I'm trying to have
> a constructive discussion on the cost of this and find a sohort term
> solution and then a long term one.
>
>>> I don't think the current problem is caused by Glance's lack of
>>> "exciting"
>>> features and I certainly don't think replacing it with Glare would be of
>>> any
>>> help now. It may be something we want to think about in the future (and
>>> this is
>>> not the first time I say this) but what you're proposing will be an
>>> expensive
>>> distraction from the real problem.
>>
>>
>> And for the very last time - I don't suggest to replace Glance now or even
>> in a year. At the moment, an email with the title "Glance needs help, it's
>> getting critical" is enough.
>> I call to think about the distant future, probably two years or near that.
>> What can prevent Flavio from writing of such emails in T cycle? Bringing
>> people from Nova and Cinder part-time will not work, because, as we
>> discussed above, even medium-size feature requires years of dedicated work,
>> and having their +1 on typo fixes... what's the benefit of that?
>
>
> Fully agree here. What I think we need is a short term and a long term
> solution. Would you agree with this?
>
> I mentioned in my previous email that I've never been opposed to a future
> transition away from Glance as soon as this happens naturally.
>
> I understand that you're not proposing to replace Glance now. What I was
> trying to understand is why you thought migratinf away from Glance in the
> future would help us now.
>
>> And for the very last time - I'm here not to promote Glare. As you know, I
>> will soon be involved in this project extremely mediately. I'm here to
>> decide what to do with Glance next. In the original email Flavio said "So,
>> before things get even worse, I'd like us to brainstorm a bit on what
>> solutions/options we have now". I described in detail my personal feelings
>> about the current situation in Glance for the members of TC, who are
>> unfamiliar with the project.  And also I suggested one possible solution
>> with Glare, maybe not the best one, but I haven't heard any other proposals.
>
>
> I know you're not promoting Glare and O hope my emails are not coming
> through as accusations of any kind. I'm playing the devil's advocate because
> I would like us to explore the different options we have and you proposed
> one.
>
>>  Instead of constructive discussion and decision making, I received a
>> bunch of insults in private correspondence, accusations of betrayal and
>> suggestions to drive me out of the community.
>
>
> As you know, I was cc'd in the thread where this happened and I'm deeply
> sorry it happened. As I mentioned in my reply to that thread, I know your
> intentions are goos and I do not want you to go anywhere.
>
> Let's try to solve this conflict the best way possible.
>
>>
>> So, should I shut up and pretend that everything is absolutely wonderful?
>> If this is a way to solve problems in OpenStack, then I understand the
>> reason for such email titles.
>
>
> Absolutely not, don't shut up. I'm sad this discussion has been stressful
> for you. I hope you understand that this thread is unrelated to that private
> email and I'm actually interested in hearing more from you. :)
>
> Flavio
>
> P.S: replying from phone, sorry if the format is all wrong.
>
>>
>> Best,
>> Mike
>>
>> [1]
>> https://review.openstack.org/#/q/status:merged+project:openstack/glance+branch:master+topic:feature/image-import
>> [2]
>> https://review.openstack.org/#/q/status:merged+project:openstack/glance+branch:master+topic:feature/image-import/import
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: [hidden email]?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Mikhail Fedosin-2
In reply to this post by Flavio Percoco-2


On Tue, Jun 13, 2017 at 4:43 AM, Flavio Percoco <[hidden email]> wrote:


On Mon, Jun 12, 2017, 19:47 Mikhail Fedosin <[hidden email]> wrote:
On Tue, Jun 13, 2017 at 12:01 AM, Flavio Percoco <[hidden email]> wrote:
On 12/06/17 23:20 +0300, Mikhail Fedosin wrote:
My opinion is that Glance stagnates and it's really hard to implement new
features there. In two years, only one major improvement was developed
(Image Import Refactoring), and no one has tested it in production yet. And
this is in the heyday of the community, as you said!

You're skipping 2 important things here:

The first one is that focusing on the image import refactor (IIR) was a
community choice. It's fixing a bigger problem that requires more focus. The
design of the feature took a couple of cycles too, not the implementation. The
second thing is that the slow pace may also be caused by the lack of
contributors.

It's exactly what I'm talking about - implementing medium-size feature (IIR is about 600 lines of code [1][2]) took 1 year of discussions and 1 year for implementation of 5 full-time developers. And most importantly, it took all the community attention. What if we need to implement more serious features? How much time will it take, given that there are not so many developers left?


What I was referring to is that this is not the normal case. The IIR was a special case, which doesn't mean implementing features is easy, as you mentioned.

On the other hand OpenStack users have been requesting for new features for
a long time: I'm talking about mutistore support, versioning of images,
image slicing (like in docker), validation and conversion of uploading data
and so on. And I can say that it is impossible to implement them without
breaking Glance. But all this stuff is already done in Glare (multistore
support is implemented partially, because modifications of glance_store are
required). And if we switch OpenStack to Glare users will get these
features out of the box.

Some of these features could be implemented in Glance. As you mentioned, the
code base is over-engineered but it could be simplified.

Everything is possible, I know that. But at what cost?


Exactly! This is what I'm asking you to help me out with. I'm trying to have a constructive discussion on the cost of this and find a sohort term solution and then a long term one.

I don't think the current problem is caused by Glance's lack of "exciting"
features and I certainly don't think replacing it with Glare would be of any
help now. It may be something we want to think about in the future (and this is
not the first time I say this) but what you're proposing will be an expensive
distraction from the real problem. 

And for the very last time - I don't suggest to replace Glance now or even in a year. At the moment, an email with the title "Glance needs help, it's getting critical" is enough. 
I call to think about the distant future, probably two years or near that. What can prevent Flavio from writing of such emails in T cycle? Bringing people from Nova and Cinder part-time will not work, because, as we discussed above, even medium-size feature requires years of dedicated work, and having their +1 on typo fixes... what's the benefit of that?

Fully agree here. What I think we need is a short term and a long term solution. Would you agree with this?

I mentioned in my previous email that I've never been opposed to a future transition away from Glance as soon as this happens naturally.

I understand that you're not proposing to replace Glance now. What I was trying to understand is why you thought migratinf away from Glance in the future would help us now.

It won't help immediately for sure. But in long-term I see next benefits: 
* We will have two full-time contributors from Nokia (can have more if it's necessary)
* Architecture is simpler, all functions are small and well documented. I believe it will take one-two days for a new developer to get accustomed with it.
* For me it's much easier to write code and review patches in Glare and I will spend more time for it.
* Integration with more projects: if Heat, Mistral, Murano will store their data in Glare we will get more feedback. 
* Long waiting features! For example, Glare has database store support, and users can put their small files (like heat templates) directly in mysql without a need of deploying Swift.
 

And for the very last time - I'm here not to promote Glare. As you know, I will soon be involved in this project extremely mediately. I'm here to decide what to do with Glance next. In the original email Flavio said "So, before things get even worse, I'd like us to brainstorm a bit on what solutions/options we have now". I described in detail my personal feelings about the current situation in Glance for the members of TC, who are unfamiliar with the project.  And also I suggested one possible solution with Glare, maybe not the best one, but I haven't heard any other proposals.

I know you're not promoting Glare and O hope my emails are not coming through as accusations of any kind. I'm playing the devil's advocate because I would like us to explore the different options we have and you proposed one.

Okay, to be fair I promoted it... But as I said, the reason of that was to propose a solution, and definitely not to offend anybody. 
 

 Instead of constructive discussion and decision making, I received a bunch of insults in private correspondence, accusations of betrayal and suggestions to drive me out of the community. 

As you know, I was cc'd in the thread where this happened and I'm deeply sorry it happened. As I mentioned in my reply to that thread, I know your intentions are goos and I do not want you to go anywhere.

Let's try to solve this conflict the best way possible.

No problem on my part. I already forgot about it :) I want to say that over the years all you people have become like my family. And sometimes family members argue, and I think that there is nothing wrong with that. All this reflects our common pain about the project, and we all want only one thing - to make OpenStack better!
 


So, should I shut up and pretend that everything is absolutely wonderful? If this is a way to solve problems in OpenStack, then I understand the reason for such email titles.

Absolutely not, don't shut up. I'm sad this discussion has been stressful for you. I hope you understand that this thread is unrelated to that private email and I'm actually interested in hearing more from you. :)

Deal :)
 

Flavio

P.S: replying from phone, sorry if the format is all wrong. 


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Chris Friesen
In reply to this post by Flavio Percoco-2
On 06/12/2017 01:50 PM, Flavio Percoco wrote:

> Glance can be very exciting if one focuses on the interesting bits and it's an
> *AWESOME* place where new comers can start contributing, new developers can
> learn and practice, etc. That said, I believe that code doesn't have to be
> challenging to be exciting. There's also excitment in the simple but interesting
> things.

As an outsider, I found it harder to understand the glance code than the nova
code...and that's saying something. :)

 From the naive external viewpoint, it just doesn't seem like what glance is
doing should be all that complicated, and yet somehow I found it to be so.

Chris

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Thierry Carrez
In reply to this post by Flavio Percoco-2
Quick attempt at a summary of the discussion so far, with my questions:

* Short-term, Glance needs help to stay afloat
  - Sean volunteered to help
  - but glance needs to add core reviewers to get stuff flowing
-> could the VM/BM workgroup also help ? Any progress there ?

* Long-term, is Glance still our best bet for the future ?
  - The code base is way more complicated than it should be
  - Difficult to work on necessary refactoring with current resources
  - Glare is a sane base, but achieves more than just image catalog
  - Disk images may be special enough to require their own service
-> Elaborate on "optimizing for their specialness is really important"

--
Thierry Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [all][tc][glance] Glance needs help, it's getting critical

Flavio Percoco-2
On 13/06/17 10:49 +0200, Thierry Carrez wrote:
>Quick attempt at a summary of the discussion so far, with my questions:
>
>* Short-term, Glance needs help to stay afloat
>  - Sean volunteered to help
>  - but glance needs to add core reviewers to get stuff flowing
>-> could the VM/BM workgroup also help ? Any progress there ?

+1

Given the current situation, I think we'll get any help we can. I'd be happy to
add Sean and a couple of other volunteers to the core team until the end of the
cycle. When Pike is out, we can do a status check and see how to proceed.

>* Long-term, is Glance still our best bet for the future ?
>  - The code base is way more complicated than it should be
>  - Difficult to work on necessary refactoring with current resources
>  - Glare is a sane base, but achieves more than just image catalog
>  - Disk images may be special enough to require their own service
>-> Elaborate on "optimizing for their specialness is really important"

I'd like to start working on a more formal proposal for this. The email threas
have covered some interesting points and there have been a good number of
sessions at various summits about this same argument.

There could be another session in Denver but I'd like to see a more formal
document, etherpad, whatever, that explains the different features that would
make the migration worth it and a set of different paths we could explore to
make this migration happen. With this info, I think we will be able to make a
thoughtful decision.

Flavio

--
@flaper87
Flavio Percoco

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc (879 bytes) Download Attachment
12