Open Stack

On 08/14/15 at 01:06pm, stuart.mclaren at 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev