Open Stack

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