66 lines
3.0 KiB
Plaintext
66 lines
3.0 KiB
Plaintext
Hi
|
|
|
|
I'd like to announce my candidacy for Cinder PTL.
|
|
|
|
I've been actively involved in Cinder as a core since it was split out of Nova,
|
|
and with nova-volume before that. I've been involved in mentoring new people,
|
|
reviews, code and community discussions all of that time. I've been an operator
|
|
of Cinder in a large public cloud, including being called out at 4am when
|
|
something breaks, giving me a great deal of sympathy for operational matters.
|
|
Cinder has grown and matured at an impressive rate, and I now feel the project
|
|
is at an important decision point about what we want to be going forward. With
|
|
that in mind, my main aims as a PTL would be as follows:
|
|
|
|
- Make the ideology of Cinder - standard features, good discoverability where
|
|
universal implementation of a feature isn;t possible, and keeping the tenant
|
|
experience as clean as possible - the admin experience should be as clean as
|
|
possible without compromising the tenant experience.
|
|
|
|
- Matching our bleeding edge velocity with our trailing edge velocity - we
|
|
merged a bunch of features that only work in a very, very limited number of
|
|
drivers. We need to push implementation of these features as widely as
|
|
possible, and where a reasonable generic implementation can be made then we
|
|
need to push that as a requirement for adding the feature.
|
|
|
|
- Stability and quality - our unit test test coverage has not improved
|
|
significantly in terms of lines of code or quality of tests, and our tempest
|
|
coverage has got worse. I suggest that we push for more tempest tests to go
|
|
with new features. The reliability and usability of third party CI can also
|
|
be incrementally improved - we've got nearly every driver being tested now,
|
|
lets make the test output more useful to developers.
|
|
|
|
- Communication - Mike demonstrated the great value of clear, regular and open
|
|
communication and I intend to keep building on this example
|
|
|
|
- Less bureaucracy that gets in the way - I think that the way we did
|
|
prioritisation in Liberty, while a good first attempt, can be improved,
|
|
particularly with dropping the review priority of tasks that are blocked
|
|
waiting for rework, so that more smaller patches can bubble up the priority
|
|
list. I'd also like to look at using review priority to encourage good
|
|
community behaviour (reviews of other people's code, bug fixes and triage,
|
|
test writing, documentation, etc)
|
|
|
|
- Finishing open work before starting more work - we have a large list of
|
|
part-implemented tasks, so we should avoiding taking on new work that doesn't
|
|
drive these goals forward.
|
|
|
|
|
|
|
|
|
|
The things I'd like to see finished in the M release:
|
|
|
|
- Replication. At least 5 drivers implementing it.
|
|
|
|
- Smooth upgrade experience - even if we can't get it to zero downtime, I'd
|
|
like a well documented, tested upgrade path and a well understood list of
|
|
work to be finished..
|
|
|
|
- H/A - I believe we can have and should have a cinder experience where the
|
|
failure of any one node does not affect the externals of cinder, without
|
|
requiring pacemaker.
|
|
|
|
|
|
|
|
Thank you for your consideration.
|
|
|