On Tue, Jun 13, 2017 at 4:43 AM, Flavio Percoco <fla...@redhat.com> wrote:
> > > On Mon, Jun 12, 2017, 19:47 Mikhail Fedosin <mfedo...@gmail.com> wrote: > >> On Tue, Jun 13, 2017 at 12:01 AM, Flavio Percoco <fla...@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-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
