[openstack-dev] [Nova] [Cinder] [Glance] glance_store and glance
Flavio Percoco
flavio at redhat.com
Fri Aug 14 12:49:50 UTC 2015
On 14/08/15 13:06 +0100, 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').
+1
While I think the comments below are spot on and they explain why some
things happened, I do agree with Mike that we - Glance - as a community have
lost focus and there hasn't been enough dedication as in previous
cycles.
I see this as an opportunity for us to reflect and work on better
plans for Mitaka. Let's not focus just on the examples Mike used
since those are just examples that might give the right/wrong
impression to people outside the Glance community.
I'd really like us to take a step back and look at what has been
accomplished in this cycle. That should give us a better understanding
on where we should be headed in the next one and it'll also help us
understanding where we've failed.
>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
ah metadef, yeah... I'll leave this discussion for a different thread.
>>* 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.
And now I know what Mike was referring to.
Thanks, Stuart.
Flavio
--
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150814/ddddf71e/attachment.pgp>
More information about the OpenStack-dev
mailing list