Open Stack

Wednesday afternoon at the OpenStack Summit we met to discuss the
plan for the upcoming transition of the OpenStack Infrastructure
team to an independent effort named OpenDev. Notes were recorded at
https://etherpad.openstack.org/p/BER-opendev-feedback-and-missing-features
and form the basis of the summary with follows.

For those unfamiliar with this topic, the announcement at
http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html
provides some background and context. Much of what follows may be a
reiteration of things also covered there, so please excuse any
redundancy on my part.

To start out, we (re)announced that we have chosen a name (OpenDev)
and a domain (opendev.org), so can more effectively plan for DNS
changes for most of the services we currently host under the
"legacy" (for us) openstack.org domain. It was also pointed out that
while we expect to maintain convenience redirects and aliases from
old hostnames for all services we reasonably can so as to minimize
disruption, there will still be some unavoidable discontinuities for
users from time to time as we work through this.

We talked for a bit about options for decentralizing GitHub
repository mirroring so that the current team no longer needs to
maintain it, and how to put it in control of people who want to
manage those organizations there for themselves instead. Doing this
with a job in Zuul's post pipeline (using encrypted secrets for
authentication) was suggested as one possible means to avoid users
all maintaining their own separate automation to accomplish the same
thing.

Interest in bare metal CI nodes in nodepool was brought up again. To
reiterate, there's not really any technical reason we can't use
them, more that prior offers to donate access to Nova/Ironic-managed
nodes for this purpose never panned out. If you work for an
organization which maintains a "bare metal cloud" we could reach
over the open Internet and you'd consider carving out some of your
capacity for our CI system, please do get in touch with us!

We spent a bit of time covering user concerns about the transition
to OpenDev and what reassurances we ought to provide. For starters,
our regular contributors and root systems administrators will
continue to be just as reachable and responsive as ever via IRC and
mailing lists, even if the names of the channels and MLs may change
as part of this transition. Similarly, our operations will remain as
open and transparent as they are today... really nothing about how
we maintain our systems is changing substantively as a part of the
OpenDev effort, though certainly the ways in which we maintain our
systems do still change and evolve over time as we seek to improve
them so that will of course continue to be the case.

Paul Belanger raised concerns that announcing OpenDev could result
in a flood of new requests to host more projects. Well, really, I
think that's what we hope for. I (apparently) pointed out that even
when StackForge was first created back at the beginning of 2012,
there wasn't much restriction as to what we would be willing to
host. As interest in OpenDev spreads to new audiences, interest in
participating in its maintenance and development should too grow.
That said, we acknowledge that there are some scalability
bottlenecks and manual/human steps in certain aspects of new project
onboarding for now, so should be very up-front with any new projects
about that fact. We're also not planning for any big marketing push
to seek out additional projects at this point, but are happy to talk
to any who discover us and are interested in the services we offer.

Next, Paul Belanger brought up the possibility of "bring your own
cloud" options for projects providing CI resources themselves. While
we expect nodepool to have support for tenant-specific resources in
the not-too-distant future, Jim Blair and Clark Boylan agreed the
large pool of generic resources we operate with now is really where
we see a lot of benefit and ability to drive efficiencies of scale.
Then Monty Taylor talked for a while, according to the notes in the
pad, and said things about earmarked resources potentially requiring
a sort of "commons tax" or... something.

Jim Rollenhagen asked whether we would potentially start to test and
gate projects on GitHub too rather than just our Gerrit. Clark
Boylan and Jim Blair noted that the current situation where we're
testing pull requests for Kata's repositories is a bit of an
experiment in that direction today and the challenges we've faced
suggest that, while we'll likely continue to act as a third-party CI
system for some projects hosted on GitHub (we're doing that with
Ansible for example), we've discovered that trying to enforce gating
in code review platforms we don't also control is not likely
something we'll want to continue in the long term.

It came up that our earlier ideas for flattening our Git namespace
to reduce confusion and minimize future repository renames is now
not looking as attractive. Instead we're probably going to need to
embrace an explosion of new namespaces and find better ways to cope
with the pain of renames in Gerrit as projects want to move between
them over time. We're planning to only run one Gerrit for
simplicity, so artificially creating "tenants" in it through
prefixes in repository names is really the simplest solution we have
to avoid different projects stepping on one another's toes with
their name choices.

Then we got into some policy discussions about namespace creation.
Jim Blair talked about the potential to map Git/Gerrit repository
namespaces to distinct Zuul tenants, and someone (might have been
me? I was fairly jet-lagged and so don't really remember) asked
about who decides what the requirements are for projects to create
repositories in a particular namespace. In the case of OpenStack,
the answer is almost certainly the OpenStack Technical Committee or
at least some group to whom they delegate that responsibility. The
OpenStack TC needs to discuss fairly early what its policies are for
the "openstack" namespace (whether existing unofficial projects will
be allowed to remain, whether addition of new unofficial projects
will be allowed there) as well as whether it wants to allow creation
of multiple separate namespaces for official OpenStack projects. The
suggestion of nested "deep" namespaces like openstack/nova/nova came
up at this point too.

We also resolved that we need to look back into the project rename
plugin for Gerrit. The last time we evaluated it, there wasn't much
there. We've heard it's improved with newer Gerrit releases, but if
it's still lacking we might want to contribute to making it more
effective so we can handle the inevitable renames more easily in the
future.

And finally, as happens with most forum sessions, we stopped
abruptly because we ran over and it was Kendall Nelson's turn to
start getting ops feedback for the Contributor Guide. ;)
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20181210/3a501468/attachment.sig>