[openstack-dev] [all][tc][glance] Glance needs help, it's getting critical
Mikhail Fedosin
mfedosin at gmail.com
Tue Jun 13 00:43:55 UTC 2017
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?
>
>
>
>> 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
[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170613/46043f83/attachment.html>
More information about the OpenStack-dev
mailing list