On 08/14/15 at 01:06pm, stuart.mcla...@hp.com wrote:
I got zero responses on the mailing list raising a problem with Glance v2 [1].
I got zero responses on cross project meeting raising a problem with Glance v2
[2].
I'm very happy with my choice of words, because I think this hand slap on
Glance is the first time I got acknowledgement in my frustration with Glance.
I should not have to attend a Glance meeting to get someone to fix Glance v2
integration issues in Cinder.
Glance is trying to increase v2 integration with Nova besides show [3], but
I would recommend Nova to not accept further v2 integration until Glance has
figured out how to handle issues in projects that already have v2 integration.
To start, Glance should assign a cross project liaison [4] to actually respond
to integration issues in Cinder.
Having focuses on the following is not helping:
* Artifacts (I honestly don't know what this is and failed to find an
explanation that's *not* some API doc).
Hi Mike,
There has definitely been debate around artifacts, both within and outside
the project. Rather than beating us up, I'm genuinely interested to
know if you have any words of advice on how we could have handled this
differently (to avoid 'pissing off the community').
From my perspective, as someone who has only peripherally been following
the artifacts movement, I think the movement towards being a generic
artifact service while at the same time being extremely concerned with
image transfer makes it really unclear what Glance wants to be. I would
have expected that artifacts means moving towards more of a catalog
service and getting out of the business of caring how the artifacts are
retrieved. Or alternately if Glance is very focused on optimizing image
transfers then it would stick to that and leave the generic cataloging
to another service. Trying to do both seems to mean that neither use
case is getting the clarity and focus that would help others understand
what Glance is trying to achieve.
The original patch to extend Glance's mission to include artifacts is here:
https://review.openstack.org/#/c/98002
The set of approvers show that this was an OpenStack-wide effort rather
than a solo run by Glance.
At the summit in Vancouver we held a session to revisit this. Around 40
people attended (including around 7 TC members) and debated artifacts
openly and with a constructive tone.
My memory is that opinions in the room were fairly equally split. One
TC member said it would be 'embarrasing' if OpenStack had two catalog
services. Another TC member adamently advocated that Glance should stick
to images.
We reached out to the community for feedback and acted as best we could
on the feedback we received.
It would have been ok (if unpopular) for us to have acted unilaterally.
How would Cinder have handled this type of situation? What could/should
we have done differently? What would you suggest we do now?
* Tagging
If you mean 'metadefs' I'd tend to agree here. But, post the big tent
model, we have -- at least in one case -- kept focus by promoting proposed
non-core functionality to its own project:
https://review.openstack.org/#/c/188014
* Role based properties [5] (who is asking for this, and why is Glance
enforcing roles?)
Protected properties are typically used for licensing, so there is a real
business/legal use case here. The public clouds I know of use them. Is the
implementation stellar? Possibly not.
This is a mess, and complete lack of focus on being what Glance was once good
at, a registry for images.
[1] - http://lists.openstack.org/pipermail/openstack-dev/2015-July/070714.html
[2] -
http://eavesdrop.openstack.org/meetings/crossproject/2015/crossproject.2015-07-28-21.03.log.html#l-239
[3] - https://github.com/openstack/nova/blob/master/nova/image/glance.py#L305
[4] -
https://wiki.openstack.org/wiki/CrossProjectLiaisons#Inter-project_Liaisons
[5] - https://review.openstack.org/#/c/211201/1
--
Mike Perez
__________________________________________________________________________
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
