[openstack-dev] [cinder] Leaving the Cinder Core team

[Scott D'Angelo]

It is with mixed feelings that I announce my resignation from the OpenStack
Cinder core reviewer team.
It has been a great pleasure to watch the OpenStack project evolve over the
years I have participated, and bit of sadness to move into a new role at
work where I am no longer involved.
After changing jobs I had attempted to keep up with Cinder reviews, but I
clearly have not participated in a few months now. I appreciate Cinder and
the other teams I've worked with in the OpenStack project, and consider the
time I spent working with you all one of the best jobs I have had. I do
not, however, think I will be able to keep up with reviews in the future,
so I should go ahead and resign.
Please feel free to contact me anytime about Cinder or for any other reason.

scottda
Scott D'Angelo
scott.dang...@gmail.com
__
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-dev] Consistent Versioned Endpoints

[Scott D'Angelo]

TL;DR: Let's discuss Version Discovery and Endpoints in the Service Catalog
at the PTG in Atlanta.

The topic of Versioning and the Endpoints discovered in the Service Catalog
was discussed in today's API Working Group Meeting[1].
A previous ML post[2] claimed:

In a perfect world, every endpoint would return the same type of resource -
most likely the versions resource as described in the API WG Microversions
spec. It would also be nice if version negotiation can happen without
requiring authentication, the easiest path to which would be supporting the
'max_version' and 'min_version' fields in the root versions resource.

One problem is multiple versioned service names in the catalog for a given
service[3], as opposed to a single endpoint that would return version
info[4].

Can we get to this "perfect world"? Let's discuss at the PTG.
It is my understanding that we do not have the ability to schedule a time
or room for such a cross-project discussion. Please chime in if interested,
and/or make your interest known to scottda, mordred, or edleafe.

Scott D'Angelo
scott.dang...@ibm.com

[1]
http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-01-12-16.00.log.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-August/102549.html
[3] http://paste.openstack.org/show/594751/
[4] http://paste.openstack.org/show/594754/
__
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

Re: [openstack-dev] [tc][all] Feedback from driver maintainers about future of driver projects

[Scott D'Angelo]

Thanks for working on this stevemar.
In the future, could we find a way to send such a survey to a broader
audience? I'm not on a Cinder driver maintainer list, but I work closely
with our driver maintainers and the OpenStack community, so I might be able
to respond more reliably to surveys like this.
thanks,
scottda
scott.dang...@ibm.com

On Tue, Jan 10, 2017 at 12:33 AM, Steve Martinelli 
wrote:

> In preparation for the next TC meeting, a survey was sent out to driver
> maintainers, here is a summary of the feedback that was gathered.
>
> Major observations
>
> ==
>
> * Are drivers an important part of OpenStack? YES!
>
> * Discoverability of drivers needs to be fixed immediately.
>
> * It is important to have visibility in a central place of the status of
> each driver.
>
> * Perspective of a driver developer and a high level person at the company
> should feel like they're part of something.
>
> * OpenStack should stop treating drivers like second-class citizens. They
> want access to the same resources (publish on docs.o.org, config guides,
> etc).
>
> * The initial wording about what constitutes a project was never intended
> for drivers. Drivers are a part of the project. Driver developers
> contribute to OpenStack by creating drivers.
>
> Discoverability
>
> ===
>
> * Consensus: It is currently all over the place. A common mechanism to
> view all supported drivers is needed.
>
> * Cinder list: http://docs.openstack.org/developer/cinder/drivers.html
>
> * Nova list: http://docs.openstack.org/developer/nova/support-matrix.html
>
> * Stackalytics list: http://stackalytics.openstack.org/report/driverlog
>
> * Opinion: If we intend to use the marketplace (or anywhere on
> openstack.org) to list in-tree and out-of-tree drivers, they should have
> CI results available as a requirement. A driver that fails CI is not just a
> vendor problem, it’s an OpenStack problem, it reflects poorly on OpenStack
> and the project.
>
> * Opinion: What constitutes a supported driver, why not list all drivers?
>
> * Opinion: Fixing discoverability can be done independently of governance
> changes. We have the option of tabling the governance discussion until we
> get the discoverability properly fixed, and see then if we still need to do
> anything more.
>
> * Opinion: Between giving full access to vertical resources to driver
> teams, and making the marketplace *the* place for learning about OpenStack
> drivers, we would have solved at least the biggest portion of the problem
> we're facing.
>
> Driver projects - official or not?
>
> ==
>
> * Fact: There is desire from some out-of-tree vendors to become ‘official’
> OpenStack projects, and gain the benefits of that (access to horizontal
> teams).
>
> * Opinion: Let drivers projects become official, there should be no 3rd
> party CI requirement, that can be a tag.
>
> * Opinion: Do not allow drivers projects to become official, that doesn’t
> mean they shouldn’t easily be discoverable.
>
> * Opinion: We don't need to open the flood gates of allowing vendors to be
> teams in the OpenStack governance to make the vendors developers happy.
>
> * Fact: This implies being placed under the TC oversight. It is a
> significant move that could have unintended side-effects, it is hard to
> reverse (kicking out teams we accepted is worse than not including them in
> the first place), and our community is divided on the way forward. So we
> need to give that question our full attention and not rush the answer.
>
> * Opinion: Consider https://github.com/openstack/driverlog an official
> OpenStack project to be listed under governance with a PTL, weekly
> meetings, and all that it required to allow the team to be effective in
> their mission of keeping the marketplace a trustworthy resource for
> learning about OpenStack driver ecosystem.
>
> Driver developers
>
> =
>
> * Opinion: A driver developer that ONLY contributes to vendor specific
> driver code should not have the same influence as other OpenStack
> developers, voting for PTL, TC, and ATC status.
>
> * Opinion: PTLs should leverage the extra-atcs option in the governance
> repo
>
> In-tree vs Out-of-tree
>
> ==
>
> * Cinder has in-tree drivers, but also has out-of-tree drivers when their
> CI is not maintained or when minimum feature requirements are not met. They
> are marked as ‘not supported’ and have a single release to get things
> working before being moved out-of-tree.
>
> * Ironic has a single out-of-tree repo: https://github.com/openstack/
> ironic-staging-drivers -- But also in-tree https://github.com/openstack/
> ironic/tree/master/ironic/drivers
>
> * Neutron has all drivers out-of-tree, with project names like:
> ‘networking-cisco’.
>
> * Many opinions on the “stick-based” approach the cinder team took.
>
> * Opinion: The in-tree vs out-of-tree argument is developer focused.
> Out-of-tree drivers