Open Stack

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 <fungi at yuggoth.org> 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
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20181211/b8d02b0b/attachment.html>