Thank you for the update, it's much appreciated for those who couldn't make it :-)
On Tue, Dec 11, 2018 at 4:34 AM Jeremy Stanley <[email protected]> wrote: > 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 > _______________________________________________ > OpenStack-Infra mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
_______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
