<div dir="ltr">Thank you for the update, it's much appreciated for those who couldn't make it :-)<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 4:34 AM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Wednesday afternoon at the OpenStack Summit we met to discuss the<br>
plan for the upcoming transition of the OpenStack Infrastructure<br>
team to an independent effort named OpenDev. Notes were recorded at<br>
<a href="https://etherpad.openstack.org/p/BER-opendev-feedback-and-missing-features" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/BER-opendev-feedback-and-missing-features</a><br>
and form the basis of the summary with follows.<br>
<br>
For those unfamiliar with this topic, the announcement at<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html</a><br>
provides some background and context. Much of what follows may be a<br>
reiteration of things also covered there, so please excuse any<br>
redundancy on my part.<br>
<br>
To start out, we (re)announced that we have chosen a name (OpenDev)<br>
and a domain (<a href="http://opendev.org" rel="noreferrer" target="_blank">opendev.org</a>), so can more effectively plan for DNS<br>
changes for most of the services we currently host under the<br>
"legacy" (for us) <a href="http://openstack.org" rel="noreferrer" target="_blank">openstack.org</a> domain. It was also pointed out that<br>
while we expect to maintain convenience redirects and aliases from<br>
old hostnames for all services we reasonably can so as to minimize<br>
disruption, there will still be some unavoidable discontinuities for<br>
users from time to time as we work through this.<br>
<br>
We talked for a bit about options for decentralizing GitHub<br>
repository mirroring so that the current team no longer needs to<br>
maintain it, and how to put it in control of people who want to<br>
manage those organizations there for themselves instead. Doing this<br>
with a job in Zuul's post pipeline (using encrypted secrets for<br>
authentication) was suggested as one possible means to avoid users<br>
all maintaining their own separate automation to accomplish the same<br>
thing.<br>
<br>
Interest in bare metal CI nodes in nodepool was brought up again. To<br>
reiterate, there's not really any technical reason we can't use<br>
them, more that prior offers to donate access to Nova/Ironic-managed<br>
nodes for this purpose never panned out. If you work for an<br>
organization which maintains a "bare metal cloud" we could reach<br>
over the open Internet and you'd consider carving out some of your<br>
capacity for our CI system, please do get in touch with us!<br>
<br>
We spent a bit of time covering user concerns about the transition<br>
to OpenDev and what reassurances we ought to provide. For starters,<br>
our regular contributors and root systems administrators will<br>
continue to be just as reachable and responsive as ever via IRC and<br>
mailing lists, even if the names of the channels and MLs may change<br>
as part of this transition. Similarly, our operations will remain as<br>
open and transparent as they are today... really nothing about how<br>
we maintain our systems is changing substantively as a part of the<br>
OpenDev effort, though certainly the ways in which we maintain our<br>
systems do still change and evolve over time as we seek to improve<br>
them so that will of course continue to be the case.<br>
<br>
Paul Belanger raised concerns that announcing OpenDev could result<br>
in a flood of new requests to host more projects. Well, really, I<br>
think that's what we hope for. I (apparently) pointed out that even<br>
when StackForge was first created back at the beginning of 2012,<br>
there wasn't much restriction as to what we would be willing to<br>
host. As interest in OpenDev spreads to new audiences, interest in<br>
participating in its maintenance and development should too grow.<br>
That said, we acknowledge that there are some scalability<br>
bottlenecks and manual/human steps in certain aspects of new project<br>
onboarding for now, so should be very up-front with any new projects<br>
about that fact. We're also not planning for any big marketing push<br>
to seek out additional projects at this point, but are happy to talk<br>
to any who discover us and are interested in the services we offer.<br>
<br>
Next, Paul Belanger brought up the possibility of "bring your own<br>
cloud" options for projects providing CI resources themselves. While<br>
we expect nodepool to have support for tenant-specific resources in<br>
the not-too-distant future, Jim Blair and Clark Boylan agreed the<br>
large pool of generic resources we operate with now is really where<br>
we see a lot of benefit and ability to drive efficiencies of scale.<br>
Then Monty Taylor talked for a while, according to the notes in the<br>
pad, and said things about earmarked resources potentially requiring<br>
a sort of "commons tax" or... something.<br>
<br>
Jim Rollenhagen asked whether we would potentially start to test and<br>
gate projects on GitHub too rather than just our Gerrit. Clark<br>
Boylan and Jim Blair noted that the current situation where we're<br>
testing pull requests for Kata's repositories is a bit of an<br>
experiment in that direction today and the challenges we've faced<br>
suggest that, while we'll likely continue to act as a third-party CI<br>
system for some projects hosted on GitHub (we're doing that with<br>
Ansible for example), we've discovered that trying to enforce gating<br>
in code review platforms we don't also control is not likely<br>
something we'll want to continue in the long term.<br>
<br>
It came up that our earlier ideas for flattening our Git namespace<br>
to reduce confusion and minimize future repository renames is now<br>
not looking as attractive. Instead we're probably going to need to<br>
embrace an explosion of new namespaces and find better ways to cope<br>
with the pain of renames in Gerrit as projects want to move between<br>
them over time. We're planning to only run one Gerrit for<br>
simplicity, so artificially creating "tenants" in it through<br>
prefixes in repository names is really the simplest solution we have<br>
to avoid different projects stepping on one another's toes with<br>
their name choices.<br>
<br>
Then we got into some policy discussions about namespace creation.<br>
Jim Blair talked about the potential to map Git/Gerrit repository<br>
namespaces to distinct Zuul tenants, and someone (might have been<br>
me? I was fairly jet-lagged and so don't really remember) asked<br>
about who decides what the requirements are for projects to create<br>
repositories in a particular namespace. In the case of OpenStack,<br>
the answer is almost certainly the OpenStack Technical Committee or<br>
at least some group to whom they delegate that responsibility. The<br>
OpenStack TC needs to discuss fairly early what its policies are for<br>
the "openstack" namespace (whether existing unofficial projects will<br>
be allowed to remain, whether addition of new unofficial projects<br>
will be allowed there) as well as whether it wants to allow creation<br>
of multiple separate namespaces for official OpenStack projects. The<br>
suggestion of nested "deep" namespaces like openstack/nova/nova came<br>
up at this point too.<br>
<br>
We also resolved that we need to look back into the project rename<br>
plugin for Gerrit. The last time we evaluated it, there wasn't much<br>
there. We've heard it's improved with newer Gerrit releases, but if<br>
it's still lacking we might want to contribute to making it more<br>
effective so we can handle the inevitable renames more easily in the<br>
future.<br>
<br>
And finally, as happens with most forum sessions, we stopped<br>
abruptly because we ran over and it was Kendall Nelson's turn to<br>
start getting ops feedback for the Contributor Guide. ;)<br>
-- <br>
Jeremy Stanley<br>
_______________________________________________<br>
OpenStack-Infra mailing list<br>
<a href="mailto:OpenStack-Infra@lists.openstack.org" target="_blank">OpenStack-Infra@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra</a></blockquote></div>