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

Mikhail Fedosin mfedosin at gmail.com
Tue Jun 13 03:02:23 UTC 2017


On Tue, Jun 13, 2017 at 4:43 AM, Flavio Percoco <flavio at redhat.com> wrote:

>
>
> On Mon, Jun 12, 2017, 19:47 Mikhail Fedosin <mfedosin at gmail.com> wrote:
>
>> On Tue, Jun 13, 2017 at 12:01 AM, Flavio Percoco <flavio at redhat.com>
>> 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.
>
>
>> 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: OpenStack-dev-request at lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170613/c2f7ac6e/attachment.html>


More information about the OpenStack-dev mailing list