[openstack-dev] [ironic] ironic-staging-drivers: what to do?

Jim Rollenhagen jim at jimrollenhagen.com
Tue Aug 14 12:38:10 UTC 2018


On Mon, Aug 13, 2018 at 2:40 PM, Julia Kreger <juliaashleykreger at gmail.com>
wrote:

> Greetings fellow ironicans!
>
> As many of you might know an openstack/ironic-staging-drivers[1]
> repository exists. What most might not know is that it was
> intentionally created outside of ironic's governance[2].
>
> At the time it was created ironic was moving towards removing drivers
> that did not meet our third-party CI requirement[3] to be in-tree. The
> repository was an attempt to give a home to what some might find
> useful or where third party CI is impractical or cost-prohibitive and
> thus could not be officially part of Ironic the service. There was
> hope that drivers could land in ironic-staging-drivers and possibly
> graduate to being moved in-tree with third-party CI. As our community
> has evolved we've not stopped and revisited the questions.
>

Which questions?

With our most recent release over, I believe we need to ask ourselves
> if we should consider moving ironic-staging-drivers into our
> governance.
>
> Over the last couple of releases several contributors have found
> themselves trying to seek out two available reviewers to merge even
> trivial fixes[4]. Due to the team being so small this was no easy
> task. As a result, I'm wondering why not move the repository into
> governance, grant ironic-core review privileges upon the repository,
> and maintain the purpose and meaning of the repository. This would
> also result in the repository's release becoming managed via the
> release management process which is a plus.
>

Agree with Dmitry, just because ironic-core has +2 doesn't mean they will
look at it. I'm not opposed to adding more of the ironic-core folks to it
outside of governance, though. While I probably wouldn't review
ironic-staging-drivers often whether it is in our governance or not, I'd be
happy to review trivial changes to help move things along.

We could then propose an actual graduation process and help alleviate
> some of the issues where driver code is iterated upon for long periods
> of time before landing. At the same time I can see at least one issue
> which is if we were to do that, then we would also need to manage
> removal through the same path.
>

Is there any reason we can't have the same graduation process without
bringing it into ironic's governance?

I know there are concerns over responsibility in terms of code
> ownership and quality, but I feel like we already hit such issues[5],
> like those encountered when Dmitry removed classic drivers[6] from the
> repository and also encountered issues just prior to the latest
> release[7][8].
>

Yes, this is my primary concern. I don't believe that the ironic team
should be responsible for this code, when we can't validate it (manually or
via CI).

Any code is going to have quality issues from time to time. The difference
is who is responsible for taking care of those.

[5] and [6] are examples of where we knew we were going to break
out-of-tree drivers, and helped fix them because we're kind people - not
where we were taking ownership of the code. I suspect if we were aware of
other out-of-tree drivers we would have been happy to fix those as well.
[7] and [8] are just general code maintenance, and aren't really an
argument to me for having the ironic team take over this project.

Besides, as Dmitry notes, he "has to" care about ironic-staging-drivers
anyway, and 3 out of those 4 commits are his. :)

Overall I'm -1, but will live by whatever decision we come to.

// jim

This topic has come up in passing at PTGs and most recently on IRC[9],
> and I think we ought to discuss it during our next weekly meeting[10].
> I've gone ahead and added an item to the agenda, but we can also
> discuss via email.


> -Julia
>
> [1]: http://git.openstack.org/cgit/openstack-infra/project-
> config/tree/gerrit/projects.yaml#n4571
> [2]: http://git.openstack.org/cgit/openstack/ironic-staging-
> drivers/tree/README.rst#n16
> [3]: https://specs.openstack.org/openstack/ironic-specs/specs/
> approved/third-party-ci.html
> [4]: https://review.openstack.org/#/c/548943/
> [5]: https://review.openstack.org/#/c/541916/
> [6]: https://review.openstack.org/567902
> [7]: https://review.openstack.org/590352
> [8]: https://review.openstack.org/590401
> [9]: http://eavesdrop.openstack.org/irclogs/%23openstack-
> ironic/%23openstack-ironic.2018-08-09.log.html#t2018-08-09T11:55:27
> [10]: https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_
> for_next_meeting
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180814/b383623c/attachment.html>


More information about the OpenStack-dev mailing list